4.1    Stakeholder Expectations Definition   
4.2    Technical Requirements Definition  
4.3    Logical Decomposition   
4.4    Design Solution Definition   

Note: It is important to note that the team must not rely solely on the requirements received to design and build the system. Communication and iteration with the relevant stakeholders are essential to ensure a mutual understanding of each requirement. Otherwise, the designers run the risk of misunderstanding and implementing an unwanted solution to a different interpretation of the requirements. This iterative stakeholder communication is a critically important part of project validation. Always confirm that the right products and results are being developed.

The Technical Requirements Definition Process transforms the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements expressed as “shall” statements that can be used for defining a design solution for the Product Breakdown Structure (PBS) and related enabling products. The process of requirements definition is a recursive and iterative one that develops the stakeholders’ requirements, product requirements, and lower level product/component requirements. The requirements should enable the description of all inputs, outputs, and required relationships between inputs and outputs, including constraints, and system interactions with operators, maintainers, and other systems. The requirements documents organize and communicate requirements to the customer and other stakeholders and the technical community.

Technical requirements definition activities apply to the definition of all technical requirements from the program, project, and system levels down to the lowest level product/component requirements document.

4.2.1 Process Description

Figure 4.2-1 provides a typical flow diagram for the Technical Requirements Definition Process and identifies typical inputs, outputs, and activities to consider in addressing technical requirements definition.

4.2.1.1 Inputs

Typical inputs needed for the requirements process include the following:

• Baselined Stakeholder Expectations: This is the agreed-to set of stakeholder expectations (e.g., needs, goals, objectives, assumptions, constraints, external interfaces) for the product(s) of this product layer.
• Baselined Concept of Operations: This describes how the system will be operated during the life cycle phases to meet stakeholder expectations. It describes the system characteristics from an operational perspective and helps facilitate an understanding of the system goals, objectives, and constraints. It includes scenarios, use cases, and/or Design Reference Missions (DRMs) as appropriate for the project. It may be in the form of a document, graphics, videos, models, and/or simulations.
• Baselined Enabling Support Strategies: These describe the enabling products that were identified in the Stakeholder Expectations Definition Process as needed to develop, test, produce, operate, or dispose of the end product. They also include descriptions of how the end product will be supported throughout the life cycle.
• Measures of Effectiveness: These MOEs were identified during the Stakeholder Expectations Definition Process as measures that the stakeholders deemed necessary to meet in order for the project to be considered a success (i.e., to meet success criteria).

Other inputs that might be useful in determining the technical requirements:

• Human/Systems Function Allocation: This describes the interaction of the hardware and software systems with all personnel and their supporting infrastructure. When human operators are a critical total-system component, the roles and responsibilities of the humans-in-the-system should be clearly understood. This should include all human/system interactions required for a mission including assembly, ground operations, logistics, in-flight and ground maintenance, in-flight operations, etc.

4.2.1.2 Process Activities

4.2.1.2.1 Define Constraints, Functional and Behavioral Expectations

The top-level requirements and expectations are initially assessed to understand the technical problem to be solved (scope of the problem) and establish the design boundary. This boundary is typically established by performing the following activities:

• Defining constraints that the design needs to adhere to or that limit how the system will be used. The constraints typically cannot be changed based on trade-off analyses.
• Identifying those elements that are already under design control and cannot be changed. This helps establish those areas where further trades will be made to narrow potential design solutions.
• Identifying external and enabling systems with which the system should interact and establishing physical and functional interfaces (e.g., mechanical, electrical, thermal, human, etc.).
• Defining functional and behavioral expectations for the range of anticipated uses of the system as identified in the ConOps. The ConOps describes how the system will be operated and the possible use-case scenarios.

4.2.1.2.2 Define Requirements

A complete set of project requirements includes those that are decomposed and allocated down to design elements through the PBS and those that cut across product boundaries. Requirements allocated to the PBS can be functional requirements (what functions need to be performed), performance requirements (how well these functions should be performed), and interface requirements (product to product interaction requirements). Crosscutting requirements include environmental, safety, human factors, and those that originate from the “-ilities” and from Design and Construction (D&C) standards. Figure 4.2-2 is a general overview on the flow of requirements, what they are called, and who is responsible (owns) for approving waivers.

• Functional requirements define what functions need to be performed to accomplish the objectives.
• Performance requirements define how well the system needs to perform the functions.

With an overall understanding of the constraints, physical/functional interfaces, and functional/behavioral expectations, the requirements can be further defined by establishing performance and other technical criteria. The expected performance is expressed as a quantitative measure to indicate how well each product function needs to be accomplished.

Note: Requirements can be generated from non-obvious stakeholders and may not directly support the current mission and its objectives, but instead provide an opportunity to gain additional benefits or information that can support the Agency or the Nation. Early in the process, the systems engineer can help identify potential areas where the system can be used to collect unique information that is not directly related to the primary mission. Often outside groups are not aware of the system goals and capabilities until it is almost too late in the process.

Technical requirements come from a number of sources including functional, performance, interface, environmental, safety, human interfaces, standards and in support of the “’ilities” such as reliability, sustainability, producibility and others. Consideration and inclusion of all types of requirements is needed in order to form a complete and consistent set of technical requirements from which the system will be architected and designed. Figure 4.2-3 shows an example of parent and child requirement flowdown.

Example of Functional and Performance Requirements

Initial Function Statement

The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.

This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements.

Functional Requirements with Associated Performance Requirements

• The TVC shall gimbal the engine a maximum of 9 degrees, ± 0.1 degree.
• The TVC shall gimbal the engine at a maximum rate of 5 degrees/second ± 0.3 degrees/second.
• The TVC shall provide a force of 40,000 pounds, ± 500 pounds.
• The TVC shall have a frequency response of 20 Hz, ± 0.1 Hz.

4.2.1.2.3 Define Requirements in Acceptable Statements

Finally, the requirements should be defined in acceptable “shall” statements, which are complete sentences with a single “shall” per statement. Rationale for the requirement should also be captured to ensure the reason and context of the requirement is understood. The Key Driving Requirements (KDRs) should be identified. These are requirements that can have a large impact on cost or schedule when implemented. A KDR can have any priority or criticality. Knowing the impact that a KDR has on the design allows better management of requirements.

See Appendix C for guidance and a checklist on how to write good requirements and Appendix E for validating requirements. A well-written requirements document provides several specific benefits to both the stakeholders and the technical team as shown in Table 4.2-1.

It is useful to capture information about each of the requirements, called metadata, for future reference and use. Many requirements management tools will request or have options for storing this type of information. Table 4.2-2 provides examples of the types of metadata that might be useful.

Rationale

The rationale should be kept up to date and include the following information:

• Reason for the Requirement: Often the reason for the requirement is not obvious, and it may be lost if not recorded as the requirement is being documented. The reason may point to a constraint or concept of operations. If there is a clear parent requirement or trade study that explains the reason, then it should be referenced.
• Document Assumptions: If a requirement was written assuming the completion of a technology development program or a successful technology mission, the assumption should be documented.
• Document Relationships: The relationships with the product’s expected operations (e.g., expectations about how stakeholders will use a product) should be documented. This may be done with a link to the ConOps.
• Document Design Constraints: Constraints imposed by the results from decisions made as the design evolves should be documented. If the requirement states a method of implementation, the rationale should state why the decision was made to limit the solution to this one method of implementation.

4.2.1.2.4 Validate Technical Requirements

An important part of requirements definition is the validation of the requirements against the stakeholder expectations, the mission objectives and constraints, the concept of operations, and the mission success criteria. Validating requirements can be broken into six steps:

1. Are the Requirements Written Correctly? Identify and correct requirements “shall” statement format errors and editorial errors.
2. Are the Requirements Technically Correct? A few trained reviewers from the technical team identify and remove as many technical errors as possible before having all the relevant stakeholders review the requirements. The reviewers should check that the requirement statements (a) have bidirectional traceability to the baselined stakeholder expectations; (b) were formed using valid assumptions; and (c) are essential to and consistent with designing and realizing the appropriate product solution form that will satisfy the applicable product life cycle phase success criteria.
3. Do the Requirements Satisfy Stakeholders? All relevant stakeholder groups identify and remove defects.
4. Are the Requirements Feasible? All requirements should make technical sense and be possible to achieve.
5. Are the Requirements Verifiable? All requirements should be stated in a fashion and with enough information that it will be possible to verify the requirement after the end product is implemented.
6. Are the Requirements Redundant or Over-specified? All requirements should be unique (not redundant to other requirements) and necessary to meet the required functions, performance, or behaviors.

Requirements validation results are often a deciding factor in whether to proceed with the next process of Logical Decomposition or Design Solution Definition. The project team should be prepared to: (1) demonstrate that the project requirements are complete and understandable; (2) demonstrate that evaluation criteria are consistent with requirements and the operations and logistics concepts; (3) confirm that requirements and MOEs are consistent with stakeholder needs; (4) demonstrate that operations and architecture concepts support mission needs, goals, objectives, assumptions, guidelines, and constraints; and (5) demonstrate that the process for managing change in requirements is established, documented in the project information repository, and communicated to stakeholders.

4.2.1.2.5 Define MOPs and TPMs

Measures of Performance (MOPs) define the performance characteristics that the system should exhibit when fielded and operated in its intended environment. MOPs are derived from the MOEs but are stated in more technical terms from the supplier’s point of view. Typically, multiple MOPs, which are quantitative and measurable, are needed to satisfy a MOE, which can be qualitative. From a verification and acceptance point of view, MOPs reflect the system characteristics deemed necessary to achieve the MOEs.

Technical Performance Measures (TPMs) are physical or functional characteristics of the system associated with or established from the MOPs that are deemed critical or key to mission success. The TPMs are monitored during implementation by comparing the current actual achievement or best estimate of the parameters with the values that were anticipated for the current time and projected for future dates. They are used to confirm progress and identify deficiencies that might jeopardize meeting a critical system requirement or put the project at cost or schedule risk.

For additional information on MOPs and TPMs, their relationship to each other and MOEs, and examples of each, see Section 6.7.2.6.2 of the NASA Expanded Guidance for SE document at https://nen.nasa.gov/web/se/doc-repository.

4.2.1.2.6 Establish Technical Requirement Baseline

Once the technical requirements are identified and validated to be good (clear, correct, complete, and achievable) requirements, and agreement has been gained by the customer and key stakeholders, they are baselined and placed under configuration control. Typically, a System Requirements Review (SRR) is held to allow comments on any needed changes and to gain agreement on the set of requirements so that it may be subsequently baselined. For additional information on the SRR, see Section 6.7.

4.2.1.2.7 Capture Work Products

The work products generated during the above activities should be captured along with key decisions that were made, any supporting decision rationale and assumptions, and lessons learned in performing these activities.

4.2.1.3 Outputs

• Validated Technical Requirements: This is the approved set of requirements that represents a complete description of the problem to be solved and requirements that have been validated and approved by the customer and stakeholders. Examples of documents that capture the requirements are a System Requirements Document (SRD), Project Requirements Document (PRD), Interface Requirements Document (IRD), and a Software Requirements Specification (SRS).
• Measures of Performance: These are the identified quantitative measures that, when met by the design solution, help ensure that one or more MOEs will be satisfied. There may be two or more MOPs for each MOE. See Section 6.7.2.6.2 in the NASA Expanded Guidance for Systems Engineering at https://nen.nasa.gov/web/se/doc-repository for further details.
• Technical Performance Measures: These are the set of performance measures that are monitored and trended by comparing the current actual achievement of the parameters with that expected or required at the time. TPMs are used to confirm progress and identify deficiencies. See Section 6.7.2.6.2 in the NASA Expanded Guidance for Systems Engineering at https://nen.nasa.gov/web/se/doc-repository for further details.

4.2.2 Technical Requirements Definition Guidance

Refer to Section 4.2.2 of the NASA Expanded Guidance for SE document at https://nen.nasa.gov/web/se/doc-repository for additional information on:

• types of requirements,
• requirements databases, and
• the use of technical standards.