bannerb

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

SWE-051 - Software Requirements Analysis

1. Requirements

4.1.2.2 The project manager shall perform software requirements analysis based on flowed-down and derived requirements from the top-level systems engineering requirements and the hardware specifications and design.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

If Class D software is safety critical, this requirement applies to the safety-critical aspects of the software.

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

2. Rationale

Software requirements are the basis of a software project.

Analyzing software requirements allows a team to ensure that they are properly formed and accurately and clearly describe the software system to be built.  Analysis provides a structured method of reviewing requirements to identify any issues with them individually or as a collected set.  The team can address identified issues before using the requirements for further project work.  This reduces the need for future rework, not only of the requirements, but also of any work based on those requirements.

3. Guidance

The software requirements analysis determines the requirement's safety criticality, correctness, consistency, clarity, completeness, traceability, feasibility, verifiability, and maintainability. The software requirements analysis activities include the allocation of functional, non-functional, and performance requirements to functions and sub functions.

It is important to ensure that requirements have been evaluated adequately because incomplete requirements can cause several problems: Incorrect estimates of project resources.

  • Missing or additional design elements.
  • Additional cost and schedule do to rework to correct for missing/incorrect requirements.
  • Added resources for verification and validation.
  • Loss of customer confidence due to improperly described requirements.

Requirements are not incorporated into the software requirements specification until the analysis process has been completed.

The requirements analysis methodology needs to be "measurable or otherwise verifiable." 278 Checklists of questions to consider (such as those included in the Resources section of this guidance) may be helpful.

In light of the operational concept and scenarios, the requirements for one level of the product hierarchy are analyzed to determine whether they are necessary and sufficient to meet the objectives of higher levels of the product hierarchy. The analyzed requirements then provide the basis for more detailed and precise requirements for lower levels of the product hierarchy." 157

Regardless of the methods chosen, the project team documents the methodology used for software requirements analysis in an appropriate project document, such as the Software Development Plan/Software Management Plan (SDP/SMP), and includes some minimum steps:

  • Verify requirements safety criticality, correctness, consistency, completeness.
  • Verify the requirements are clear, precise, unequivocal, verifiable, testable, maintainable, feasible.
  • Verify requirements traceability.
  • Verify that requirements have been properly flowed down from one level to the next (i.e., from the system requirements to the software subsystem requirements and to the various levels of requirements within the software subsystem).
  • Verify that requirements have been properly identified and flowed across from the software interfaces, including all computer hardware requirements and all fault management requirements.
  • Examine the requirements "individually and as an integrated set." 276

The team may perform analysis of software requirements in conjunction with the allocation of requirements to various levels of functions and sub-functions. Guidance on logical decomposition of requirements may be found in SWE-050.

The following roles may be involved in software requirements analysis:

  • Software Requirements Engineers.
  • Software Safety and Assurance personnel.
  • Systems Engineers.
  • Hardware Engineers.
  • Operations.
  • Fault Management Engineers.
  • Customers.

Software requirements analysis begins after the System Requirements Review (SRR). The development team analyzes the software requirements for completeness and feasibility. The development team uses structured or object-oriented analysis and a requirements classification methodology to clarify and amplify the requirements. Prioritizing requirements may also occur as part of requirements analysis. Developers work closely with the requirements definition team to resolve ambiguities, discrepancies, and to-be determined (TBD) requirements or specifications. The theme of reuse plays a prominent role throughout requirements analysis and the design phase. Special emphasis is placed on identifying potentially reusable architectures, designs, code, and approaches.

When requirements analysis is complete, the development team prepares a summary requirements analysis report and holds a Software Requirements Review (SwRR). During the SwRR, the development team presents the results of their analysis for evaluation. Following the SwRR, the requirements definition team updates the requirements document to incorporate any necessary modifications and the requirements analysis is revised based on changes to requirements made after SwRR. This revision work is completed by Preliminary Design Review (PDR) at the same time the requirements are finalized.

Software requirements analysis is a continuous activity performed on all software requirements and software requirement changes.

Use of formal inspections is an excellent method of reviewing requirements with stakeholders because it brings multiple viewpoints to bear and also achieves a common understanding of the requirements. Information on formal inspections can be found in SWE-087. Software peer reviews/inspections (SWE-088, SWE-089) are a recommended best practice for all safety and mission-success related requirements, design and code software components. Guidelines for software peer reviews/inspections are contained in the NASA Software Formal Inspections Standard (NASA-STD-2202-93). 277

Determine safety criticality

Software safety personnel need to be involved in the analysis of software requirements to determine their safety criticality. Software safety personnel analyze software requirements in terms of safety objectives to determine whether each requirement has safety implications. Those requirements with safety implications are designated, marked, and tracked as "safety-critical."

Additional analysis steps typically performed by software safety personnel include:

  • Verification that software safety requirements are derived from appropriate parent requirements, include modes, states of operation, and safety-related constraints, and are properly marked.
  • Verification that software safety requirements "maintain the system in a safe state and provide adequate proactive and reactive responses to potential failures."      

Additional information on analysis performed by software safety personnel can be found in the NASA Software Safety Standard (NASA-STD-8719.13) 271and the NASA Software Safety Guidebook 276.

Determine correctness

Requirements are considered correct if they "respond properly to situations" 001 and are appropriate to meet the objectives of higher-level requirements. A method for determining correctness is to compare the requirements set against operational scenarios developed for the project.

Determine consistency

Requirements are consistent if they do not conflict with each other within the same requirements set and if they do not conflict with system (or higher-level) requirements. It is helpful to have at least one person read through the entire set of requirements to confirm the use of consistent terms/terminology throughout.

Determine clarity

Requirements are clear if they are precise, unequivocal, and unambiguous ("can only be interpreted one way" 001) both individually and as a collection. Requirements need to be concise, "stated as briefly as possible without affecting meaning." 001

Suggested methods for confirming the clarity of requirements include:

  • Reading the requirements and their supporting documents.
  • Formal inspection.

Determine completeness

Requirements are complete if there are no omissions or undefined conditions in the requirements set. Requirements are also complete if there are no "TBDs" in the requirements set.

Suggested methods for confirming the completeness of requirements include:

  • Reading the requirements and their supporting documents.
  • Formal inspection.
  • Reviewing the requirements set to confirm that availability, installation, maintainability, performance, portability, reliability, safety, security, and other requirements are included as appropriate to the project. 061
  • Reviewing the requirements set to confirm they are "sufficiently complete to begin design." 061
  • Reviewing the requirements to confirm they have any necessary accompanying rationale and verifiable assumptions. 086
  • Review the requirements set against operational scenarios developed for the project.

Determine traceability

When determining requirement traceability, the team ensures that requirements trace bi-directionally so that all software requirements have a parent (higher level) requirement and all levels of software requirements and flowed down to the appropriate detailed (lower) levels for implementation. In order for requirements to be properly traced, they are also uniquely identified.

Suggested methods for this type of analysis include:

  • Trace requirements from parent/source documents into the software requirements specification and vice versa.
  • Reviewing existing traceability matrices for completeness and accuracy (SWE-052).
  • Reviewing the requirements set to confirm there are no "extra" or "unneeded" requirements (those not necessary to meet the parent requirement).
  • Reviewing the requirements to confirm all performance requirements are realistic.

Determine feasibility

Technically feasible requirements are reasonable, realistic requirements that can be implemented and integrated together successfully to meet the operational concepts and system requirements of the project within the given operating environment, budget, schedule, available technology, and other constraints. 061

Suggested methods for this type of analysis include:

  • Reviewing requirements to confirm they do not "overly constrain the design." 061
  • Reviewing the requirements to confirm they do not unnecessarily "necessitate the use of non-standard, unusual, or unique hardware or software." 061
  • Review the requirements to confirm they are appropriate for the operation and maintenance of the project.

Determine verifiability

Requirements are verifiable if they are testable, if there is “a technique to verify and/or validate the requirement."  001 Suggested techniques include testing, demonstration, inspection, and analysis.

Suggested methods for determining if requirements are verifiable include:

  • Reviewing the requirements to confirm that they use verifiable terms (e.g., do not use terms such as "easy," "sufficient," "adequate").
  • Reviewing the requirements set to confirm requirements are "stated precisely to facilitate specification of system test success criteria." 086
  • Reviewing the requirements to confirm that there is at least one feasible method identified to verify the requirement

Determine maintainability

Requirements are maintainable if they are "written so that ripple effects from changes are minimized (i.e., requirements are as weakly coupled as possible)."  086 Maintainability can be achieved, by reviewing the requirements set looking for unnecessarily coupled or interdependent requirements.

Communicate outcome

Although not part of the engineering requirement, it is recommended that results of software requirements analysis be captured in the project documentation and communicated to those who need this information to make decisions or to develop (or update) project documents. The stakeholders and the project will decide how to address the results of the analysis, including any changes that need to be made to address findings. The methodology used for the software requirements analysis and the results of the software requirements analysis are communicated at multiple project formal reviews as defined in the software development or management plan. Specifically, according to the NASA Software Safety Standard (NASA-STD-8719.13) 271 , "The provider software safety requirements analysis will be available to the acquirer and the acquirer SMA [Safety and Mission Assurance] for program, project, and facility formal reviews, system-level safety reviews, and upon acquirer request." 271

When capturing the results of software requirements analysis, consider the following content:

  • Purpose and background of the project, overall system concepts, and document overview.
  • Key reuse candidates and overall architectural concept for the system.
  • Updates to operations concepts resulting from work performed during the requirements analysis phase.
    • Updated operations scenarios.
    • Operational modes, including volume and frequency of data to be processed in each mode, order and type of operations, etc.
    • Updated descriptions of input, output, and messages.
  • Specification analysis
    • Summary of classifications (mandatory, derived, "wish list," information only, or TBD) assigned to requirements and functional specifications.
    • Problematic specifications (identification and discussion of conflicting, ambiguous, infeasible, untestable, and TBD requirements and specifications).
    • Unresolved requirements/operations issues, including the dates by which resolutions are needed
    • Analysis of mathematical algorithms.
  • System constraints
    • Hardware availability (execution, storage, peripherals).
    • Operating system limitations.
    • Support software limitations.
  • Development assumptions.
  • Risks, both to costs and schedules, including risks related to TBD or changing requirements, as well as technical risks.
  • Prototyping efforts needed to resolve technical risks, including the goals and schedule for each prototyping effort.
  • Data flow or object-oriented diagrams (results of all functional decomposition or object-oriented analysis of the requirements performed during the requirements analysis phase).
  • Data dictionary for the updated processes, data flows, and objects shown in the diagrams.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to software requirements analysis, including relevant checklists.

NASA-specific requirements analysis process information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to software requirements analysis may be found in the following related requirements in this Handbook:

SWE-050

Software Requirements

SWE-052

Bidirectional Traceability Between Higher Level Requirements and Software Requirements

SWE-053

Manage Requirements Change

SWE-087

Software Peer Reviews and Inspections for Requirements, Test Plans, Design, and Code

SWE-088Software Peer Reviews and Inspections - Checklist Criteria and Tracking
SWE-089Software Peer Reviews and Inspections - Basic Measurements

4. Small Projects

Projects with small budgets or limited personnel may choose to limit the number of reviews involved in software requirements analysis. It is important in this situation to avoid skipping any important analysis activities. Consider using checklists or other guides to ensure all analysis elements are addressed.

Additionally, multiple roles may be filled by a single person on small projects, so it may be helpful to request assistance from experts outside the project when conducting requirements analysis. These persons can provide "fresh eyes" as well as specific key perspectives that may not be available on the core project team.

5. Resources

  • (SWEREF-001) Software Development Process Description Document, EI32-OI-001, Revision R, Flight and Ground Software Division, Marshall Space Flight Center (MSFC), 2010. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.

  • (SWEREF-057) Software Management Plan (SMP) Template, GRC-SW-TPLT-SMP, NASA Glenn Research Center (GRC), 2009. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.

  • (SWEREF-061)

    JPL Document D-24994, NASA Jet Propulsion Laboratory, 2003. See Page 20. Approved for U.S. and foreign release.

  • (SWEREF-086)

    5526_7-21-06_Req_RevA_generic-R1V0, 2006. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.

  • (SWEREF-105) Software System/Subsystem Requirements Specifications (SSRS) Checklist, NASA Marshall Space Flight Center (MSFC) , 2012. This NASA-specific information and resource may be available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.

  • (SWEREF-157)

    CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.

  • (SWEREF-174)

    Department of Defence Systems Management College, Supplementary text prepared by the Defense Acquisition University Press, Fort Belvoir, VA, 2001.

  • (SWEREF-189) Writing an SRS, Foster, C.M. (1993). Analex Corporation for Glenn Research Center. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.

  • (SWEREF-271)

    NASA STD 8719.13 (Rev C ) , Document Date: 2013-05-07

  • (SWEREF-276)

    NASA-GB-8719.13, NASA, 2004.

  • (SWEREF-277)

    NASA-STD-8739.9, NASA Office of Safety and Mission Assurance, 2013. Change Date: 2016-10-07, Change Number: 1

  • (SWEREF-278)

    NASA-STD-8739.8A , NASA TECHNICAL STANDARDS SYSTEM, Approved 2020-06-01 Superseding "NASA-STD-8739.8, With Change 1" https://standards.nasa.gov/standard/osma/nasa-std-87398

  • (SWEREF-559)

    Public Lessons Learned Entry: 1501.

  • (SWEREF-576)

    Public Lessons Learned Entry: 3377.

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

Tool nameTypeOwner/SourceLinkDescriptionUser

WinMerge

Open Source

http://winmerge.org/ ...

"WinMerge is an Open Source differencing and merging tool for Windows. WinMerge can compare both folders and files, presenting differences in a visual text format that is easy to understand and handle."

IV&V

Together

COTS

Micro Focus

https://www.microfocus.com/products/requirements-management/together/ ...

Together® is a modeling platform that gives enterprise teams leading-edge design capabilities which enable the visualization and continued maintenance of IT architectures.

IV&V

RequirementsLink

COTS

ENSER/Parametric Technology Corporation (PTC)

http://www.ptc.com/appserver/wcms/relnotes/note.jsp?icgdbkey=826imdbkey=119829 ...

Windchill RequirementsLink. Requirements capture and tracking tool. Windchill RequirementsLink - an integral option for Windchill PDMLink - lets you manage product requirements, including change control and associating requirements with specific product structures and design content. With bi-directional traceability between customer needs, market requirements and the underlying technical requirements, you can ensure that customer and market requirements are satisfied by designs, and properly verified during development.

SSC

Rational Clearquest

COTS

IBM Rational

http://www-01.ibm.com/software/awdtools/clearquest/ ...

Change management software that helps improve developer productivity while accommodating the methodologies, processes and tools that best fit the project and the people on the team. This software provides tools and processes that allow you to maintain control of changes while catering to the diverse needs of the developer.

IV&V, JSC

PTC Integrity

COTS

PTC

http://www.ptc.com/application-lifecycle-management/integrity/lifecycle-manager ...

PTC Integrity is a systems and software lifecycle management (SSLM) and application lifecycle management (ALM) platform used for Process automation and workflow management

IV&V, GSFC

MinGW

Open Source

MinGW

http://www.mingw.org/ ...

MinGW, a contraction of "Minimalist GNU for Windows", is a minimalist development environment for native Microsoft Windows applications.

IV&V

IBM Rhapsody

COTS

IBM Rational

http://www-01.ibm.com/software/awdtools/rhapsody/ ...

"IBM® Rational® Rhapsody® family provides collaborative design and development for systems engineers and software developers creating real-time or embedded systems and software. Rational Rhapsody helps diverse teams collaborate to understand and elaborate requirements, abstract complexity visually using industry standard languages (UML, SysML, AUTOSAR, DoDAF, MODAF, UPDM), validate functionality early in development, and automate delivery of innovative, high quality products." (NOTE: Several versions are listed on the website for architecture, system engineering requirements analysis, design and model management, simulations to validate requirements and analyze architecture, and code generation. Unsure which versions are used within NASA. Listed requirements are those related to these topics.)

IV&V GSFC ?

GUESS

Open Source

Sourceforge

http://graphexploration.cond.org/ ...

GUESS is an exploratory data analysis and visualization tool for graphs and networks. The system contains a domain-specific embedded language called Gython (an extension of Python, or more specifically Jython) which supports the operators and syntactic sugar necessary for working on graph structures in an intuitive manner. GUESS also offers a visualization front end.

IV&V

Enterprise Architect

COTS

Sparx Systems, Inc.

http://www.sparxsystems.com/ ...

Enterprise Architect provides complete traceability from requirements, analysis and design models, through to implementation and deployment. ...

IV&V

DOORS®

COTS

IBM® Rational®

http://www-01.ibm.com/software/awdtools/doors/ ...

IBM® Rational® DOORS® family is a group of requirements management tools that allow you to capture, trace, analyze and manage changes across the development lifecycle.

ARC, DFRC, GRC, GSFC, IV&V, JPL, JSC, JSC, LaRC, MSFC,

Beyond Compare

COTS

Scooter Software, Inc.

http://scootersoftware.com/ ...

Beyond Compare allows you to quickly and easily compare your files and folders. By using simple, powerful commands you can focus on the differences you're interested in and ignore those you're not. You can then merge the changes, synchronize your files, and generate reports for your records. Ver 4.2.5.

LaRC

Understand

COTS

Scientific Toolworks, Inc.

http://www.scitools.com/ ...

Understand is a static analysis tool for maintaining, measuring, & analyzing critical or large code bases.

IV&V

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to software requirements analysis:

  • Software Requirements Management. Lesson Number 3377: "Cost and schedule impacts that result from incomplete, incorrect, or changing software requirements increase the later they occur in the software life cycle." 576
  • Orbital Space Plane - Stay true to the process! (Contributor to Orbital Space Plane (OSP) problems.) Lesson Number 1501: "Development of the Level 2 requirements did not follow established systems engineering guidelines for allocation, inclusion of performance and functional requirements, validation, and feasibility assessments. ... Requirement development, analyses, and system design activities were not synchronized. Functional decomposition was not complete before system design started and before Level 3 requirements were base-lined. ... The process for demonstrating requirements feasibility was unclear." 559
  • No labels