2. Requirements1 Agenda for understand-req activity r1. Objective r2. Identifying the customer r3. Learning what the customer wants r4. Trade studies r5. Quality functional deployment (QFD) r6. Validating customer requirements r7. Writing requirements r8. Homework

2. Requirements2 1. Objective rUnderstand-requirements activity rUnderstand-requirements tasks rCompletion criteria rPseudo-completion criteria rCustomer-understanding flow 1. Objective

2. Requirements3 Understand-requirements activity rReaches agreement with the customer on the statement of work, specifications, and interfaces that constrain product development 1. Objective

2. Requirements4 Understand-requirements tasks Product requirements review (RR) Assist customer in developing product requirements and interfaces initial contract, spec, & I/Fs final contract, spec, & I/Fs approval 1. Objective

2. Requirements5 Completion criteria rComplete when the customer and the contractor agree on the statement of work, specification, and interfaces that constrain product development 1. Objective

2. Requirements6 Pseudo-completion criteria rProduct specification and external interfaces complete rRequirements review (RR) complete 1. Objective

2. Requirements7 Customer-understanding flow Identifying the customer Learning what the customer wants Validating customer requirements Writing requirements Flowing down and tracing requirements Review requirements Understanding the customer identifies the customer & flows through to managing customer requirements Managing requirements 1. Objective

2. Requirements8 2. Identifying the Customer rCustomer rDesign context rDesign vs requirements rPseudo customers 2. Identifying the customer

2. Requirements9 Customer rWho is the customer? l The person who’s paying for the product; e.g., contracting agency or product engineering for the next higher product l Users of the product l Pseudo customers 2. Identifying the customer

2. Requirements10 Design context Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design Level N+2 Spec 1 Level N+2 Spec 2 Level N+2 Spec P Level N+1 Design 2 Level N+1 Design 1 Level N+1 Design M Design occurs at each level and produces lower specs. 2. Identifying the customer

2. Requirements11 Design vs requirements Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design Design at level N becomes requirements at level N+1 Requirements as seen by level N+1 Design as seen by level N 2. Identifying the customer

2. Requirements12 Pseudo customers (1 of 2) Level N Spec Level N+1 Spec 1 Level N+1 Spec 2 Level N+1 Spec M Level N Design In addition to higher-level requirements, pseudo customers guide design In addition to higher-level requirements, pseudo customers guide design Pseudo customers 2. Identifying the customer

2. Requirements13 Pseudo customers (2 of 2) r Enterprise rProduct line rRe-usability rPotential customers r Development process rDesign rBuild rTest rSupport rMaintenance r Other customers r Other stakeholders Example pseudo customers 2. Identifying the customer

2. Requirements14 3. Learning what the customer wants rWhat the customer wants rSingle point of contact for agreement rReaching agreement 3. Learning what the customer wants

2. Requirements15 What the customer wants Customer wants Customer problem Customer preferences Economics Operation Maintenance Upgrade Field test Validation Training Support Disposal Production Politics Schedule Wants flow from problem, environment, and life cycle

2. Requirements16 Single point of contact for agreement Documented agreement Discussion Consensus Customer point of contact Contractor point of contact Customer stakeholdersContractor stakeholders Stakeholders discuss issue. Each team conveys consensus to its POC. POCs have RAA for decisions. Stakeholders discuss issue. Each team conveys consensus to its POC. POCs have RAA for decisions. POC has RAA for decisions 3. Learning what the customer wants

2. Requirements17 Reaching agreement rDefine functional areas & identify requirements rPrioritize and schedule completion of requirements rAssign points of contact and stakeholders rWrite sample requirements that people can review 3. Learning what the customer wants

2. Requirements18 4. Trade studies rUse rExample 4. Trade studies

2. Requirements19 Use rUsed to make decisions rShould be have a reason for being done rCommon technique is to use weighted ranking l Ideal -- Choose weights before study l Reality -- Choose weights after study rINCOSE Systems Engineering Handbook discusses in detail 4. Trade studies

2. Requirements20 Example 1 lawn mower

2. Requirements21 5. Quality functional deployment (QFD) rQFD rExample rQFD flowdown rQFD limitations 5. Quality functional deployment (QFD)

2. Requirements22 QFD rA requirements flowdown technique rDeploys voice of the customer rFlows down requirements to design, parts, and manufacturing 5. Quality functional deployment (QFD)

2. Requirements23 Example 1 lawn mower Quality functional deployment (QFD)

2. Requirements24 QFD flowdown what how much how what how much how what how much how Design Parts Manufacturing 5. Quality functional deployment (QFD)

2. Requirements25 QFD limitations rDuplicates information in specs rRequires tool 5. Quality functional deployment (QFD)

2. Requirements26 6. Validating customer requirements rDefinition of VOR rVOR techniques rRequirements pitfall rVOR RAA rAlternate definition of VOR rExample 6. Validating customer requirements

2. Requirements27 Definition of VOR rVOR is the process of confirming that we’ve solved the customer problem. rVerification ensures that we’ve solved the problem right. Validation ensures that we’ve solved the right problem. 6. Validating customer requirements

2. Requirements28 VOR techniques rAnalysis, modeling, prototyping, experimentation, and survey 6. Validating customer requirements

2. Requirements29 Requirements pitfall rIt’s possible to have a correct set of requirements for the solution we’ve chosen, but the solution we’ve chosen may not solve the customer problem. 6. Validating customer requirements

2. Requirements30 VOR RAA rLies with the customer, but the contractor can assist. rHowever, in generating requirements for lower products, contractor has RAA for VOR 6. Validating customer requirements

2. Requirements31 Alternate definition of VOR rEnsuring that technical requirements are consistent and complete with respect to user requirements, higher specifications, and other stakeholders rEIA 632 defines validation in these terms and assigns RAA to the contractor 6. Validating customer requirements

2. Requirements32 Solution provided by customer has correct requirements but doesn’t solve problem Solution provided by customer has correct requirements but doesn’t solve problem Example 1 -- Process development Customer believes engineering is inefficient Generates requirements for new engineering process Survey asks how engineering will respond to process Engineering will not use because cost exceeds value problem OK requirements for solution survey Validation shows solution won’t solve problem 6. Validating customer requirements

2. Requirements33 7. Writing requirements rDefinition of a requirement rOccurrence of requirements rGuidelines for a good requirement rTools for writing good requirements rExamples rNotes 7. Writing requirements

2. Requirements34 Definition of a requirement rSomething obligatory or demanded rStatement of some needed thing or characteristic 7. Writing requirements

2. Requirements35 Occurrence of requirements rWriting requirements occurs in both the understand-customer activity and the design activity rThe customer has RAA for requirements in the understand-customer activity even though the contractor may actually write the requirements rThe contractor has RAA for requirements in the design activity 7. Writing requirements

2. Requirements36 Errors in requirements come mainly from incorrect facts (50%), omissions (30%), inconsistent (15%), ambiguous (2%), misplaced (2%) Errors in requirements come mainly from incorrect facts (50%), omissions (30%), inconsistent (15%), ambiguous (2%), misplaced (2%) Guidelines for a good requirement rNeeded rCapable of being verified rFeasible schedule, cost, and implementation rAt correct level in hierarchy rCannot be misunderstood rGrammatically correct rDoes not duplicate information 7. Writing requirements

2. Requirements37 Tools for writing good requirements rRequirements elicitation rModeling rTrade studies 7. Writing requirements

2. Requirements38 Example 1 -- good requirements rThe motor shall weigh less than 10 pounds. rThe software shall use less than 75 percent of the computer memory available for software. rThe MTBF shall be greater than 1000 hours. 7. Writing requirements

2. Requirements39 Example 2 -- verification (1 of 3) rCustomer want -- The outside wall shall be a material that requires low maintenance 7. Writing requirements

2. Requirements40 Example 2 -- verification (2 of 3) rFirst possible rewording -- The outside wall shall be brick. l More verifiable l Limits contractor options l Not a customer requirement 7. Writing requirements

2. Requirements41 Example 2 -- verification (3 of 3) rSecond possible rewording -- The outside wall shall be one that requires low maintenance. Low maintenance material is one of the following: brick, stone, concrete, stucco, aluminum, vinyl, or material of similar durability; it is not one of the following: wood, fabric, cardboard, paper or material of similar durability l Uses definition to explain undefined term 7. Writing requirements

2. Requirements42 Example 3 -- feasible rNot feasible requirement -- The assembly shall be made of pure aluminum having a density of less than 50 pounds per cubic foot 7. Writing requirements

2. Requirements43 Example 4 -- level r Airplane shall be capable carrying up to 2000 pounds r Wing airfoil shall be of type Clark Y Airplane Wing p Wing airfoil shall be of type Clark Y Wing airfoil type is generally a result of design and should appear in the lower product spec and not in the higher product spec. Wing airfoil type is generally a result of design and should appear in the lower product spec and not in the higher product spec. 7. Writing requirements

2. Requirements44 Example 5 -- understanding rAvoid imprecise terms such as l Optimize l Maximize l Accommodate l Etc. l Support l Adequate 7. Writing requirements

2. Requirements45 Example 6 -- duplication rCapable of a maximum rate of 100 gpm rCapable of a minimum rate of 10 gpm rRun BIT while pumping 10 gallons gpm rVs: Run BIT while pumping between min. and max. 7. Writing requirements

2. Requirements46 Example 7 -- tough requirements rBIT false alarm rate < 3 percent rComputer throughput < 75 percent of capacity rPerform over all altitudes and speeds rConform with all local, state, and national laws rThere shall be no loss of performance rShall be safe rThe display shall look the same rTBDs and TBRs rStatistics 7. Writing requirements

2. Requirements47 Notes rPerfect requirements can’t always be written rIt’s not possible to avoid all calamities rRequirements and design are similar 7. Writing requirements

2. Requirements48 8. Homework (1 of 3) r1. RAA for requirements in the understand- customer activity lie with (a) requirements management, (b) the customer, (c) the contractor, (d) quality assurance r2. The understand-customer activity reaches agreement with the customer on which type of interfaces: (a) interfaces external to the product, (b) interfaces internal to the product,(c) all interfaces, (d) interfaces that constrain product development 8. Homework

2. Requirements49 Homework (2 of 3) r3. The customer is (a) is always one entity, (b) may be more than one entity, (c) always the product at the next-higher level, (d) undefined r4. A good practice in reaching agreement with the customer is to have agreements made by (a) management, (b) contracts, (c) a single- point of contact for customer and a single- point of contact for contractor, (d) individual stakeholders 8. Homework

2. Requirements50 Homework (3 of 3) r5. Trade studies should (a) always be done, (b) always use the method defined in the INCOSE Systems Engineering Handbook, (c) be done only if needed, (d) always include QFD considerations r6. For the requirement “Performance shall be met when speed greater than 200 mph and speed less that 400 mph,” performance must be met at (a) requirement unclear, (b) 200 mph and 400 mph, (c) any one point in the speed range, (d) all points in the speed range. 8. Homework