bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-053 - Manage Requirements Changes

1. Requirements

4.1.3.1 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 Applicability Across Classes

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

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

Figure 1 - Typical flow down of requirements 273


"The average project experiences about a twenty-five percent change in requirements after the requirements have been defined for the first system release, which causes at least a twenty-five percent schedule slip [23]. Several studies also have shown that volatility in requirements contribute to the inefficient production of low-quality software [11, 13]. Consequently, requirements should be managed using a defined configuration management process that uses change control boards and automated change control tools that manage each requirement as a separate configuration item [10, 27].1 Using a configuration management tool permits personnel to identify which requirements have been added, removed, or changed since the last baseline, 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." 061 

Changes to requirements can be an indicator of software instability or an unclear description of the end product. Regardless of the reason, requirements 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.

Figure 2 shows a typical requirements change management process flow.

Figure 2 - Software requirements management activities 273


Per NASA-STD-8719.13, NASA Software Safety Guidebook276, "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. Traceability information is an important tool in this evaluation." 276

See SWE-052 for guidance on requirements traceability and SWE-080 for guidance on impact analysis, including cost, technical, and schedule impacts.

Requirements management also includes the management of the software data dictionary content.  Examples of content contained in a software data dictionary include:

    1. Channelization data (e.g., bus mapping, vehicle wiring mapping, hardware channelization).
    2. Input/Output (I/O) variables.
    3. Rate group data.
    4. Raw and calibrated sensor data.
    5. Telemetry format/layout and data.
    6. Data recorder format/layout and data.
    7. Command definition (e.g., onboard, ground, test specific).
    8. Effecter command information.
    9. Operational limits (e.g., maximum/minimum values, launch commit criteria information).

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.

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 7.18 – Documentation Guidance 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.

Analyze the changes for cost, technical, and schedule impacts

"Effective management of requirements changes requires a process that assesses the impact of the proposed changes prior to approval and implementation of the change. " (NASA/SP-2007-6105, NASA Systems Engineering Handbook) 273.

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 Configuration Control Board (CCB) or other review board (see SWE-082) who can request or perform an impact analysis (see SWE-080) before determining how to disposition the change.

When performing analysis of changes, look for impacts such as:

  • Impact to other parts of the software system (not just the immediate design or code where the change will occur): architecture, design, interfaces, concept of operations, higher- and lower-level requirements.
  • Impact to 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.
  • Criticality of 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, SWE-059, SWE-064, SWE-072).  Other relevant items, from NASA/SP-2007-6105, NASA Systems Engineering Handbook 273, 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 threats 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 to the function of the software and overall system.

Document analysis results

Document and maintain with the project records the results of the impact analysis and any decisions based on that analysis. Communicate the results to the appropriate stakeholders, i.e., project personnel who must implement approved changes, must update documentation related to those changes, 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.

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.

NASA users should consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to the management of requirements changes.

Additional guidance related to the management of requirements changes may be found in the following related requirement in this Handbook:

SWE-052

Bidirectional Traceability Between Higher Level Requirements and Software Requirements

SWE-080

Track and Evaluate Changes

SWE-059

Bidirectional Traceability Between Software Requirements and Software Design
SWE-064Bidirectional Traceability Between Software Design and Software Code
SWE-072Bidirectional Traceability Between Software Test Procedures and Software Requirements
SWE-082Authorizing Changes

4. Small Projects

For projects with limited budgets or staff, spreadsheet programs may be used to manage the requirements and track changes to them, but when the number of requirements is large and a project can afford it, using an appropriate combination of a requirements management tool, a change management tool, and a change request tool can make managing requirements change easier for the project.

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. See Chapter 9. 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-091) Requirements Management, 580-PC-024-04, Software Engineering Division, NASA Goddard Space Flight Center (GSFC), 2016. 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-273)

    NASA SP-2007-6105, Rev1, NASA Headquarters, 2007. See 6.2 Requirements Management.

  • (SWEREF-276)

    NASA-GB-8719.13, NASA, 2004.

  • (SWEREF-305)

    Ramzan, S., Ikram N., (December 2006). IEEE International Multitopic Conference 2006, 2006. NASA users can access IEEE standards via the NASA Technical Standards System located at https://standards.nasa.gov/. Retrieved on December 14, 2017 from http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4196410.

  • (SWEREF-307) Requirements Management, GRC-SW-7150.6, Rev. D, Software Engineering Process Group, NASA Glenn Research Center, 2011. 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-512)

    Public Lessons Learned Entry: 625.


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

ARM

Unknown

http://satc.gsfc.nasa.gov/tools/arm/ ...

GSFC

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

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

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,

6. 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." 512
  • No labels