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.

Go To Page: 1 2 3 4

Articles in this Topic    Discussions in this Topic