Requirements and Duncker Diagrams

Transcription

1 Requirements and Duncker Diagrams Table of Contents Reading...1 The Systems Engineering Method...2 Customer Expectations (Project Objectives and Mission Profile)...4 The Iterative Nature of the System Design Process...5 Requirements (Level 1 Program/Project)...7 Duncker Diagrams...12 To Market, To Market...13 Reading 1. NASA Systems Engineering Handbook NASA-SP Rev-1 Appendix C: How to Write a Good Requirement, Use of Correct Terms 2. NASA Systems Engineering Handbook NASA-SP Rev-1 Appendix C: How to Write a Good Requirement, Requirements Validation Checklist, Clarity 3. NASA Systems Engineering Handbook NASA-SP 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 D

2 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 a. Form Creative Design Solution (System PBS) b. Define Level 2 System and Subsystem Requirements c. Make Hardware and/or Software Model(s) and Perform Experiments d. Organize and Analyze Data e. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements? f. If additional detail need, Repeat Process 5. Select a preferred design a. Does the system work 3 (performance)? b. Is the system achievable within cost and schedule constraints? c. If the answer is no, adjust Customer s Expectations (Step 1) and start again. 6. Communicate Results (PDR and CDR) a. Preparing presentations (PDR and CDR) b. Reports, plans, and specifications. (Project Planning) 7. 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 D

3 The System Engineering Design Method D

4 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 4, and criteria for defining mission success. o Include information on what you are to solve, and consider why you need to solve this problem. o Case Study 1 st Iteration Problem: People are being injured and dying in traffic accidents. Customer Objective: Decrease the number of traffic accidents Social Engineering Solution: Roll out a Drive Safely campaign with better driver education and traffic enforcement 4 I will use the term Mission Profile in place of Operational Objectives D

5 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 5 (performance)? Is the system achievable within cost and schedule constraints? o The output of this step will typically result in modification of the customer s expectations and the process starts again (outside loop). o This process continues until the system architecture, mission profile (ConOps), and requirements and stakeholder expectations achieve consistency. o The number of iterations must be sufficient to allow analytical verification of the design to the requirements. o The design process is hierarchical by nature with the same process applied to the next level down in the program one person s subsystem is another person s project. 5 This includes determining if the system is safe and reliable D

6 Customer Expectations May Change As we have seen, 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. o Case Study 2 nd Iteration Problem: People are being injured and dying in traffic accidents. Customer Objective: Decrease the number of (injuries due to) traffic accidents Engineering Solution: Design a safer vehicle and roadways D

7 Requirements (Level 1 Program/Project) Reference: NASA Systems Engineering Handbook Section 4.2 Technical Requirements Definition Start (page 40) and Appendix C page A: 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 6. (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) 6 This will make the original design philosophy and negotiation results available to assess future proposed changes and modifications against D

8 Requirements (Level 1 Program/Project) Understand and translate of customer s expectations into clear unambiguous quantitative, verifiable, and realizable level 1 program requirements We choose to go to the moon in this decade (time 0:19 to 0:23) is both a goal and at the same time an excellent set of top level programmatic requirement encompassing cost, schedule, and performance. This administration declares unconditional war on poverty in America may be a noble goal, but does not lead to a good set of top level 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 translating the customer s and institutional requirements into Program/Project requirements. Program/Project requirements typically do not imply a design solution D

9 Requirements (Level 1 Program/Project) 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. 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 D

10 Requirements (Level 1 Program/Project) Document all decisions made during the development of the original design concept 7. Include links to source material and how decisions were made o 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? 8 Use of Correct Terms. The correct word usage can make all the difference between success and failure. a. Shall = requirement. All the rules defined in this presentation apply! b. Will = facts or declaration of purpose. Typically verified simply by inspection. The robot will be painted red. c. Should = goal. Time permitting we will accomplish this goal. You can think of these as bonus points. Are the requirements clear and unambiguous? o Are all aspects of the requirement understandable and not subject to misinterpretation? o 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? 7 This will make the original design philosophy and negotiation results available to assess future proposed changes and modifications against. 8 NASA Systems Engineering Handbook NASA-SP Rev-1 Appendix C: How to Write a Good Requirement, Use of Correct Terms D

11 Requirements (Level 1 Program/Project) Avoid multiple requirements within a paragraph 9. 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? On Your Own Spring 2016 A-TeChToP Research Project The most exhaustive research project ever done. Unfortunately, in many cases poorly translated to a corrected set of requirements. Tesla 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. Pathfinder The Preliminary Pathfinder Project Document is located here. How will these requirements be verified? 9 NASA Systems Engineering Handbook NASA-SP Rev-1 Appendix C: How to Write a Good Requirement, Requirements Validation Checklist, Clarity D

12 Duncker Diagrams As you explore the problem by translating into requirements, a step which includes design trade-off studies, simulation, modeling, experiments, and rapid prototyping; you may also want to first apply the Duncker Diagram. Case Study Duncker Diagram o Problem: People are being injured and dying in traffic accidents. o Achieve Desired State Path 1: Decrease the number of traffic accidents Solution 1: Roll out a Drive Safely campaign with better driver education Solution 2: Traffic enforcement o Ok not to Achieve Desired State Path 1: Do NOT decrease the number of traffic accidents Solution 1: Design a safer vehicle Solution 2: Design safer roadways D

13 To Market, To Market The Situation: Toasty O s was one of the hottest selling cereals when it first came on the market. However, after several months, sales dropped. The consumer survey department was able to identify that customer dissatisfaction, as expressed in terms of taste, was related to the age of the cereal. Consequently, management determined that they must streamline the production process to get the cereal on the store shelves faster, thus ensuring a fresher product. Engineering had quite a time with this problem - there wasn t much slack time that could be removed from the process to accomplish the goal. Of the steps required to get the product on the shelves (manufacturing, packaging, storage, and shipping) manufacturing and packaging were the fastest so plans for building plants closer to the major markets were considered as was trying to add more trucks to get the cereal to market faster D

14 To Market, To Market Sales of Toasty O s are dropping. Consumer surveys have indicated dissatisfaction with a stale taste. PERCEIVED MISSION OBJECTIVE (THE PROBLEM): Streamline the production process to get the cereal on the store shelves faster, thus ensuring a fresher product. SECOND PERCEIVED OBJECTIVE: Get the Cereal to Market Faster D

15 Duncker Diagram D

16 To Market, To Market Continued ORIGINAL MISSION STATEMENT Get cereal to market faster. The real problem was that the cereal was not staying fresh long enough, not that it wasn t getting to market fast enough. NEW MISSION STATEMENT Make Toasty O s boxes tighter and determine appropriate additive to slow down the spoiling reaction D