bannerd


SWE-051 - Software Requirements Analysis

1. Requirements

4.1.3 The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, 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 History

SWE-051 - Last used in rev NPR 7150.2D

RevSWE Statement
A

3.1.1.3 The project 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.

Difference between A and B

No change

B

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.

Difference between B and C

Added requirement to perform software requirements analysis based on safety and reliability analyses.

C

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

Difference between C and DNo change
D

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



1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


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.  The analysis provides a structured method of reviewing requirements to identify any issues with them individually or as a collected set.  The team should 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 safety criticality, correctness, consistency, clarity, completeness, traceability, feasibility, verifiability, and maintainability of the requirements. The software requirements analysis activities include the allocation of functional, non-functional, and performance requirements to all functions.

Faulty requirements may be due to incomplete, unnecessary, contradictory, unclear, unverifiable, untraceable, incorrect, in conflict with system performance requirements, otherwise poorly written, or undocumented requirements. It is important that operators properly identify and document safety requirements, and per industry standards, ensure that safety requirements are internally consistent and valid at the system level for the resulting computing system to work safely throughout its lifecycle.

After documenting the Software Requirements, run them through a requirements analysis tool (e.g., QVScribe) to analyze their quality. (QVScribe access may be obtained via a NAMS request.)


Software requirement analysis must be performed on all safety-critical software requirements on Class A, B, and C software.  This software requirement analysis should be performed on Class D software but is not required.

It is important to ensure that requirements have been evaluated adequately for completeness because incomplete requirements can cause several problems:

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

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.

CMMI for Development, Version 1.3: Improving processes for developing better products and services

Requirements Analysis - Analyze requirements to ensure that they are necessary and sufficient - SP3.3
"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."
"As products are defined, their relationship to higher level requirements and the higher level definition of the functionality and quality attributes should be understood. Also, the key requirements used to track progress are determined. For instance, the weight of a product or size of a software product can be monitored through development based on its risk or its criticality to the customer."
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, and completeness.
  • Verify the requirements are clear, precise, unequivocal, verifiable, testable, maintainable, and 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 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 and fault management requirements.
  • Examine the requirements "individually and as an integrated set." 276


The analysis of software requirements is performed in conjunction with the allocation and decomposition of requirements. Guidance on the logical decomposition of requirements may be found in SWE-050 - Software Requirements.

The following roles may be involved in software requirements analysis:

  • Software Requirements Engineers including Software Engineers and Developers
  • Software Safety Engineers, Software Assurance, Safety Assurance
  • Systems Engineers
  • Hardware Engineers
  • Cybersecurity Engineers
  • Operations Engineers
  • Fault Management Engineers
  • Customers/Users

Software requirements analysis begins after the System Requirements Review (SRR) milestone. The development team analyzes the software requirements for completeness and feasibility. The development team may use a structured or object-oriented analysis and a requirements classification methodology to clarify and augment 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. Special emphasis should be placed on software reuse throughout the requirements analysis and the design phase, identifying potentially reusable architectures, designs, code, and approaches.

When the 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 may need to update the requirements specification to incorporate any necessary modifications. 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 baselined. The Entry/Exit Criteria for the SwRR milestone review are defined in Topic 7.09 - Entrance and Exit Criteria.

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

The 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 and Inspections for Requirements, Plans, Design, Code, and Test Procedures. Software peer reviews/inspections (SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking, SWE-089 - Software Peer Reviews and Inspections - Basic Measurements) 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 Topic 7.10 - Peer Review and Inspections Including Checklists.

3.1 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 and tracked as "safety-critical."

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 (5.08 - SDP-SMP - Software Development - Management Plan), and includes some minimum steps:

  • Verify requirements safety criticality, correctness, consistency, and completeness.
  • Verify the requirements are clear, precise, unequivocal, verifiable, testable, maintainable, and 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 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 and fault management requirements.
  • Examine the requirements "individually and as an integrated set." 276

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

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 the requirements analysis and the design phase. Special emphasis is placed on identifying potentially reusable architectures, designs, codes, and approaches. See 7.09 - Entrance and Exit Criteria

When the 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. See SWE-053 - Manage Requirements Changes

The 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 and Inspections for Requirements, Plans, Design, Code, and Test Procedures. Software peer reviews/inspections (SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking, SWE-089 - Software Peer Reviews and Inspections - Basic Measurements) 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 See also Topic 7.10 - Peer Review and Inspections Including Checklists

3.1 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 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 the analysis performed by software safety personnel can be found in the Topics 8.54 - Software Requirements Analysis and 8.58 - Software Safety and Hazard Analysis of this Handbook (NASA-HDBK-2203). 

The criterion for determining software safety criticality is defined in NASA-STD-8739.8.

See also PAT-034 - SAANALYSIS Checklist

3.2 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.

3.3 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. Some examples of inconsistencies are using different terminology, values, or units of measure in different places when in fact they should be the same terminology/value/unit. It is helpful to have at least one person read through the entire set of requirements to confirm the use of consistent terms/terminology/values/units throughout. A requirements analysis tool may also be able to catch some of these inconsistencies.

3.4 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 the meaning." 001

Suggested methods for confirming the clarity of requirements include:

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

3.5 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 supporting documents including the requirements traceability.
  • 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
  • Review the requirements to confirm they are "sufficiently complete to begin design." 061
  • Review the requirements to confirm they have any necessary accompanying rationale and verifiable assumptions. 086
  • Review the requirements set against nominal and off-nominal operational scenarios developed for the project.
  • Review the requirements using the various requirements checklists specified in Section 3.11 below.

3.6 Determine traceability

When determining requirement traceability, the team ensures that requirements are traced bi-directionally so that all software requirements have a parent (higher level) requirement, and all levels of software requirements flow down to the appropriate detailed (lower) levels for implementation. 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.
  • Review existing traceability matrices for completeness and accuracy (SWE-052 - Bidirectional Traceability).
  • Review the requirements set to confirm there are no "extra" or "unneeded" requirements (those not necessary to meet the parent requirement).

3.7 Determine feasibility

Technically feasible requirements are reasonable, realistic requirements that can be implemented and integrated 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.
  • Reviewing the requirements to confirm all requirements are realistic including performance requirements.

3.8 Determine verifiability

Requirements are verifiable if they are testable. They are also verifiable if there is “a technique to verify and/or validate the requirement."  001 Suggested techniques include testing, demonstration, inspection, and analysis. Engineering and Software Assurance have a joint responsibility for ensuring the requirements are verifiable.

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," and "adequate").
  • Reviewing the requirements set to confirm requirements are "stated precisely to facilitate specification of system test success criteria." 086
  • Confirming that there is at least one feasible method/technique identified to verify the requirement

3.9 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 and looking for unnecessarily coupled or interdependent requirements.

3.10 Communicate outcome

Although not considered a software engineering product, it is recommended that the 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 the findings. The methodology used for the software requirements analysis and the results of the software requirements analysis is communicated at multiple project formal reviews as defined in the software development or management plan. Specifically, according to the NASA Software Assurance and Software Safety Standard (NASA-STD-8739.8). Guidance for the analysis report content may be found in Topic 5.21 - Software Requirements Analysis Report Minimum Content

3.11 Requirements Checklists

There are several checklists that aid in the analysis of software requirements. They look at the various aspects described in the previous sections. The available requirements checklists are:

3.12 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.13 Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

SPAN Links

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.

A requirements analysis tool (e.g., QVScribe) that is free to the project or available at a reduced cost may be used to analyze the requirements.

5. Resources

5.1 References

  • (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-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. Access NASA-GB-8719.13 directly: https://swehb.nasa.gov/download/attachments/16450020/nasa-gb-871913.pdf?api=v2
  • (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.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
  • (SWEREF-559) Public Lessons Learned Entry: 1501.
  • (SWEREF-576) Public Lessons Learned Entry: 3377.

5.2 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

5.3 Process Asset Templates

SWE-051 Process Asset Templates
Click on a link to download a usable copy of the template. 

Requirements Development and Analysis Assets Process Asset Templates
Click on a link to download a usable copy of the template. (ReqAn)

6. Lessons Learned

6.1 NASA Lessons Learned

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

  • Software Requirements Management. Lesson Number 3377 576 : "Cost and schedule impacts that result from incomplete, incorrect, or changing software requirements increase the later they occur in the software life cycle."
  • Orbital Space Plane - Stay true to the process! (Contributor to Orbital Space Plane (OSP) problems.) Lesson Number 1501 559: "Development of the Level 2 requirements did not follow established systems engineering guidelines for allocation, the 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."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

SWE-051 - Software Requirements Analysis
4.1.3 The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design. 

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Perform a software assurance analysis on the detailed software requirements to analyze the software requirement sources and identify any incorrect, missing, or incomplete requirements.

7.2 Software Assurance Products

  • From SWE-050 - Software Requirements, The results of the independent SA analysis performed on the detailed software requirements, including the list of requirements issues identified and records in a problem tracking system.


    Objective Evidence

    • Software requirements.
    • Software requirements analysis results or report.

    Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

    • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
    • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
    • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
    • Signatures on SA reviewed or witnessed products or activities, or
    • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
      • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
      • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
    • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

  • # of software work product Non-Conformances identified by life cycle phase over time
  • # of Software Requirements (e.g., Project, Application, Subsystem, System, etc.)
  • # of Software Requirements that do not trace to a parent requirement   
  • Defect trends for trace quality (# of circular traces, orphans, widows, etc.)
  • # of detailed software requirements vs. # of estimated SLOC to be developed by the project
  • # of incorrect, missing, and incomplete requirements (i.e., # of requirements issues) vs. # of requirements issues resolved
  • # of safety-related requirement issues (Open, Closed) over time
  • # of safety-related non-conformances identified by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Deficient requirements are the largest single factor in software and computing system project failure, and deficient requirements have led to a number of software-related aerospace failures and accidents.

Faults in requirements can originate from the adoption of requirements that are incomplete, unnecessary, contradictory, unclear, unverifiable, untraceable, incorrect, in conflict with system performance requirements, otherwise poorly written, or undocumented. It is important that operators properly identify and document safety requirements, and per industry standards, ensure that safety requirements are internally consistent and valid at the system level for the resulting computing system to work safely throughout its lifecycle.

Software Assurance and software safety should perform an independent SA analysis of the detailed software requirements as they are developed.  Use the guidelines in the 8.54 - Software Requirements Analysis. See tab 2, SW Requirements Analysis Techniques.

Make sure that the detailed software requirements include or point to requirements for COTS, GOTS, MOTS, OSS, or reused software components that are part of the software system. 

NASA Missions go through a logical decomposition in defining their requirements. Requirements analysis addresses a system’s software requirements including analysis of the functional and performance requirements, hardware requirements, interfaces external to the software, and requirements for qualification, quality, safety, security, dependability, human interfaces, data definitions, user requirements, installation, acceptance, user operation, and user maintenance.  

When evaluating the software requirements, use the list of items in the SA Requirements Analysis Checklist PAT-034:


Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

PAT-034 - SAANALYSIS Checklist

There are several additional checklists that aid in the analysis of software requirements. They look at the aspects various aspects described on tab 3. The other available requirements checklists are:


Consider if the requirements being analyzed are SMART requirements “specific, measurable, attainable (achievable/actionable/appropriate), realistic, timebound (timely, traceable)”.

To confirm that the software requirements satisfy the conditions in SWE-051 make sure that the flowed down and derived requirements are from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design.

Software safety personnel need to be involved in the analysis of software requirements to determine their safety-criticality. Any software requirements that trace are determined to have safety implications. Those requirements with safety implications are tracked as "safety-critical."

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

  • No labels