You are on page 1of 37


Requirements Development Process
Stakeholder s Needs ID Problem

Dev Rqmts

Stakeholder s?
Rqmts OK

Derive Rqmts

Allocate Rqmts

Analyze Rqmts

Control Functions used throughout: • Use case models • V&V Plan • Dev MOEs • Manage Rqmts • Dev Risk Mgmt Plan • CCB

Customers are not aware of the details of what they need. Systems Engineers must enter and understand the customers environment, discover the details and explain them. Flexible designs and rapid prototyping facilitate identification of customer needs.



9/17/2013 4 . unambiguous manner. Problem stating is more important than problem solving.    Identifying and stating the problem is the Systems Engineer’s most important task. The problem must be stated in a clear. An elegant solution to the wrong problem is less than worthless.

◦ Stakeholders often describe the perceived solution as the statement of the problem. 9/17/2013 5 . The problem statement must not contain preconceived solutions.  The Systems Engineers must help the customer state the problem completely. independent of solutions and specific technologies.

         Users Customer Maintenance people Operators ILS people Owners Benefactors Victims Sponsors 9/17/2013 6 .

      Users: passengers that fly on the airplane Operators: fight crews and mechanics Owners: GD stockholders Regulators: FAA Sponsor: Corporate headquarters Maintenance: Ground crews 9/17/2013 7 © 2009 Bahill .

Who specifically are all the stakeholders for your project 9/17/2013 8 .

 Problem statements describes the customers’ needs and expectations States the goals of the project Delineates the scope of the system Reports the concept of operations Describes the stakeholders Lists the deliverables       Presents the key decisions that must be made. 9/17/2013 9 .

 It is good engineering practice to state the problem in terms of needed capabilities or the top-level function that the system must perform. This stimulates consideration of more alternative designs. it is better to state the problem in terms of the deficiency that must be ameliorated.   9/17/2013 10 . However.

◦ states the goals (or capabilities) of the project. ◦ reports the concept of operations. we are ready to write formal requirements. ◦ presents key decisions and ◦ (in the final version) highlights the preferred alternatives. ◦ delineates the scope of the problem. ◦ describes the stakeholders.  The problem statement ◦ describes the customers’ needs and expectations. After these items are captured. ◦ lists the deliverables. 9/17/2013 11 .

Then re-examine the requirements. Then re-assess the functions and re-assess the requirements. and reexamine the functions. 9/17/2013 12 . First look at the functions. etc.    System functions are transformed into system requirements with a parallel and iterative process. then write some requirements.

and verifiable system requirements . An important aspect of systems engineering is converting user necessary "needs" into clear. concise.

 Transforming  Ensuring operational needs into an integrated system design solution subsystem and interface compatibility  Characterizing technical risks. .

examination. analysis. test.◦Necessary  What is the worst thing that could happen if this requirement were not included? ◦Verifiable  How will it be proven . or demonstration .

◦ Attainable  Is it technically feasible and does it fit within budget. schedule. simple and unambiguous . and other constraints ? ◦ Clear  Does it express a single thought that is concise.

 The basis for every project -Defines stakeholders needs -Defines what the system must do  Expressed in natural language  Subject to misinterpretation The first 10% of a program’s life cycle (development) determines the remaining 90% (production. operations. support)  17 .

including cost  Describe the problem in terms of measurable parameters system concepts. Define the customer's needs. cost and risk requirements . identifying constraints that limit solutions  Establish  Define principal interactions (interfaces)  Develop parametric data for cost and performance  Determine function. performance.

Validation 19 . The state of a requirement can be captured by its three attributes: ◦ Agreement – customer/user and contractor ◦ Test strategy .Agreed to ◦ Satisfaction .

20 . The extent to which a project's requirements deviate from this ideal state represents the degree of risk to which the project is exposed from the requirements management point of view ◦ also indicates the extent of the work necessary to get the requirements into the ideal state.

    Customers believe in the “I’ll know it when I see it. Once low-level requirements are satisfied.” maxim. then other requirements become high priority. It is not possible to get all of the requirements correctly at the beginning of a program. Therefore. 9/17/2013 21 . Stakeholder priorities change with time. the process must be iterative. ◦ Requirements are ever changing.

       Making bad assumptions Writing implementation (HOW) instead of requirements (WHAT) Describing operations instead of writing requirements Using incorrect terms Ambiguity .Using incorrect sentence structure or bad grammar Missing requirements Over-specifying (the $600 toilet seat) .

g. Delayed requirements) Reject poor requirements Reuse requirements across projects 23 .    Minimize the number of requirements Find sets of requirements relating to    particular topics Detect omissions and duplications Eliminate conflicts between requirements Manage iteration (e.

 KURs (key user requirements) or KPIs (key performance indicators) or KPRs (Key Performance Requirements) ◦ small subset that capture the essence of the system. ◦ Absolutely mandatory ◦ Quantified with performance attributes 24 .

If this function went away. NISN. user services  Driving Requirement: A requirement that drives the architecture and/or design in a direction it would not otherwise go ◦ These could be things that are hard to implement or challenging ( e.5Gbps.g. Non digitized analog IF back to the ULE. L12 . ◦ Examples would be scheduling services. a requirement that is driving one to implement a new technology or approach)  Not all driving requirements are key requirements ◦ An example is the fault detection and isolation to the LRU level ◦ This is not a key requirement but could drive the architecture by creating something new to accommodate. security. 1. one would still meet the basic functions and objectives of the system.. Key Requirement: A basic function that the system must perform.

      ALL requirements are important and required Key and Driving Level 3 requirements identified for increased Requirements Review Board and SRR focus Senior NASA system engineers provided initial list List of requirements iterated with GD/NASA senior system engineers Key/Driving requirements categorized Key/Driving requirements flowed to Elements ◦ Identified by “Priority” attribute in DOORs database L13 .

       Single traceable element Uniquely identified Technically possible Legally possible Clearly understandable Precise and Concise Verifiable 27 .

28 . ◦ Testable ◦ One requirement at a time. Indicate different priorities of requirement ◦ “Shall” ◦ “Should” ◦ “May”  The rules to follow: ◦ Simple direct language.

29 .  Complete: all requirements are present Consistent: no two requirements are in conflict once  Non-redundant: each rqmt is expressed  Structured: there is a clear structure to the requirements document  Satisfied: the appropriate degree of traceability coverage has been achieved  Qualified: the appropriate degree of traceability coverage has been achieved.

◦ Program planning ◦ Risk management ◦ Acceptance testing ◦ Tradeoffs ◦ Change control. 30 .

30% 8. The most common reasons for project failures are not technical Incomplete requirements 13. September 1994.10% Lack of user involvement 12.60% 9.1995 and 1996.70% Sources: Standish Group.90% Lack of executive support Changing requirements/specification 9.Scientific American. 31 .40% Lack of resources Unrealistic expectations 10.

 Requirements engineering has a vital role to play at every level of the life cycle Stakeholder Requirements The beginning Testing Stakeholder Rqmts Acceptance Test The End System Requirements System Test SubSystem Requirements Integration Test Component Requirements Component Test 32 .

  Traceability .are met by System requirements .understanding how highlevel rqmts are transformed into low-level rqmts In an engineering context.are partitioned into Subsystems . the interest focuses on how ◦ ◦ ◦ ◦ Stakeholder requirements .are implemented as Components – are found where 33 .

     Greater confidence in meeting objectives Ability to assess the impact of change Improved accountability of subordinate organizations Ability to track progress thru process Ability to balance cost against benefit 34 .

 Without a clear distinction between problem and solution. 35 . ◦ Inability to find optimal solutions due to lack of design freedom. the following result: ◦ Lack of understanding of the real problem ◦ Inability to scope the system and understand which functions to include ◦ Continued debate about the system by the stakeholders.

There can be more things included in a traceability matrix than shown. or many-to-many Rqmt Design Test Code .  Simple traceability matrix structure. one-to-many. the relationship of driver to satisfier can be one-to-one. many-to-one. In traceability.

S12 S13 U3 ID S10 S11 Functional Requirement System shall accept requirement data System shall calculate Amount of retirement System shall calculate point to point travel time System shall calculate amount of survivor annuity Backward Traceability U2 U2 U2 U3 S12 S13 .ID U2 User Requirements User shall process retirement claims User shall process survivor claims Forward Traceability S10. S11.