1. Risk

Risk Rationale:

The timely baselining of software requirements is essential for ensuring a stable foundation for software design, development, verification, and validation activities. Software requirements provide the definitive scope, functionality, and constraints that the software must fulfill to meet mission and stakeholder objectives. Baseline requirements are those that are formally reviewed, agreed upon, and approved, signaling to all stakeholders that the project has a clear and shared understanding of what the software system will achieve and how it will behave.

Late baselining of software requirements—occurring after the Critical Design Review (CDR)—poses significant risks to the software development process. The CDR is intended to confirm that the system design (hardware and software) satisfies all defined and allocated requirements and is ready to move into implementation. If software requirements have not been finalized and approved by CDR, there is a risk that subsequent design decisions will be based on incomplete or unverified information, increasing the likelihood of misalignment between software and system-level requirements. This misalignment can lead to costly rework, schedule delays, and unstable or inconsistent software design.

Late baselining also disrupts the downstream activities that are dependent on clear and stable requirements. During development, baselined requirements provide the guidance needed for coding, integration, and testing. Delaying the baselining process creates uncertainty regarding the scope and functionality of the software, inhibiting the team's ability to make confident technical decisions and increasing the likelihood of defects or gaps in implementation. Verification activities, including traceability analysis and formal acceptance testing, are also negatively impacted because incomplete requirements lack sufficient definition to confirm whether the delivered software meets stakeholder expectations.

The impact of late baselining of requirements is particularly pronounced in complex, high-stakes missions, where software systems must be highly reliable, safe, and thoroughly integrated with hardware and other subsystems. Without baselined requirements, critical program elements such as risk assessments, interface definitions, and resource allocations (e.g., CPU cycles, memory) may also remain unresolved or inaccurate, introducing additional programmatic and technical risks.

This risk exists due to multiple possible factors, including inadequate planning, insufficient stakeholder engagement, or prolonged iterations caused by unresolved TBDs (To Be Determined), TBCs (To Be Confirmed), or TBRs (To Be Reviewed) in the requirements definition process. Late-breaking changes in mission objectives or external constraints can also force delays in requirements baselining, as can a failure to adhere to proper requirements management processes.

2. Mitigation Strategies

Mitigation Strategies

Ensuring that software requirements are baselined prior to CDR is critical to reducing variability and ensuring design and implementation alignment. Timely requirements baselining promotes stability across the development lifecycle, improves project predictability, and minimizes risks related to schedule delays, cost overruns, and quality issues. Addressing this risk requires proactive requirements development, early stakeholder engagement, adherence to project timelines, and robust peer reviews to resolve ambiguities prior to CDR.

3. Resources

3.1 References