There are a Variety of Specifications Presented Throughout the Industry to Capture Requirements.

The requirements document (specification), the result of analysis, sets the stage for the entire and/or any process/phase/activity (design, implementation, etc.) within the development process or life cycle. It is a configuration identification document as well as the design specification/document. The requirements document contains functional/capability, design, interface, data, and other product (software/application/system) requirements. Although it is a living document, a requirements document records the agreements and decisions reached between the contractor, client/customer, and users. This begins the requirements management process/configuration management.

A requirements document may record agreements and decisions related to a project and product (system, software, application, database, web site, network, etc.). Signed by the author of the document and approved by the developer, user representative, PM and customer/client/sponsor. The business, functional/capability, and feature requirements must be complete enough to commit to executing the remaining development process (i.e., design, construction, etc.). Each paragraph in the document will/should be numbered/identified. Each requirement should be identified. Each system, software, application and it modules or components should be identified. The web site should be identified. A change page/log should be inserted in the document. A traceability matrix should be inserted in an appendix. All requirements must be stated with “Shall”, “must” and intent with “will”. For consistency, consider having one section identified for all product requirements. Many companies do/should have some type of methodology and templates that are used for the enterprise. Most can be tailored and modified for the particular project and product. A requirements document can be 50 to 100 pages for small/medium size products or hundreds to thousands pages for large products. In the aerospace environment volumes have been prepared.

Basic Content

1. Introduction Document Overview

   Terms, acronyms, abbreviations, and definitions

   Usually a good idea to have up front to allow stakeholders an opportunity to familiarize themselves with common terms and definitions before reading the specification/document. If extensive, may be included as an appendix.) Referenced and Applicable Documents

2. Project SummaryIncluding: Implementation approach for development (based on configuration management/deliverables. The development process.)

   Assumptions

   (Related to project, organization, technology, the entire development process (or individual process (e.g., design)), and people.)

   Constraints (Related to project, architecture/design, standards/regulations, technology, etc.)

   Risks (initially identified risks and preparation of a risks management plan)

   (Related to project, each development process (such requirements, design,

   implementation, etc.), technology, etc.

3. Product Overview/General Requirements/Capabilities (After a requirements is identified it can be fulfilled by an individual or group function/functions, class/object, or components. Each requirement for the software/application can be described at these levels). Described inperformance measurable terms.) Presented in table form for the purpose of presentation.

1. Qualification Methods(Each requirement (in section three for this example) shall be validated

   by one of the following methods: test, analyst, inspection, demonstrate,

   or observation.) Can be identified by each requirements or detailed

   here)