Download
system engineer s toolbox n.
Skip this Video
Loading SlideShow in 5 Seconds..
System Engineer’s Toolbox PowerPoint Presentation
Download Presentation
System Engineer’s Toolbox

System Engineer’s Toolbox

176 Vues Download Presentation
Télécharger la présentation

System Engineer’s Toolbox

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. System Engineer’s Toolbox INCOSE: NM Enchantment ChapterByCheryl HillAugust 12, 2009 ComplianceAutomation, Inc. 1

  2. Objectives To provide three tools to help you: • Elicit requirements • Get all the requirements • Communicate better with customers and developers • Reduce rework due to requirement defects 2

  3. Rationale SCOPE Requirement Check List 3 3

  4. Toolkit 1: Scope Goals and objectives Need Business Caseor Mission Assumptions Scope isan iterative process Scope is an iterative process Interfaces Schedule Drivers and Constraints Risk Budget Authority and Responsibility Operational Concepts

  5. 200 OMV 180 GRO 78 160 GALL TDRSS 140 CEN IRAS HST 120 TETH 100 GOES I-M Actual – Target Cost Target Cost MARS LAND 76 MAG 80 ACT LAND 78 STS COBE ERB 77 60 ERB 80 40 SEASAT GRO 82 HEA UARS VOYAGER EUVE/EP ISEE 20 DE SMM ULYSSES IUE PION/VEN 5 10 15 20 25 30 Requirements Definition and Preliminary Design Target Total Cost Why Scope?Effect Of Requirements Definition Investment On Program Costs Why are you running so fast when you don’t know where you are going? German proverb

  6. NEED • NASA – vehicle to replace shuttle NASA – make human access to space safer and cheaper

  7. IS derived from a problem assessment why we are doing something a way to ensure we stay on track IS NOT the product subject to change MUST BE in writing available to all NEED

  8. Goals define specific things to accomplish to meet the need Objectives define how we will know when we get there Goals and Objectives Transport crew to and from space station Twice as safe as shuttle

  9. Stakeholders Security Customer Procurement Engineering Training System Engineering Software Maintenance Logistics Manufacturing Operations Quality Testing Developers Reliability Safety

  10. External Interfaces Test command & data status command Your System Physical database Power

  11. Operational Concepts Test and Verification Integration Disposal Storage Upgrades Transportation Maintenance Life-cycle Deployment Logistics Transition Manufacturing Training Development Installation Operations

  12. Toolkit 2: Requirement Checklist • Requirement wording • Ambiguities • Implementation • Operations

  13. Good Requirements Mandatory Characteristics • Needed • Verifiable • Attainable • Technically • Cost • Schedule Customer-Centered Products, p. 119

  14. Characteristics of Good Requirements Improving Communications • One Thought • Concise • Simple • Stated Positively • Grammatically Correct • Can only be understood one way Customer-Centered Products, p. 119

  15. What a requirement must state • WHOis responsible • The system • The software • The structure • WHAT shall be done • operate at a power level of … • acquire data from … • withstand loads up to … Who What Connect

  16. Use The Correct Terms • Requirements are binding - Shall • Facts or Declaration of Purpose - Will • Goals are non-mandatory provisions - Should • Don’t use must

  17. etc. Maximize Sufficient User-friendly Robust High speed Including, but not limited to Minimize Adequate Easy Ultra-low power TBD Avoid Ambiguous Terms • Accommodate • Support • Indefinite pronouns- this • -these • - it -and/or -be able to/becapable of Customer-Centered Products, p. 162-4

  18. Implementation Versus Requirements • How:The aircraft shall have three engines (DC-3 initial requirements). • What:The aircraft shall meet the operation requirements with a single engine out. The magic of “why” • How:The System shall include flight performance instrumentation. • What:The System shall measure its flight performance. What do you want to verify?

  19. Operations Statements Requirement • The operator shall have the capability to change the given thread selection. Rewrite • The system shall allow a change of thread selection during operations. • The system shall provide a user interface for thread selection changes.

  20. Toolkit 3: Rationale • What • How • Why

  21. Rationale – defines • Why a requirement is needed • What assumptions were made • What design effort drove the requirement • Information to help understand the requirement • Source of any numbers

  22. What NOT to Put in Rationale • A rewrite of the requirement • Hidden requirements • Copy of another requirement’s rationale • Everything you know on the topic

  23. Rationale Benefits • Key to understanding • Reduce interpretation problems • Facilitate maintenance and upgrades • Preserve corporate knowledge

  24. Example • Requirement: The truck shall have a height of no more than 14 feet. • Rationale: Ninety-nine percent of all U.S. interstate highway overpasses have a 14-foot or greater clearance. (Assumption: The truck will be used primarily on U.S. interstate highways for long-haul, intercity freight in the U.S.)

  25. Rationale SCOPE Your Tool Box Requirement Check List