250 likes | 444 Views
System Engineer’s Toolbox. INCOSE: NM Enchantment Chapter By Cheryl Hill August 12, 2009. Compliance Automation, Inc. 1. Objectives. To provide three tools to help you: Elicit requirements Get all the requirements Communicate better with customers and developers
E N D
System Engineer’s Toolbox INCOSE: NM Enchantment ChapterByCheryl HillAugust 12, 2009 ComplianceAutomation, Inc. 1
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
Rationale SCOPE Requirement Check List 3 3
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
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
NEED • NASA – vehicle to replace shuttle NASA – make human access to space safer and cheaper
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
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
Stakeholders Security Customer Procurement Engineering Training System Engineering Software Maintenance Logistics Manufacturing Operations Quality Testing Developers Reliability Safety
External Interfaces Test command & data status command Your System Physical database Power
Operational Concepts Test and Verification Integration Disposal Storage Upgrades Transportation Maintenance Life-cycle Deployment Logistics Transition Manufacturing Training Development Installation Operations
Toolkit 2: Requirement Checklist • Requirement wording • Ambiguities • Implementation • Operations
Good Requirements Mandatory Characteristics • Needed • Verifiable • Attainable • Technically • Cost • Schedule Customer-Centered Products, p. 119
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
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
Use The Correct Terms • Requirements are binding - Shall • Facts or Declaration of Purpose - Will • Goals are non-mandatory provisions - Should • Don’t use must
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
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?
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.
Toolkit 3: Rationale • What • How • Why
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
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
Rationale Benefits • Key to understanding • Reduce interpretation problems • Facilitate maintenance and upgrades • Preserve corporate knowledge
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.)
Rationale SCOPE Your Tool Box Requirement Check List