Software Documentation and Software Processes
May 9, 2001 -
© Edward B. Toupin
* Requirements Analysis In a perfect world, the software company and the customer must agree on the content of the Requirements Analysis Document before a project can begin. The document must contain a detailed statement identifying the problem that needs solving, without implying a solution. Additionally, it is important to provide an overview of objectives that must be met in solving the problem. * Functional Specification The development team uses the Requirements Analysis Document to develop a Functional Specification Document. This document outlines the requirements and tasks that are required to meet the needs of the customer and provides an elementary design to understand the solution for the customer. * Customer Proposal The Customer Proposal outlines the tasks, budget, and timeline required to complete the task described in the Functional Specification Document. This document must provide the customer with the project management details as well as a copy of the Functional Specification Document for the project. * Software Design Once the customer has accepted the Customer Proposal, the development team produces the Software Design Document. This document details how the software will ultimately function to achieve the requirements contained in the Requirements Analysis and Functional Specification documents. The content details the decomposition of the software as well as dependency and data flow descriptions. The information should provide absolute detail of diagrams and descriptions showing the individual components of the overall project. * Feature Change The Feature Change Document provides a way to manage addenda and updates for documentation. This document outlines the changes made to a given component of a product or project. The content must provide enough detail to describe the change, why the change was made, and any tests to ensure that the change was valid. * Test Documentation The Test Documentation provides a set of criteria that details how to test each atomic component of the system (i.e., white box) as well as the entire system (i.e., black box). Additionally, the documentation should list all input actions associated with each component as well as the expected results. Finally, the document should list any specific timing constraints as well as any test equipment needed to verify the integrity of the software. * User Acceptance Test The User Acceptance Test is a short document that defines a set of steps that the user can use to ensure that the software meets the original requirements analysis. --- So, what about the user documentation? --- Planning the user documentation is a necessary step to eliminate problems and surprises that can occur during
The copyright of the article Software Documentation and Software Processes in Technical Writing is owned by Edward B. Toupin. Permission to republish Software Documentation and Software Processes in print or online must be granted by the author in writing.
Articles in this Topic
Discussions in this Topic
|