High Level Requirements (Level 1 Program/Project)

View Exclusively

Table of Contents

Reading

  1. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Use of Correct Terms
  2. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Requirements Validation Checklist, Clarity
  3. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Section 4.2 Technical Requirements Definition Start (page 40)
  4. Department of Chemical Engineering, University of Michigan, Ann Arbor, Chapter 5 “Problem Definition Techniques

The Systems Engineering Method

  1. Customer[1] Expectations (Project Objectives and Mission Profile)
  2. High Level Requirements (Level 1 Program/Project)
  3. Functional and Logical decompositions (Project WBS)[2]
  4. Trade Studies and Iterative Design Loop
    1. Form Creative Design Solution (System PBS)
    2. Define Level 2 System and Subsystem Requirements
    3. Make Hardware and/or Software Model(s) and Perform Experiments
    4. Organize and Analyze Data
    5. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements?
    6. If additional detail need, Repeat Process
  5. Select a preferred design
    1. Does the system work[3] (performance)?
    2. Is the system achievable within cost and schedule constraints?
    3. If the answer is no, adjust Customer’s Expectations (Step 1) and start again.
  6. Communicate Results (PDR and CDR)
  7. Preparing presentations (PDR and CDR)
  8. Reports, plans, and specifications. (Project Planning)
  9. Implement the design. (Project Implementation)
[1] NASA introduces the term Stakeholders at this time, a term that encompasses both the customer and individuals directly or indirectly effected by the project. Due to the introductory nature of this course, I will simply use the term customer.  
[2] See Week 1 Job Descriptions
[3] This includes determining if the system is safe and reliable.

The System Engineering Design Method

Customer Expectations (Project Objectives and Mission Profile)

  • After Mission Authorization (i.e. funding), the process Starts with a study team collecting and clarifying the Customer’s Expectations (The Problem Statement), including the program objectives, constraints, design drivers, mission profile[1], and criteria for defining mission success.
    • Include information on what you are to solve, and consider why you need to solve this problem. The Duncker Diagram may help answer this question.

[1] I will use the term Mission Profile in place of Operational Objectives

Customer Expectations May Change

  • The statement of the Customer’s Expectations may be modified as objectives are translated into requirements and the nature of the real problem is better understood.
  • After each iteration, make sure you are proceeding to solve the real problem as opposed to the perceived problem.

The Iterative Nature of the System Design Process

From the customer’s expectations high-level requirements are defined.

These high-level requirements drive an iterative design loop where creative “strawman” architecture/designs and derived system and subsystem requirements are developed.

This process will require iterations (inside loops) and design decisions to achieve consistency. Once consistency is achieved, analyses allows the project team to validate the design against the customer’s expectations. A simplified validation asks the questions:

  • Does the system work[1] (performance)?
  • Is the system achievable within cost and schedule constraints?
  • The output of this step will typically result in modification of the customer’s expectations and the process starts again (outside loop).
  • This process continues until the system—architecture, mission profile (ConOps), and requirements and stakeholder expectations achieve consistency.
  • The number of iterations must be sufficient to allow analytical verification of the design to the requirements.
  • The design process is hierarchical and recursive by nature with the same process applied to the next level down in the program – one person’s subsystem is another person’s project.

[1] This includes determining if the system is safe and reliable.

Requirements (Level 1 Program/Project)

Reference:   NASA Systems Engineering Handbook Section 4.2 Technical Requirements Definition Start (page 40) and Appendix C page A: 279

  1. Understand and translate of customer’s expectations into clear unambiguous quantitative, verifiable, and realizable level 1 program requirements
  2. Complete and thorough requirements traceability (including requirement flow-down and verification that the requirement is at the correct level).
  3. Does the requirement move the design process forward and are any requirements missing (your strawman design will help you discover these requirements)?
  4. Document all decisions made during the development of the original design concept[1]. (Including links to source material) and how they were made (Are equations used to calculate a requirement provided and are answers correct)
  5. Is language in the form of a requirement?
  6. Avoid multiple requirements within a paragraph. (i.e., breakup statements that contain multiple requirements)
Note: It is extremely important to involve the customer in all phases of a project. Such involvement should be built in as a self-correcting feedback loop that will significantly enhance the chances of mission success. Involving customer in a project builds confidence in the end product and serves as a validation and acceptance with the target audience.

Understand and translate of customer’s expectations into clear unambiguous quantitative, verifiable, and realizable level 1 program requirements

Complete and thorough requirements traceability (including requirement flow-down and verification that the requirement is at the correct level).

  • Program requirements translate, are linked to, the customer objectives, while project requirements may reflect an institutional requirement (like safety or flight restrictions).
  • At this point in the project, our focus is on translating the customers and institutional requirements into Program/Project requirements.
  • Program/Project requirements typically do not imply a design solution.

Does the requirement move the design process forward and are any requirements missing (these are the hardest to discover and the most expensive in cost and schedule to correct)?

  • The lowest level requirement is normally stated in the form of a specification. In the diagram below, in the bottom row – left hand corner a specification is created without a link to a higher level requirement(s). This is the simplest way of discovering any missing requirements. Alternatively, if no such higher requirement exists, the product is over designed.
  • In middle row – right side of the diagram below we have an example of a requirement that does not lead to a specification and therefore does not move the design process forward. Alternatively, it could be argued that the product is under designed by not meeting all its design requirements.

Document all decisions made during the development of the original design concept[2].

  • Include links to source material and how decisions were made
    • Are the equations used to calculate a requirement provided and are answers correct?
  • Close attention to this process is the difference between the customer saying “you said” and your company paying to correct the problem within the agreed upon schedule, versus you telling the customer your new requirement is out-of-scope and your customer paying the increased cost with attendant schedule delay.

Is language in the form of a requirement?[3]

  • Use of Correct Terms. The correct word usage can make all the difference between success and failure.
  1. Shall = requirement. All the rules defined in this presentation apply!
  2. Will = facts or declaration of purpose. Typically verified simply by inspection. The robot will be painted red.
  3. Should = goal. Time permitting we will accomplish this goal. You can think of these as bonus points.
  • Are the requirements clear and unambiguous?
    • Are all aspects of the requirement understandable and not subject to misinterpretation?
    • Is the requirement free from indefinite pronouns (this, these) and ambiguous terms (e.g., “as appropriate,” “etc.,” “and/or,” “but not limited to”)?
  • Are the requirements concise and simple?

Avoid multiple requirements within a paragraph[1].

  • Do the requirements express only one thought per requirement statement, a standalone statement as opposed to multiple requirements in a single statement, or a paragraph that contains both requirements and rationale?
  • Does the requirement statement have one subject and one predicate?
[1] NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Requirements Validation Checklist, Clarity
[2] This will make the original design philosophy and negotiation results available to assess future proposed changes and modifications against.
[3] NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Use of Correct Terms

On Your Own

The most exhaustive research project ever done. Unfortunately, in many cases poorly translated to a corrected set of requirements.

The Tesla Final Project Document is here.  Does level 1 Project Requirements meet the criteria previously defined? Do level 2 System/Subsystem flow down from the level above.

The Preliminary Pathfinder Project Document is located here. How will these requirements be verified?

View Exclusively