Introduction:

• The Requirements Analysis Report (RAR) defines what your system must do in terms of capabilities, not in terms of solutions. The RAR establishes a clear set of requirements that guide the development of the system. Below are guidelines and common pitfalls to avoid when preparing your RAR.

• The RAR is an output from conducting the Concept Exploration life cycle phase (Kossiakoff SE P&P Chapter 6).

Requirements Hierarchy:

• Ensure that your requirements are structured in a clear hierarchy. 

• Start with high-level need statements, followed by operational or capability requirements, and then move down to derived and decomposed requirements. 

• Derived and decomposed requirements will be more fully developed after you complete your FAR, CDR and A-Spec.

• All of the requirements in the RAR stop at the system boundary. This means all of the requirements should state, "The system shall...".

  • Also called the Black Box Domain. 

  • Your A-Spec will define requirements for primary subsystems and critical components within your system boundaries (white box).

Avoiding Premature Solutions:

At this stage, your requirements should not force or imply specific solutions within the system. You haven’t yet formulated your functional and physical domains, so avoid defining internal system elements (e.g., "shall have sensors"). Instead, focus on the capabilities that these elements are supposed to provide. Ask yourself why a certain element is needed and what it must achieve; the answers will guide you to the real requirements.

Quantitative vs. Qualitative Requirements:

Be sure to accurately distinguish between quantitative and qualitative requirements. Quantitative requirements must include measurable values. If a requirement is declared quantitative but lacks specific, measurable values, it cannot be properly tested. This oversight often leads to unverified or unverifiable requirements, introducing unnecessary risk into your project. Use Threshold (T) and Objective (O) measures to bound upper and lower measures.

Importance of Quantification:

Many requirements can and should be quantified, yet they often aren't. Unquantified requirements are difficult to verify, and they allow too much flexibility, which can lead to design issues later on. Always strive to make your requirements as measurable as possible to ensure they can be verified and that the system will perform as intended.

Characteristics of Good Requirement Statements:

When crafting your Requirements Analysis Report, it's essential to ensure that each requirement is clear, precise, and effective. The following characteristics of good requirements should guide you in this process. Strive to incorporate these attributes into every requirement you develop, as they are critical for successful systems engineering and project outcomes. 

• Necessary: The requirement must define an essential capability, characteristic, constraint, or quality factor.

• Appropriate: The level of detail in the requirement should match the entity it refers to, aligning with the appropriate level of abstraction.

• Singular: Each requirement should state a single capability, characteristic, constraint, or quality factor.

• Unambiguous: The requirement should be clear and interpretable in only one way.

• Complete: The requirement must describe the necessary capability or characteristic without needing additional information.

• Feasible: The requirement must be achievable within the entity's constraints, including cost, schedule, and technical limitations.

• Verifiable: The requirement should be structured so that its fulfillment can be proven to the customer's satisfaction.

• Correct: The requirement must accurately represent the need from which it was derived.

• Conforming: The requirement should follow an approved standard template and style for writing.

• Consistent: The set of requirements should not conflict with one another, and the language used must be uniform throughout.

• Comprehensible: The requirements must be written clearly, so they are easily understood in relation to the system of which they are a part.

• Able to be validated: It must be possible to prove that the requirement set will meet the entity's needs within the given constraints.

To go above and beyond, check out this appendix from the NASA Systems Engineering Handbook focusing on how to write good requirement statements.

Key Performance Parameters (KPPs):

KPPs must be fully quantified and measurable. These parameters are critical to the success of the project. If a developer cannot meet a KPP, even by a small margin, the project should not proceed. Compliance with KPPs is non-negotiable, so ensure that these are clearly defined and achievable. More info at this DAU page.

Tip: Ensure the primary purpose(s) of your system is captured as a quantified KPP!

Built-In Tests (BITs) and RM&A:

• Be cautious with self-check (Built-In Test, or BIT) requirements or those related to features commonly seen in mechanical devices. Self-checks are part of Mean Time to Repair (MTTR), which in turn is a subset of overall system Availability. Therefore, BIT requirements should appear lower in your hierarchy, at tiers 3 or 4, alongside other MTTR factors.

• One of your top level requirements should be availability. Availability has two derived requirements: Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR). If you'd like to go to the extra mile (not required for capstone), then MTTR can be further decomposed into the following:

  • Mean Time To Transport (MTTT)

  • Mean Time To Detect (MTTD)

  • Mean Time To Diagnose (MTTDg)

  • Mean Time To Isolate (MTTI)

  • Mean Time To Access (MTTA)

  • Mean Time To Perform Repair (MTTpR)

  • Mean Time To Verify (MTTV)

  • Mean Time To Re-Deploy (MTTRd)

• Bit Checks play a role in Mean Time To Detect (MTTD), Diagnose (MTTDg) and Isolate (MTTI), so we shouldn't see Bit checks or other associated requirements at the top tiers of a requirements hierarchy.

Final Thoughts:

Avoid the common mistakes highlighted above, and ensure that your requirements are clear, hierarchical, and verifiable. A well-constructed RAR will guide your project smoothly through the development process and help you avoid costly revisions later.

Steve Biemer's RAR Checklist

You will need to track the number and type of requirements as you progress through the course. Please use this table (and make sure this table is present in the A-Specification and the Final Report). 

Quantitative means just that, the requirement is defined in quantitative terms and can be verified in quantitative terms. Binary means that the requirement is verified as being satisfied or not. And Qualitative means that the verification method is subjective to a set of criteria, or worse, someone’s opinion.  

For the report, the instructors expect the following: 

1. A list of user/stakeholder needs, i.e., the desired operational outcomes. These can be titles “objectives” or “needs” or "capabilities"—your call. 

2. Description of how requirements were identified and generated, including people contacted if applicable. 

3. A general description of how you organized the requirements. In general, requirements are organized in five categories:  

1. operational,  

2. functional, 

3. performance,  

4. external interfaces (including user I/O), and 

5. constraints 

Requirements in this report should NOT be organized by subsystem, or any other physical representation. Why? Because all requirements should be at the system level, and so we would not be defining anything within the boundaries yet.

4. Requirements table. 20-40 system-level (top tier) requirements are typical, with numerous derived & decomposed child requirements below them, bringing the total to about 150-200. If you get less than this after thorough decomposition, don't worry about it. It is what it is. Don't "force" a bunch of requirements into existence just to meet this number. 

You can capture your requirements in a table with the following columns: 

1. ID Number 

2. Need(s) or Objective(s) (for traceability) 

3. Category (e.g., operational, functional, performance, external, constraint) 

4. Type (quantitative, binary, qualitative) 

5. Requirements statement (“the system shall…”) 

6. Verification method (I, D, T, or A) 

7. For overachievers: KPP (check the box to indicate KPP) 

8. For overachievers: origin (stakeholder, reference, derived) 

9. For overachievers: rationale (why this requirement?) 

10. For overachievers: description (expanded description from the statement) 

5. Key Performance Parameters identified (~5-8 KPPs) in a separate table. These can be the same as 5-8 requirements in (3) above. However, they should also be listed in a separate table. KPPs are those critical requirements that if not met may result in the cancellation of the program or system. If they're not quantified here in the RAR, they must be quantified by the A-Specification! 

6. Verification method identified for each requirement. All requirements should indicate a verification method: Inspection, Demonstration, Test, or Analysis. 

7. Requirements should be mapped (or traced) to Stakeholder needs or objectives. 

Concept of Operations Section (within the RAR above) 

1. An overall Concept diagram depicting the system in operation. This is a one-page diagram that communicates to the reader how the system is intended to be used. Should be scenario-independent. This is often referred to as an OV-1, or Operational View-1. 

2. List of potential users and operators. 

3. General description of how the system is intended to operate. 

4. Three to five scenarios describing the operational environment in which the system will operate and the actions or tasks the system performs within the scenario context. Make sure you indicate the system’s actions, and not just user actions! The more robust, rich and descriptive your scenarios are, the more ammunition you have to pull requirements and functions out of. Keep in mind that the mission domain (scenarios and use cases) should not be driving or dictating physical solutions!

5. Overachievers: provide one or more use cases for each scenario. 

RAR Checklist Credit: Steve Biemer