Requirement Requirement EngineeringEngineering

Preeti MishraPreeti Mishra

Course InstructorCourse Instructor

Why good Specs are Essential:

• It is VERY expensive to fix problems late in the process. It is very cheap to rewrite or clarify a written spec.

• What costs $1 to fix at ReqGathering– $5 in the design stage – $10 in the coding stage – $20 in the unit testing phase – $200 after delivery

4

5

The Problems with our Requirements Practices

• We have trouble understanding the requirements that we do acquire from the customer

• We often record requirements in a disorganized manner• We spend far too little time verifying what we do record• We allow change to control us, rather than establishing

mechanisms to control change• Most importantly, we fail to establish a solid foundation

for the system or software that the user wants built

Types of Types of RequirementsRequirements

• Functional– ex - it must email the sales manager when an

inventory item is "low"

• Non-Functional– ex - it must require less than one hour to run report

#5

• Explicit– ex – required features

• Implied– ex – software quality

• Forgotten– ex – exists in current process

• Unimagined 7

Requirements of Requirements of RequirementsRequirements

• Clear

• Measurable

• Feasible

• Necessary

• Prioritized

• Concise8

Why Req Eng is Difficult

9

10

A Solution: Requirements Engineering

• Begins during the communication activity and continues into the modeling activity

• Builds a bridge from the system requirements into software design and construction

• Allows the requirements engineer to examine– the context of the software work to be performed– the specific needs that design and construction must address– the priorities that guide the order in which work is to be

completed– the information, function, and behavior that will have a profound

impact on the resultant design

Requirement Engineering

– RE helps software engineer to better understand the problem they will work to solve

– Participant : Software Engineers, managers, customers and end users

– RE is a software engineering action that begin during the communication activity and continues into the modeling activity

RE Provides the appropriate mechanism for

• Understanding what the customer want• Analyzing need• Assessing feasibility• Negotiating a reasonable solution• Specifying a solution unambiguously• Validating the specification• Managing the requirement as they are transformed

into an operational system

13

Requirements Engineering Tasks

• Seven distinct tasks– Inception– Elicitation– Elaboration– Negotiation– Specification– Validation– Requirements Management

• Some of these tasks may occur in parallel and all are adapted to the needs of the project

• All strive to define what the customer wants• All serve to establish a solid foundation for the design

and construction of the software

14

RequirementsManagement

Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Requirement Engineering Tasks

• Inception—Establish a basic understanding of the problem and the nature of the solution.

• Elicitation—Draw out the requirements from stakeholders.• Elaboration—Create an analysis model that represents

information, functional, and behavioral aspects of the requirements.

• Negotiation—Agree on a deliverable system that is realistic for developers and customers.

• Specification—Describe the requirements formally or informally.• Validation—Review the requirement specification for errors,

ambiguities, omissions, and conflicts. • Requirements management—Manage changing requirements.

16

Inception Task

• During inception, the requirements engineer asks a set of questions to establish…– A basic understanding of the problem– The people who want a solution– The nature of the solution that is desired– The effectiveness of preliminary communication and

collaboration between the customer and the developer• Through these questions, the requirements engineer needs

to… – Identify the stakeholders– Recognize multiple viewpoints– Work toward collaboration– Break the ice and initiate the communication

17

The First Set of Questions

• Who is behind the request for this work?• Who will use the solution?• What will be the economic benefit of a successful

solution?• Is there another source for the solution that you

need?

These questions focus on the customer, other stakeholders, the overall goals, and the benefits

18

The Next Set of Questions

• How would you characterize "good" output that would be generated by a successful solution?

• What problem(s) will this solution address?• Can you show me (or describe) the business

environment in which the solution will be used?• Will special performance issues or constraints affect the

way the solution is approached?

These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution

19

The Final Set of Questions

• Are you the right person to answer these questions? Are your answers "official"?

• Are my questions relevant to the problem that you have?

• Am I asking too many questions?• Can anyone else provide additional information?• Should I be asking you anything else?

These questions focus on the effectiveness of the communication activity itself

Elicitation

• It certainly simple enough, but…• Why difficult

– Problem of Scope• The boundary of the system is ill-defined

– Problem of Understanding• The customer/users are not completely sure of what is needed

– Problem of volatility • The requirement change over time

• To help overcame these problem, requirement engineers ,must approach the requirement gathering activity in an organized manner

Elicitation Process Guideline

– meetings are conducted and attended by both software engineers and customers

– rules for preparation and participation are established

– an agenda is suggested – a "facilitator" (can be a customer, a developer, or an

outsider) controls the meeting– a "definition mechanism" (can be work sheets, flip

charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used

– the goal is • to identify the problem• propose elements of the solution• negotiate different approaches, and• specify a preliminary set of solution requirements

Elaboration

• Expand requirement into analysis model• Elements of the analysis model

– Scenario-based elements• Functional—processing narratives for software

functions• Use-case—descriptions of the interaction between

an “actor” and the system– Class-based elements

• Implied by scenarios– Behavioral elements

• State diagram– Flow-oriented elements

• Data flow diagram

Negotiation

• Agree on a deliverable system that is realistic for developers and customers

• SW team & other project stakeholders negotiate the priority, availability, and cost of each requirement

• The Process are :– Identify the key stakeholders

• These are the people who will be involved in the negotiation

– Determine each of the stakeholders “win conditions”• Win conditions are not always obvious

– Negotiate• Work toward a set of requirements that lead to “win-win”

26

The Art of Negotiation

• Recognize that it is not competition• Map out a strategy• Listen actively• Focus on the other party’s interests• Don’t let it get personal• Be creative• Be ready to commit

Specification

• Final work product produced by requirement engineer.

• Can be any one (or more) of the following:– A written document– A set of models– A formal mathematical– A collection of user scenarios (use-cases)– A prototype

Technically Speaking,"requirement" ≠ "specification"

• Requirement – understanding between customer and supplier

• Specification – what the software must do

• Requirements that are not in the SRS– Costs– Delivery dates– Acceptance procedures– etc 29

Validation

examine the specification to ensure that SW requirement isnot ambiguous, consistent, error free etc

A review mechanism that looks for• errors in content or interpretation

• areas where clarification may be required

• missing information

• inconsistencies (a major problem when large products or systems are engineered)

• conflicting or unrealistic (unachievable) requirements.

Validation Vs. Verification

• Validation: “Am I building the right product?” checking a work product against higher-level work products or authorities that frame this particular product.– Requirements are validated by stakeholders

• Verification: “Am I building the product right?” checking a work product against some standards and conditions imposed on this type of product and the process of its development.– Requirements are verified by the analysts mainly

Validation Cont’d

• A review of the analysis model addresses the following question :– Is each requirement consistent with the overall objective for

the system/product?– Have all requirements been specified at the proper level of

abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

– Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

– Is each requirement bounded and unambiguous?– Does each requirement have attribution? That is, is a source

(generally, a specific individual) noted for each requirement? – Do any requirements conflict with other requirements?

33

Summary

RequirementsManagement

Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

The problems is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem

Theodore Rubin

Need to focus

Moving in the wrong direction at a fast pace is still moving in the wrong direction.

Wrong

Right

Quality Function Deployment

QFD

Information on QFD….

• Developed in Japan in the mid 1970s• Introduced in USA in the late 1980s• Toyota was able to reduce 60% of cost

to bring a new car model to market• Toyota decreased 1/3 of its

development time• Used in cross functional teams• Companies feel it increased customer

satisfaction

Why….?

• Product should be designed to reflect customers’ desires and tastes.

• House of Quality is a kind of a conceptual map that provides the means for interfunctional planning and communications

• To understand what customers mean by quality and how to achieve it from an engineering perspective.

• HQ is a tool to focus the product development process

Important points

• Should be employed at the beginning of every project (original or redesign)

• Customer requirements should be translated into measurable design targets

• It can be applied to the entire problem or any subproblem

• First worry about what needs to be designed then how

• It takes time to complete

Components of House of Quality

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Who

Whats

Wh

o vs

. W

hat

s

Hows vs Hows

Hows

Whats vs Hows

Now

No

w v

s W

hat

How MuchesHows vs

How Muches

Step 1: Who are the customers?

• To “Listen to the voice of the customer” first need to identify the customer

• In most cases there are more than one customer– consumer– regulatory agencies– manufacturing– marketing/Sales

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Who

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vs

Wha

t

How MuchesHows vs

HowMuches

Customers drive the development of the product, not the designer

Customers drive the development of the product, not the designer

Step 2: Determine the customers’

requirements• Need to determine what is

to be designed• Consumer

– product works as it should– lasts a long time– is easy to maintain– looks attractive– incorporated latest technology– has many features

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Who

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vs

Wha

t

How MuchesHows vs

HowMuches

List all the demanded qualities at the same level

of abstraction

Step 2: cont...

• Manufacturing– easy to produce– uses available resources– uses standard components and methods– minimum waste

• Marketing/Sales– Meets customer requirements– Easy to package, store, and transport– is suitable for display

Kano Model

Excitement

SatisfiersBasic

Perfo

rman

ce

Fullyimplemented

Absent

Customer Satisfaction

-

+

Disgusted

Delighted

Basic Quality: These requirements are not usually mentioned by customers. These are mentioned only when they are absent from the product.

Performance Quality: provides an increase in satisfaction as performance improves

Excitement Quality or “wow requirements”: are often unspoken, possibly because we are seldom asked to express our dreams. Creation of some excitement features in a design differentiates the product from competition.

Types of customer requirements

• Functional requirements describe the product’s desired behavior

• Human factors• Physical requirements• Reliability• Life-cycle concerns• Resource concerns• Manufacturing requirements

How to determine the Whats?

• Customer survey (have to formulate the questions very carefully)

• If redesign, observe customers using existing products

• Combine both or one of the approaches with designer knowledge/experience to determine “the customers’ voice”

Step 3: Determine Relative Importance of the Requirements:

Who vs. What

• Need to evaluate the importance of each of the customer’s requirements. – Generate weighing factor for each

requirement by rank ordering or other methods

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Wh

o

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vsW

hat

How MuchesHows vs

HowMuches

Rank Ordering• Order the identified customer requirements• Assign “1” to the requirement with the lowest

priority and then increase as the requirements have higher priority.

• Sum all the numbers• The normalized weight

Rank/Sum

• The percent weight is: Rank*100/Sum

Step 4: Identify and Evaluate the Competition: How satisfied is the

customer now?

• The goal is to determine how the customer perceives the competition’s ability to meet each of the requirements– it creates an awareness of what already exists– it reveals opportunities to improve on what already exists

The design:1. does not meet the requirement at all2. meets the requirement slightly3. meets the requirement somewhat4. meets the requirement mostly5. fulfills the requirement completely

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Wh

o

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vsW

hat

How MuchesHows vs

HowMuches

Step 5: Generate Engineering Specifications: How will the

customers’ requirements be met?

• The goal is to develop a set of engineering specifications from the customers’ requirements.

Restatement of the design problem and customer requirements in terms of parameters that can be measured.

Each customer requirement should have at least one engineering parameter.

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Wh

o

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vsW

hat

How MuchesHows vs

HowMuches

Step 6: Relate Customers’ requirements to Engineering

Specifications: Hows measure Whats?

• This is the center portion of the house. Each cell represents how an engineering parameter relates to a customers’ requirements.

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Wh

o

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vsW

hat

How MuchesHows vs

HowMuches

9 = Strong Relationship3 = Medium Relationship1 = Weak RelationshipBlank = No Relationship at all

Step 7: Identify Relationships Between Engineering Requirements:

How are the Hows Dependent on each other?

• Engineering specifications maybe dependent on each other.

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Wh

o

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vsW

hat

How MuchesHows vs

HowMuches

9 = Strong Relationship3 = Medium Relationship1 = Weak Relationship-1 = Weak Negative Relationship-3 = Medium Negative Relationship-9 = Strong Negative RelationshipBlank = No Relationship at all

Step 8: Set Engineering Targets: How much is good

enough?

• Determine target value for each engineering requirement.– Evaluate competition products

to engineering requirements– Look at set customer targets– Use the above two

information to set targets

Customer Evaluation

Units

Targets

Th

is P

rod

uct

This Product

Targets

Wh

o

Whats

Who

vs.

Wha

ts

Hows vsHows

Hows

Whats vsHows

Now

Now

vsW

hat

How MuchesHows vs

HowMuches