bannerd

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

Compare with Current View Page History

Version 1 Next »

4.5 Principles Related to Tailoring the Standard Requirements

4.5.1: The Center SMA TA shall review and agree with any tailored Software Assurance and Software Safety Standard requirements.

4.5.2  Software requirements tailoring is the process used to seek relief from standard requirements consistent with program or project objectives, acceptable risk, and constraints. To accommodate the wide variety of software systems and subsystems, applying these requirements to specific software assurance, software safety, and IV&V efforts may be tailored where justified and approved. NASA established the TA governance model to approve and mitigate any changes to the Software Assurance and Software Safety Standard requirements. Tailoring from requirements in the Software Assurance and Software Safety Standard is governed by the
following steps. Tailoring at the Center level is decided by the SMA TA and the NPR 7150.2 Requirements Mapping Matrix applicability. Tailor the software assurance, software safety, and IV&V requirements using the following levels:

a. The first level of tailoring is the Software Classification Decision, see NPR 7150.2.

b. The second level of tailoring is the project’s Software Requirements Mapping Matrix, see NPR 7150.2.

c. The third level of tailoring is the tailoring by the Software Assurance TA of the Software Assurance and Software Safety Standard requirements that correspond to the project’s Software Requirements Mapping Matrix requirements.

4.5.3  The Software Assurance and Software Safety Standard establishes a baseline set of requirements for software assurance, software safety, and IV&V to reduce risks on NASA projects and programs. Each project has unique circumstances, and tailoring can modify the requirements set for software assurance, software safety, and IV&V effort. Determining the tailoring of requirements is a joint software engineering effort and SMA effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, programs, organizations, or other collections of similar software development efforts.

4.5.4  Per SWE-121, the software assurance organization maintains a Requirements Mapping Matrix or multiple Requirements Mapping Matrices against requirements in the Software Assurance and Software Safety Standard, including those delegated to other parties or accomplished by contract vehicles. Per SWE-013 and SWE-039, the software assurance organization conducts risk assessment efforts to determine the software assurance, software safety, and IV&V tasks to be performed and the rigor of each task.

4.5.5  The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that justifies supporting acceptance. The organization submitting the tailoring request informs the next higher level of involved management of the tailoring request in a timely manner. The dispositioning organization reviews the request with the other organizations that could be impacted or have a potential risk (i.e., to safety, quality, cybersecurity, health) with the proposed changes and obtains the concurrence of those organizations.

4.5.6  If a system or subsystem development evolves to meet a higher or lower software classification defined in NPR 7150.2, the software assurance, software safety, and IV&V organizations shall update their plan(s) to fulfill the applicable requirements per the Requirements Mapping Matrix and any approved changes and initiate adjustments to applicable contracts to meet the modified requirements.

4.5.7  The responsibilities for approving changes to the software engineering requirements are in NPR 7150.2. When the requirement and software class are applicable, the projects record the risk and rationale for any requirement not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix.

  • No labels