2. Requirements1 Agenda for understand-req activity r1. Objective r2. Identifying the customer r3. Learning what the customer wants r4. Tools r5. Validating customer requirements r6. Writing requirements r7. Homework

2. Requirements2 1. Objective rUnderstand-requirements activity rUnderstand-requirements tasks rCompletion criteria rPseudo-completion criteria rUnderstanding-requirements flow rOther requirements concepts 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 Assist customer in developing product requirements and interfaces initial contract, spec, & I/Fs final contract, spec, & I/Fs 1. Objective Product requirements review (RR)

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 Understanding-requirements flow Identifying the customer Learning what the customer wants Validating customer requirements Writing requirements Review requirements Understanding requirements identifies the customer & flows through to managing customer requirements Managing requirements 1. Objective

2. Requirements8 Other requirements concepts (1 of 2) r1. Understand requirements vs requirements management l The understand-requirements activity is not the same as requirements management The understand-requirements focuses on identifying who the customers are and what they want. Requirements management focuses on generating and maintaining quality requirements of all types regardless of what activity generates them 1. Objective

2. Requirements9 Other requirements concepts (2 of 2 rUnderstand requirements vs requirements analysis l Requirements analysis is approximately the same as understanding requirements Understand requirements does not include designing although it may use the results of design Definition of requirements is a little looser and sometimes includes high-level definition of design 1. Objective

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

2. Requirements11 Customer rCustomers for the product 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 l Note that there may be more than one of each type of customer for each product 2. Identifying the customer

2. Requirements12 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. Requirements13 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. Requirements14 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. Requirements15 Pseudo customers (2 of 2) r Other stakeholders 2. Identifying the customer r Enterprise rProduct line rRe-usability rPotential customers r Development process rDesign rBuild rTest rSupport rMaintenance r Other customers Example pseudo customers

2. Requirements16 3. Learning what customers want rWhat the customers want rEliciting wants from the customers rSingle point of contact for agreement rReaching agreement 3. Learning what the customer wants

2. Requirements17 What the customers want (1 of 3) 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. Requirements18 What the customer wants (2 of 3) rIEEE P1220 tasks l 1. Customer expectations l 2. Project and enterprise constraints l 3. External constraints l 4. Operational scenarios l 5. Measure of effectiveness (MOEs) l 6. System boundaries l 7. Interfaces l 8. Utilization environments 15 tasks from IEEE P 1220

2. Requirements19 What the customer wants (3 of 3) rIEEE P 1220 tasks (continued) l 9. Life cycle l 10. Functional requirements l 11. Performance requirements l 12. Modes of operation l 13. Technical performance measures l 14. Physical characteristics l 15. Human systems integration 15 tasks from IEEE P 1220 (continued)

2. Requirements20 Eliciting wants from customers rTools l Quality functional deployment l Trade studies l Published materials -- RFPs, RFIs, RFQs, trade journals and bulletins rTechniques l Customer-contractor partnerships l Engineer-to-engineer contacts l Alliances and teaming l Techniques taught in customer elicitation courses 3. Learning what the customer wants

2. Requirements21 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. Requirements22 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. Requirements23 4. Tools rTrade studies rQuality functional deployment (QFD) rCaution 4. Tools

2. Requirements24 Trade studies (1 of 2) rUsed to make decisions rMany types of trade studies rA common technique is to use weighted ranking -- discussed in INCOSE Systems Engineering Handbook l Ideal -- Choose weights before study l Reality -- Choose weights after study 4. Tools

2. Requirements25 Trade studies (2 of 2)

2. Requirements26 QFD (1 of 5) rA requirements elicitation and flowdown technique rDeploys voice of the customer rFlows down requirements to design, parts, and manufacturing 4. Tools

2. Requirements27 QFD (2 of 5) Tools

2. Requirements28 QFD (3 of 5)

2. Requirements29 QFD (4 of 5) what how much how what how much how what how much how Design Parts Manufacturing 4. Tools

2. Requirements30 QFD (5 of 5) rShortcomings l Duplicates information in specifications l Requires tool 4. Tools

2. Requirements31 Caution rTools should be used because they’re needed rThey shouldn’t be used just because they’re available or because we feel obligated to use the tools 4. Tools

2. Requirements32 5. Validating customer requirements rDefinition of VOR rVOR techniques rRequirements pitfall rVOR RAA rAlternate definition of VOR rExample rCautions 5. Validating customer requirements

2. Requirements33 Definition of VOR (1 of 2) 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. 5. Validating customer requirements Validation vs verification

2. Requirements34 Definition of VOR (2 of 2) r1. Ensure customer requirements are correct l Done early l Integral part of understanding requirements r2. Ensure customer approach solves problem l Done early r3. Ensure that product solved the problem l Done on delivered product l Meets requirements but doesn’t solve problem Three types of validation

2. Requirements35 VOR techniques rAnalysis, modeling, prototyping, experimentation, and survey 5. Validating customer requirements

2. Requirements36 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. 5. Validating customer requirements

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

2. Requirements38 Alternate definition of VOR rEnsuring that technical requirements are consistent and complete with respect to user requirements, higher specifications, and other stakeholders 5. Validating customer requirements

2. Requirements39 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 5. Validating customer requirements

2. Requirements40 Cautions (1 of 3) wrong problem spec right problem Exercise care in telling customer that, in our opinion, they’ve solved the wrong problem Exercise care in telling customer that, in our opinion, they’ve solved the wrong problem 5. Validating customer requirements customer choice our choice common approach when contractors want to sell their product

2. Requirements41 Cautions (2 of 3) problem spec Exercise care to not confuse customer solution with customer problem Exercise care to not confuse customer solution with customer problem customer solution 5. Validating customer requirements virtual problem real problem

2. Requirements42 Cautions (3 of 3) problem spec Exercise care in telling customer that, in our opinion, they’ve solved the problem wrong Exercise care in telling customer that, in our opinion, they’ve solved the problem wrong customer solution 5. Validating customer requirements our solution common approach when contractors want to sell their product what validation is supposed to do

2. Requirements43 6. Writing requirements rDefinition of a requirement rOccurrence of requirements rGuidelines for a good requirement rExamples for each guideline rTools for writing good requirements rNotes 6. Writing requirements

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

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

2. Requirements46 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 rGrammar and spelling correct rDoes not duplicate information 6. Writing requirements Compliance Automation

2. Requirements47 Example for each guideline rExample 1 -- needed rExample 2 -- verification rExample 3 -- feasible rExample 4 -- level rExample 5 -- understanding rExample 6 -- duplication rExample 7 -- grammar and spelling rExample 8 -- tough requirements 6. Writing requirements

2. Requirements48 Example 1 -- needed 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. 6. Writing requirements

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

2. Requirements50 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 6. Writing requirements

2. Requirements51 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 6. Writing requirements

2. Requirements52 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 6. Writing requirements

2. Requirements53 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. 6. Writing requirements

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

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

2. Requirements56 Example 7 -- grammar and spelling rThe computers is comercial-off-the-shelf items rIncorrect grammar or spelling will divert customer review of the requirements from the technical content 6. Writing requirements

2. Requirements57 Example 8 -- 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 6. Writing requirements

2. Requirements58 Tools for writing good requirements rRequirements elicitation rModeling rTrade studies 6. Writing requirements

2. Requirements59 Notes rPerfect requirements can’t always be written rIt’s not possible to avoid all calamities rRequirements and design are similar and therefore are often confused and placed at the wrong level in the hierarchy 6. Writing requirements

2. Requirements60 7. 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- requirements 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) none 7. Homework

2. Requirements61 Homework (2 of 3) r3. The customer (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 7. Homework

2. Requirements62 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  200 mph and  400 mph,” performance must be met at (a) requirement unclear, (b) 200 mph and 400 mph, (c) one point in the speed range, (d) all points in the speed range. 7. Homework