1. Requirements

4.1.5 The project manager shall track and manage changes to the software requirements. 

1.1 Notes

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

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Requirements change management helps ensure alignment between the software requirements and the project’s software plans and software work products. Collecting, analyzing, and managing requirements changes allow a project to control those changes and measure their impact. Requirements change management can also provide early insights into the impact of those changes to the overall project's budget and schedule, including the ability to plan how to address changes rather than simply reacting when a change is made.

3. Guidance

3.1 Requirements Changes

Quoting Wikipedia, “Requirements Management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project.”

As a project progresses and requirements are flown down, the requirements are decomposed into functional and performance requirements and allocated across the system. These are then further decomposed and allocated among the elements and subsystems. This decomposition and allocation process continues until a complete set of design-to requirements is achieved. During this process, it may become apparent that there are requirements that are missing, conflicting, unfeasible, etc. resulting in the need to modify the baselined requirements set. When changes to the requirements are required, it becomes necessary to track and manage those changes.

Requirements management practices control how requirements are introduced, changed, and removed. The average project experiences changes in requirements after the requirements have been defined for the first system release, which causes schedule slip.

Several studies also have shown that volatility in requirements contributes to the inefficient production of low-quality software. Consequently, requirements should be managed using a defined configuration management process that uses Change Control Boards (CCBs) and automated change control tools that manage each requirement as a separate item. Using a configuration management tool permits personnel to identify which requirements have been added, removed, or changed since the last baseline (requirements volatility), who has made these changes, when they were made, and the reason for making them. In addition, by maintaining requirements in a configuration management tool, they can be traced to the artifacts that realize them.

Changes to requirements can be an indicator of software instability or unclear description of the end product. Regardless of the reason, requirement changes often mean increased costs, longer schedules, and changes in the technical features of the software. Changes in requirements can result in rework and can affect software safety.

The actual process of making changes should be a structured, defined process. This process should describe how a proposed change is submitted, evaluated, decided upon, and incorporated into the requirements baseline. Usually, a Change Control Board, consisting of people from various disciplines and perspectives, will review potential changes and either approve or reject them. A requirements management tool can help manage the changes made to many individual requirements, maintain revision histories, and communicate changes to those affected by them.

Part of the change management process should be an evaluation of the impact the change will have on the system and other requirements especially safety and security requirements. See SWE-080 - Track and Evaluate Changes for guidance on impact analysis, including cost, technical, and schedule impacts. Traceability information is an important tool in this evaluation. See SWE-052 - Bidirectional Traceability for guidance on requirements traceability.

Requirements management also includes the management of the software data dictionary content or ICD content.  Examples of the content contained in a software data dictionary may be found in topic 5.07 - SDD - Software Data Dictionary. Examples of content contained in an Interface Control Document (ICD) may be found in a future topic.

Keep in mind that managing changes to requirements is an ongoing process that occurs throughout the project life cycle and needs to be planned for during project planning activities.

See also SWE-050 - Software Requirements, SWE-051 - Software Requirements Analysis.

3.2 Capture And Manage The Changes

Consider using configuration management tools, requirements management tools, or change request tools to capture changes to requirements. Many of these tools will keep version histories and are able to provide reports on the changes. Some of those reports may be useful to management when analyzing the impact of the requirements changes on the project.

Regardless of the capture method, projects need to collect a minimum set of data to describe the requested change.  See topic 5.01 - CR-PR - Software Change Request - Problem Report, for more information.

As part of managing requirements changes, the team needs to keep in mind the effect of "requirements creep" on software development, including its costs and complexity. Those performing impact analyses or approving/disapproving requirements changes need to carefully scrutinize requests to avoid approving enhancements not required to accomplish the project goals and objectives.

3.3 Analyze The Changes For Cost, Technical, And Schedule Impacts

Once change requests are documented, the team analyzes them for their effect on all parts of the software system as well as their effect on the overall system and project, as applicable to the level of change. Typically, changes are reviewed by a CCB or other review board (see SWE-082 - Authorizing Changes) who can request or perform an impact analysis (see SWE-080 - Track and Evaluate Changes) before determining how to disposition the change. 

When performing an analysis on the changes, look for impacts such as:

• Impact on other parts of the software system (not just the immediate design or code where the change will occur): architecture, design, interfaces, the concept of operations, higher- and lower-level requirements.
• Impact on other parts of the overall system (e.g., system requirements, interfaces, hardware).
• Safety, reliability, performance impacts.
• Skills needed (e.g., special expertise, additional developers, consultants).
• Rework effort (e.g., requirements specification, design, code, test, user manuals).
• New effort (e.g., code development, documentation, test case development, software assurance).
• Impact to stakeholders.
• Potential to introduce errors into the software.
• The criticality of the affected software.

Traceability matrices and tools are useful when determining the impact of a change, but the team needs to update the traceability information to keep it current as changes to the requirements occur (see SWE-052 - Bidirectional Traceability).  Other relevant items, from NASA/SP-2016-6105 Rev 2, NASA Systems Engineering Handbook ²⁷³, include:

• Performance margins – "a list of key performance margins for the system and the current status of the margin... the propellant performance margin will provide the necessary propellant available versus the propellant necessary to complete the mission."
• Configuration management top evaluators list – "appropriate persons [to evaluate] the changes and providing impacts to the change... changes need to be routed to the appropriate individuals to ensure that the change has had all impacts identified."
• Risk system and threats list – "used to identify risks to the project and the cost, schedule, and technical aspects of the risk...A threat list is normally used to identify the costs associated with all the risks for the project."

The team uses the results of the impact assessment to determine the effect the change has on the project in terms of:

• Cost including personnel and equipment costs.
• Schedule including new or revised design, development, testing, and documentation effort.
• Technical impacts on the function of the software and overall system.

3.4 Document Analysis Results

Document and maintain the results of the impact analysis and any decisions based on that analysis with the project's records. Communicate the results to the appropriate stakeholders, i.e., project personnel who must implement approved changes, must update documentation related to those changes, or must test those changes; system-level personnel who must coordinate changes in response to this requirements change; as well as those affected if a requested change is not approved for implementation, including stakeholders outside the development team.

See also Topic 5.09 - SRS - Software Requirements Specification

3.5 Other Tasks

In addition to the activities noted above, managing changes to requirements may also include the following:

• Ensuring that relevant project plans are updated to reflect approved requirements changes.
• Ensuring change requests are created, assigned, and completed for work products affected by approved requirements changes, e.g., design documents, user manuals, interface specifications.
• Ensuring changed requirements and all related changed work products are verified and validated.
• Ensuring traceability documents are updated to reflect the requirements change.
• Ensuring that the rest of the project uses only the latest, updated project documents that reflect the requirements change.

3.6 Additional Guidance

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

3.7 Center Process Asset Libraries

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

4. Small Projects

For projects with limited budgets or staff, spreadsheet programs (e.g., Excel workbooks) may be used to manage the requirements and track changes to them.

When the number of requirements is large and a project can afford it, a database may be appropriate. The database may contain a combination of a requirements management tool, a change management tool, and/or a change request tool can make managing changes easier for the project.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

The NASA Lessons Learned database contains the following lesson learned related to managing requirements change:

• Lewis Spacecraft Mission Failure Investigation Board (Indirect contributors to loss of spacecraft.) Lesson Number 0625: ⁵¹²  "These indirect contributors [to the loss of the spacecraft] are to be taken in the context of implementing a program in the Faster, Better, Cheaper mode: Requirement changes without adequate resource adjustment."
• Software Requirements Management, Lesson Number 3377:   ⁵⁷⁶ "The legacy (manual) methods for managing the implementation of software requirements for the Space Shuttle Program have had a major impact on cost and schedule over the entire software development life cycle." 
• Requirements Management Process and Database, Lesson Number 23801:  ⁴⁴¹  The Ground Systems Development and Operations (GSDO) Program implemented Cradle, a Commercially available requirements management tool. "Cost and schedule impacts occurred due to a number of issues with how the requirements were structured, allocated and closed. System acceptance or certification reviews were delayed due to the lack of an efficient process for closing requirements or making closure evidence available in configuration-managed repositories. Significant resources were needed in order to correct problems with the GSDO Program’s requirements set and the allocation, management and closure of requirements." 

6.2 Other Lessons Learned

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

7. Software Assurance

7.1 Tasking For Software Assurance

7.2 Software Assurance Products

Issues and concerns from the requirements volatility trending

7.3 Metrics

• Software Requirements volatility (# of requirements added, deleted, or modified; # of TBDs over time, Percentage)
• The trend of change status over time (# of changes approved, # in implementation, # in test, # closed)
• The trend of Open vs. Closed Non-Conformances over time
• # of incorrect, missing, and incomplete requirements (i.e., # of requirements issues) vs. # of requirements issues resolved

          Note: Metrics in bold type are required for all projects. 

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Confirm the software requirements changes (e.g., CRs) are documented, tracked, approved, and maintained throughout the project life cycle.

1. Software assurance should analyze all proposed changes for impacts, looking closely at any impacts the change may have in any of the software related to safety or security. The analysis should also consider whether there will be any impacts on existing interfaces or the use of any COTS, GOTS, MOTS, or reused software in the system and whether the change will impact any future maintenance effort. Any identified risks should be brought up in the CCB meeting to discuss approval/rejection of the change.
2. Confirm:

• • That the project tracks the changes

Software assurance will check to see that any changes that are submitted are properly documented and tracked through all the states of resolution (investigation, acceptance/rejection, implementation, test, closure) in the project tracking system.

• • That the changes are approved and documented before implementation

Software assurance should track the changes from their submission to their closure or rejection. Initially, SA should confirm that all changes follow the change management process that the project has established. Initially, the change will be documented and submitted to the authorizing CCB for consideration. The authorizing CCB (which will include a software assurance person) will evaluate any changes for impacts. See SWE-082 - Authorizing Changes. 

If the software is safety-critical, the responsible software assurance personnel will perform software safety change analysis to evaluate whether the proposed change could invoke a hazardous state, affect a control for a hazard, condition, or state, increase the likelihood or severity of a hazardous state, adversely affect safety-critical software, or change the safety criticality of an existing software element.  It needs to be kept in mind that changes to the hardware or the software can impact the overall system’s safety and while the focus is on software changes, the software also needs to be aware of changes to the hardware that may impact how software controls, monitors and analyzes inputs from that hardware.  Hardware and software changes can alter the role of software from non-safety-critical to safety-critical or change the severity from moderate to critical. 

Some other considerations for the evaluation of changes:

• • • Is the change an error correction or a new requirement?
    • Will the change fix the problem without major changes to other areas?
    • If major changes to other areas are needed, are they specified, and is this change really necessary?
    • If the change is a requirements change, has the new requirement been approved?
    • How much effort will be required to implement the change?
    • If there is an impact on safety or reliability, are there additional changes that need to be made in those areas? Note: If there is a conflict between safety and security, safety changes have priority.

When all the impacts are considered, the CCB votes on acceptance/rejection. Software assurance is a voting member of the CCB.  Software assurance verifies that the decision is recorded and is acceptable, defined as:

• When the resolution is to “accept as is”, verify that the impact of that resolution on quality, safety, reliability, and security is compatible with the Project’s risk posture and is compliant with NPR 7150.2 and other Center and Agency requirements for risk.
• When the resolution is a change to the SW, the change will sufficiently address the problem and will not impact quality, safety, reliability, security, and compliance with NPR 7150.2; the change will not introduce new or exacerbate other, discrepancies or problems.
• In either case, the presence of other instances of the same kind of discrepancy/problem has been sought out and, if detected, addressed accordingly.
• Verify that appropriate software severity levels are assigned and maintained.
• Assure any risk associated with the change is added to the Project/facility risk management system and is addressed, as needed, in safety, reliability, or other risk systems
• • That the implementation of the changes is complete

Software assurance will check to see if the implementation of the approved changes has been coded as per the change request. Check to see that any associated documentation changes are submitted/approved and/made as needed (i.e., updates to requirements, design, test plans/procedures, etc.)

• • That the project tests the changes

Software assurance will check to see that the project test any of the code that has changed and runs a set of regression tests to see that the change has not caused a problem anywhere else in the software system. If the software is safety-critical, a full set of regression tests should be run to ensure that there was no impact on the safety-critical functions.

3. Confirm software changes are done in the software control process

Software assurance will check that the software control process has been followed throughout the handling of the submitted change and that the status of the change is recorded and confirmed as closed.

Develop any issues and concerns from the requirements volatility trending.

Requirements volatility is the change in requirements (added, deleted, and modified) over a given time interval.  The success of software projects is dependent on the quality of requirements. Requirements are the basis for planning project schedules as well as for designing and testing specifications.

Examples:

Software requirements volatility is expected during the early stages of a project (conceptualize / requirements phase). It becomes a concern when it occurs after the software requirements phase (after CDR) is complete because it is likely to result in the re-work of the software components. 

Even though the requirements may be thought of as stable when baselined, some of them may change as the project progresses. Software requirement changes during the software development process are also known as Requirements Volatility.

Requirements volatility has a great impact on the cost, the schedule, and the quality of the final product. Due to requirements volatility, some projects may only be partially completed or even fail. Requirements volatility cannot be fully overcome but can be exposed with some requirement measures or metrics. Requirements volatility metrics could be early indicators of project risks. 

Generally, the software engineers will be producing trend charts of the software volatility. If they are not, the SA personnel should take the software requirements to change data and produce the volatility trend charts. In performing an analysis of the trending data, they should follow the project or SA analysis procedures. As a general guideline, the amount of volatility should be leveling off by the end of the requirements analysis phase. If there is considerable requirements volatility on into development, it is cause for concern. A project that has a lot of requirements volatility when it is nearing a test or delivery period has a major problem. There may be good reasons for this increased volatility (for example, a major design change in a spacecraft), but such a level of change requires careful analysis and probably replanning of activities. The earlier these trends can be identified, the better chance the project has of correcting the problem or replanning to adjust to the requirements changes. 

Requirements evolution is due to factors.

1. External Factors:
   1. Government regulations
   2. project direction and changes
   3. project funding
2. Internal factors
   1. Hardware and interface constraints and unknowns 
   2. Lack of experience of the system requirements and software requirements development team
   3. Feedback from milestone reviews and peer reviews 
   4. Complexity 
   5. Customer, operational, software, and hardware changes
   6. Hazard identifications
   7. Lack of process maturity in requirements generation and requirements management
   8. Requirement or hardware reuse
   9. Environmental changes or mission profile changes
3. Requirements instability (the extent of fluctuation in user requirements)
4. Requirements diversity (the extent to which stakeholders disagree among themselves deciding on requirements).
5. Requirements analyzability (the extent to which the process of producing requirement -specification can be reduced to objective procedure).
6. Poor communication between users and the development team.

Requirements volatility contains schedule, cost, and performance risk factors. Developing and maintaining a trending of software requirements volatility measurements is critical to determine the risks associated with the project.

Requirement volatility is not the only reason contributing to the success of any project, by can be a key indicator in the project risk and success.

Several challenges lead to Requirement Volatility.

1. The change request form was not always complete. A change request form may have little information about the reason for the proposed change.
2. No formal impact analysis and incomplete change effort estimation.
3. Traceability between requirements and other software artifacts is not established. See SWE-052 - Bidirectional Traceability

The impact of requirement volatility on the software project has been seen as:

1. Projects Schedule: If the schedule of one activity delays, obviously all subsequent activities schedule will be disturbed.
2. Project Performance: Project performance decreases due to the change in requirements. Requirement Volatility has a high impact on the coding and maintenance phases.
3. Project Cost: Project cost increases due to the change in requirements.
4. S/W Maintenance Project cost increases due to the change in requirements.
5. S/W Quality: Quality of software decreases due to continuous changes in requirements.

Though requirements volatility has an impact on the project schedule, project performance, project cost, software maintenance, and software quality, it may have some positive effects as well as it may help us to have a better understanding of user requirements.

7.5 Additional Guidance

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