1

Requirements Development Process

Stakeholder s Needs ID Problem
Revise

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

Identifying and stating the problem is the Systems Engineers most important task. An elegant solution to the wrong problem is less than worthless. Problem stating is more important than problem solving. The problem must be stated in a clear, unambiguous manner.

9/17/2013

The problem statement must not contain preconceived solutions.

Stakeholders often describe the perceived solution as the statement of the problem.

The Systems Engineers must help the customer state the problem completely, independent of solutions and specific technologies.

9/17/2013

Users Customer Maintenance people Operators ILS people Owners Benefactors Victims Sponsors

9/17/2013

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

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. However, it is better to state the problem in terms of the deficiency that must be ameliorated. This stimulates consideration of more alternative designs.

9/17/2013

10

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

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

9/17/2013

12

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

 Transforming Ensuring

operational needs into an integrated system design solution subsystem and interface compatibility

Characterizing

technical risks.

Necessary

What is the worst thing that could

happen if this requirement were not included?

Verifiable

How will it be proven - examination,

analysis, test, or demonstration

 Attainable

Is it technically feasible and does it fit

within budget, schedule, and other constraints ?

Clear

Does it express a single thought that is

concise, simple and unambiguous

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 programs life cycle (development) determines the remaining 90% (production, operations, support)

17

 Define

the customer's needs, including cost

Describe

the problem in terms of measurable parameters

system concepts, identifying constraints that limit solutions

Establish

Define

principal interactions (interfaces)

Develop

parametric data for cost and performance

Determine

function, performance, cost and risk requirements

The state of a requirement can be captured by its three attributes:

Agreement customer/user and contractor Test strategy - Agreed to Satisfaction - Validation

19

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.

20

It is not possible to get all of the requirements correctly at the beginning of a program.
Requirements are ever changing.

Customers believe in the Ill know it when I see it, maxim. Stakeholder priorities change with time. Once low-level requirements are satisfied, then other requirements become high priority. Therefore, the process must be iterative.
9/17/2013 21

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)

Minimize the number of requirements Find sets of requirements relating to

particular topics Detect omissions and duplications Eliminate conflicts between requirements Manage iteration (e.g. Delayed requirements) Reject poor requirements Reuse requirements across projects

23

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

Key Requirement: A basic function that the system must perform.

Examples would be scheduling services, 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.g., 1.5Gbps, Non digitized analog IF back to the ULE, NISN, security, 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. If this function went away, one would still meet the basic functions and objectives of the system.

L12

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

Indicate different priorities of requirement

Shall Should May

The rules to follow:

Simple direct language. Testable One requirement at a time.

28

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.

29

 Program planning Risk management Acceptance testing Tradeoffs

Change control.

30

 The

most common reasons for project failures are not technical

Incomplete requirements

13.10%

Lack of user involvement

12.40%

Lack of resources Unrealistic expectations

10.60% 9.90%

Lack of executive support Changing requirements/specification

9.30% 8.70%

Sources: Standish Group,1995 and 1996;Scientific American, September 1994.

31

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 - understanding how highlevel rqmts are transformed into low-level rqmts In an engineering context, the interest focuses on how
Stakeholder requirements - are met by System requirements - are partitioned into Subsystems - 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, 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, Inability to find optimal solutions due to lack of design freedom.

35

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

Design

Test

Code

ID
U2

User Requirements
User shall process retirement claims User shall process survivor claims

Forward Traceability
S10, S11, 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