Page History
...
| id | tabs-1 |
|---|
1. Requirements
3.1.1.1 The project shall document the software requirements.
1.1 Notes
The requirements for the content of a Software Requirement Specification and a Data Dictionary document are defined in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, section 5.2.1 and 5.2.2, respectively]. The requirements definition activity also includes documenting key decisions, developing requirement rationales, and defining assumptions. The requirement development activities can use lessons learned in performing the logical decomposition process activities. The requirements definition activity provides an understanding of the derived technical requirements baseline, a logical decomposition model, traceability to technical requirements, and an understanding of the stakeholder's expectations.
1.2 Applicability Across Classes
Class E and Not Safety Critical is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.
...
| f | 1 |
|---|---|
| g | 1 |
| h | 0 |
| ansc | 1 |
| asc | 1 |
| bnsc | 1 |
| csc | 1 |
| bsc | 1 |
| esc | 1 |
| cnsc | 1 |
| dnsc | 1 |
| dsc | 1 |
| ensc | p |
...
| id | tabs-2 |
|---|
2. Rationale
Requirements are the basis for a software product. They identify the needs to be addressed, the behavior of the system, and the constraints under which the problem is to be solved. They specify the product the provider is to deliver to a customer.
...
Requirements serve as the basis for verification activities allowing the developing organization and the customer to judge the completeness of the product.
...
| id | tabs-3 |
|---|
3. Guidance
A general process flow for documenting software requirements is shown below:
Guidance for the content of the documents which capture software requirements, the Software Requirement Specification (SRS) (SWE-109) and the Data Dictionary document (SWE-110) are found in other sections of this Handbook. Additionally, software interface requirements may be captured in an Interface Control Document (ICD) or an Interface Requirements Document (IRD), along with hardware interface requirements. If an ICD or IRD is used, the SRS references that document.
The following roles may be involved in defining and documenting software requirements as appropriate for the project:
- Project stakeholders, including the customer and senior management.
- Software Lead.
- Software Requirements Engineer.
- Systems Engineer.
- Software Architects.
- Software Assurance Engineer.
Elements to Capture
When capturing software requirements, it is important to:
- Document key decisions and the person(s) who made them, for example:
- Which requirements are "must-have."
- Prioritization of requirements.
- Stakeholder decisions that form the basis for requirements.
- Resolutions to conflicting requirements.
- High-level design choices that affect low-level requirements.
- Develop requirement rationales, for example:
- Reasons why one feature or performance requirement was chosen over another.
- Originating document or basis for a requirement, e.g., operational concepts document, trade study, parent requirement.
- Stakeholder expectations.
- Risks which are the basis for a requirement.
- Technology limitations.
- Time constraints.
- Regulations, laws.
- Define assumptions, for example:
- Environmental or any other constraints.
- Mission type (e.g., human-rated vs. robotic).
- Assumed technology availability.
- Preset budgetary restrictions.
- Logically decompose the requirements.
...
- System and subsystem requirements documents, hardware schematics and specifications.
- System architecture.
- System models and simulations.
- System safety analyses, including the preliminary hazard analysis (PHA), subsequent system hazard analyses, and software safety analyses.
- Environmental requirements, including operations and hardware requirements, vehicle or facility requirements.
- Standards.
- External regulations.
- Program/project specification.
- Operational concepts document.
- Interface requirements.
- Legacy products.
- Organizational requirements.
- Quality attributes (e.g., reliability, availability, security, safety, maintainability, portability, usability).
- Structured interviews with customers, users (may include development of scenarios, examination of reports, analysis of competing products), other subsystem engineers (e.g., electrical/electronic and data; thermal; Guidance, Navigation, and Control (GN&C); mechanical).
- Brainstorming sessions with customers, users, developers.
- Stakeholder input or user needs (provided or elicited via interviews, prototypes, questionnaires, surveys, or other techniques).
General Guidance
Some general guidance to follow when defining and documenting software requirements includes:
...
- Failing to define needed requirements, including safety requirements.
- Writing requirements inconsistently or ambiguously.
- Using inexperienced personnel to define the requirements.
- Incorrect understanding of underlying assumptions or constraints.
- Including unneeded features or capabilities.
- No clear method for allocating requirements to software subsystems.
- Choosing solutions before defining the requirements and/or user needs.
- Failing to spend enough time or resources on requirements definition.
| Note |
|---|
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to documenting software requirements, including templates, checklists, and sample documents. |
Guidance for baselining and updating the SRS in preparation for life-cycle milestone reviews can be found in Topic 7.8 - Maturity of Life Cycle Products at Milestone Reviews in this Handbook.
Additional guidance related to documenting software requirements may be found in the following related requirements in this Handbook:
...
...
Software Requirements
...
...
Software Requirements Analysis
...
...
Bidirectional Traceability Between Higher Level Requirements and Software
...
...
Manage Requirements Change
...
...
Software Requirements Specification
...
| id | tabs-4 |
|---|
4. Small Projects
...
| id | tabs-5 |
|---|
5. Resources
...
| toolstable |
|---|
...
| id | tabs-6 |
|---|
6. Lessons Learned
The NASA Lessons Learned database contains the following lessons learned related to defining and documenting software requirements:
...
