7/27/2019 SE-CH5.ppt

1/42

Chapter - 5

Understanding Requirements

Unit II

7/27/2019 SE-CH5.ppt

2/42

Introduction

Definition : The broad spectrum of tasks and

techniques that lead to an understanding ofrequirements is called Requirement Engineering.

Why it is important? : Designing and building anelegant computer program that solves wrong

problem serves no ones needs. Thats why its

important to understand what the customer wants

before you begin to design and build a computerbased system.

7/27/2019 SE-CH5.ppt

3/42

It is a major software engineering action thatbegins during the communication activity and

continues into modeling activity.

Requirement Engineering builds a bridge todesign and construction.

Requirement engineering provides theappropriate mechanism for understanding what thecustomer wants, analyzing need, assessing

feasibility, negotiating a reasonable solution,specifying the solution unambiguously, validatingthe specification and managing the requirementsas they are transformed into operational system.

7/27/2019 SE-CH5.ppt

4/42

Requirement engineering tasks

1. Inception:-

The intent is to establish a basic understandingof a problem, the people who want a solution,

the nature of the solution that is desired, and

the effectiveness of the preliminary

communication and collaboration between thecustomers and the developer.

7/27/2019 SE-CH5.ppt

5/42

2. Elicitation :-

It seems simple enough ask the customer, theuser, and other what the objective for the systemare, what is to be accomplished etc. But it isntsimple.

A number of problems that are encountered aselicitation occurs:

a) Problem of scope:- The boundary of thesystem is ill-defined or the customer/ usersspecify unnecessary technical details that mayconfuse

7/27/2019 SE-CH5.ppt

6/42

b) Problem of understanding :- customer/

users are not completely sure of what isneeded, do not have full understanding of

the problem domain, have trouble

communicating needs to the s.w engineer,, omit important information, specify

ambiguous requirements

c) Problem of volatility :- the requirements

change over time

7/27/2019 SE-CH5.ppt

7/42

3. Elaboration:-

The information obtained from the customer

during the pervious two stages is expanded and

refined during elaboration.

It focuses on developing a refined technical

model that identifies various aspects of s.w

functions, behavior and information.

Elaboration is driven by the creation and

refinement of user scenario that describe how

the end user will interact with system.

7/27/2019 SE-CH5.ppt

8/42

4. Negotiation :-

It isnt unusual for customers and users to askfor more than can be achieved, given limitedbusiness resources.

Customers, users and other stakeholders areasked to rank requirements and then discuss

conflicts in priority.

Risk associated with each requirement areidentified and analyzed.

Using iterative approach , requirements areeliminated, combined, modified so that eachparty achieve some measures of satisfaction.

7/27/2019 SE-CH5.ppt

9/42

5. Specification :-

A specification can be a written document, a set

of graphical models, a formal mathematical

model, a collection of usage scenario, a

prototype, or any combination of these.

It describes the functions and performance of

the computer based system and the constraintsthat will govern its development.

7/27/2019 SE-CH5.ppt

10/42

6. Validation :-

Consequences of the requirement engineering

are assessed for quality.

Requirement validation examines hespecification to ensure that all software

requirements have been stated unambiguously,that inconsistencies, omission, and error havebeen detected and corrected.

The review team includes s.w engineers,customers, users, and other stake holders whoexamine the specification looking for errors incontents or interpretations, missing informationetc.

7/27/2019 SE-CH5.ppt

11/42

7. Requirement management :-

It is a set of activities that helps the projectteam identify, control, and track

requirements and changes to

requirements at any time as the projectproceeds.

Features traceability table:- show how therequirements relate to important customer

observable system.

7/27/2019 SE-CH5.ppt

12/42

Source traceability table:- identifies the source ofeach requirements

Dependency traceability table:- indicates howrequirements are related to one another.

Subsystem traceability table:- categorizerequirements by the subsystem that they govern.

Interface traceability table:- shows howrequirements are related to internal and external

system interfaces.

7/27/2019 SE-CH5.ppt

13/42

Establishing The Ground Work

The steps required to establish the groundwork for

understanding of software requirements

(1) Identifying the stakeholders :-

Stakeholder means anyone who benefits in adirect or indirect way from the system which isbeing developed.

Every stakeholder has different view of thesystem, achieves benefits when the system issuccessfully developed, and is open to different

risks if the development effort should fail.

7/27/2019 SE-CH5.ppt

14/42

2) Recognizing multiple viewpoints

Because of many stakeholders, the requirementsof the system will be explored from many differentpoints of view. (if possible give example)

As information is collected from many viewpoints,it can be inconsistent or conflicting. The job ofrequirement engineer is to categorize all

stakeholder information in way that will allow

decision maker to choose an internallyconsistent set of requirements for thesystem.

7/27/2019 SE-CH5.ppt

15/42

3) Working towards collaboration :-

The job of the requirement engineer is toidentify areas of commonality and areas ofconflict / inconsistency.

Collaboration does not mean thatrequirements are defined by committee.Stakeholder collaborate by providing theirview of requirements,but a strong projectchampion may make the final decisionaboutwhich requirements make the cut.

7/27/2019 SE-CH5.ppt

16/42

4) Asking the first questions:-

Questions in 3 different sets

(1) Context free questions focuses on thecustomers and stakeholders, the overall proj.

goals. For eg.

a. Who is behind the request for this work?

b. Who will use the solution?

c. What will be the economic benefit of a

successful solution?

d. Is there another source for the solution

that one needs?

(2) Allow the customer to voice his or her

perceptions about a solution:

7/27/2019 SE-CH5.ppt

17/42

For eg.

a. How would you characterize good

output that would be generated by asuccessful solution?

b. What problem will this solution address?

c. Can you show the business environmentin which the solution will be used?

d. Will special performance issues or

constraints affect the way the solution isapproached?

7/27/2019 SE-CH5.ppt

18/42

(3) Focuses on the effectiveness of the

communication activityMeta-Questions

For eg.a. Are you the right person to answer these

questions? Are your answers official?

b. Are my ques. relevant to the prob. that youhave?

c. Am I asking too many questions?

d. Can anyone else provide additional info.?

e. Should I be asking you anything else?

7/27/2019 SE-CH5.ppt

19/42

Eliciting requirements

Collaborative requirement gathering

Team of stakeholders and developers worktogether to identify the problem, propose

elements of solution, negotiate differentapproaches, and specify preliminarily set ofsolution requirements.

Guidelines :-

1) Meeting are conducted and attended byboth s.w engineers and customers.

7/27/2019 SE-CH5.ppt

20/42

2)Rules for preparation and participation areestablished.

3)An agenda is suggested that formal enoughto cover all important points but informalenough to encourage the free flow of ideas.

4)A facilitator control the meeting.

5)A definitionmechanism is used. ( can bework sheet, flip charts , wall stickers etc.)

7/27/2019 SE-CH5.ppt

21/42

The goal is to identify the problem, propose

elements of solution, negotiate different

approaches, and specify preliminarily set ofsolution requirements.

Out of the initial meetings, the stakeholders write

a one-or-two page productrequest.

A meeting place, time and date are selected and

a facilitator is chosen.

The product request is distributed to all the

attendees before the meeting date.

7/27/2019 SE-CH5.ppt

22/42

Each attendee is asked to make a list of objectsthat are part of the environment that surrounds

the system, other objects that are to beproduced by the system, and the objects that areused by the system to perform its functions.

In addition, each attendee is asked to listservices that manipulate or interact with theobjects.

Then list of constraints and performance criteriaare also developed.

7/27/2019 SE-CH5.ppt

23/42

As the requirement gathering meeting begins,

the first topic of the discussion is the need and

justification for the new product.

Everyone should agree that the product is

justified. Once the agreement has beenestablished , each participant presents his list.

Then a combined list is created for one topicarea.

7/27/2019 SE-CH5.ppt

24/42

It eliminates redundant data, adds new idea but

does not delete anything.

After combined lists for all topic areas ( objects,

services, constraints , performance) have been

created , the facilitator coordinates the

discussion.

The objective is to develop a consensus list of

objects, services, constraints, and performancefor the system to be built.

An object or service described on a list will

7/27/2019 SE-CH5.ppt

25/42

require further explanation. To accomplish this,stakeholder develop mini-specification for

entries on list.

Mini-specification is an elaboration of an objector service.

The mini-specification are presented to allstakeholders for discussion. Addition, deletions,and further elaboration are made.

In some cases, the development of mini-specswill uncover new objects, services, constraints,or performance requirements that will be addedto the original lists.

7/27/2019 SE-CH5.ppt

26/42

During all discussion, the team may arise an

issue that can not be resolved during the

meeting.

An issue list is maintained so that these ideaswill be acted on later.

7/27/2019 SE-CH5.ppt

27/42

Quality Function Deployment

QFD is a technique that translates the needs of

the customer into technical requirements for s.w.

It identifies three types of requirements :

1) Normal:- It reflects objectives and goals stated

by customer. If these requirements are present ,the customer is satisfied. (graphical displays,

specific system functions etc.)

7/27/2019 SE-CH5.ppt

28/42

2) Expected:- These requirements are implicit tothe product or system and may be so

fundamental that the customer does notexplicitly state them. Their absence will causedissatisfaction. Ex: ease of software installation.

3) Exciting:- It reflects features that go beyond thecustomers expectations and prove to be verysatisfying when present. Ex: multiple touchscreen.

QFD uses customer interviews and observation,surveys, and examination of historical data.

7/27/2019 SE-CH5.ppt

29/42

These data are then translated into a table ofrequirements called the Customer Voice Table

that is reviewed with the customer and other

stakeholders.

A variety of diagrams, matrices, and evolution

methods are then used to extract expected

requirements and to attempt to derive excitingrequirements.

7/27/2019 SE-CH5.ppt

30/42

User Scenarios

As the requirements are gathered , an overall

vision of system features and functions begins to

materialize.

Developers and users can create a set of

scenarios that identify a thread of usage for the

system to be constructed.

The scenarios are often called use cases.

7/27/2019 SE-CH5.ppt

31/42

Elicitation Work Product

For most systems, the work product includes:-

Statement of need and feasibility

Statement of scope for product / system

List of customers, users and other stakeholderswho participated in requirements elicitation.

Description ofsystems technical environment.

7/27/2019 SE-CH5.ppt

32/42

A list of requirements and constraints

A set of usage scenario

Any prototype developed

D l i U C

7/27/2019 SE-CH5.ppt

33/42

Developing Use Cases

The use case describes the systems behavior

under various conditions as the systemresponds to a request from one of its

stakeholders.

The first step in writing a use case is to define the

set ofactors that will be involved in the story.

An actor is anything that communicates with thesystem or product and it is external to the

system itself.

7/27/2019 SE-CH5.ppt

34/42

Because requirement elicitation is an evolutionary

activity, not all actors are identified during the first

iteration.

Primary actors are identified during first iteration

and secondary actors as more is learned about

the system.

Primary actors interact to achieve required system

function and derive the intended benefit from the

system.

Secondary actors support the system so that

primary actors can do their work.

7/27/2019 SE-CH5.ppt

35/42

Once actors have been identified, use cases can be

developed.

A number of questions that should be answered by

a use case :

Who is the primary actor, the secondary actor

(s)?

What are the actors goal?

What variations in the actors interaction are

possible?

B ildi Th R i t M d l

7/27/2019 SE-CH5.ppt

36/42

Building The Requirement Model

The intent of the analysis model is to provide a

description of the required informational,functional, and behavioral domains for acomputer-based system.

As the requirements model evolves, certainelements will become relatively stable, providinga solid foundation for the design task thatfollows.

Other elements of the model may be more volatile,indicating that stakeholders do not yetunderstand requirements for the system.

7/27/2019 SE-CH5.ppt

37/42

Elements Of The Requirement Model

Scenario Based ElementsScenario-based elements of requirement

model are often the first part of the model that isdeveloped. As such, they serve as input for the

creation of the other modeling elements.

Class-based Elements

Each usage scenario implies a set of objects

that are manipulated as an actor interacts withthe system. These objects are categorized intoclasses- a collection of things that have similarattributes and common behavior.

7/27/2019 SE-CH5.ppt

38/42

Behavioral Elements

The state diagram is one method for

representing the behavior of a system. A state isany externally observable mode of behavior. In

addition, state diagram indicates actions taken

as a consequence of a particular event.

Flow-oriented Elements

Information is transformed as it flows through a

computer based system. The system acceptsinput in a variety of forms, applies functions to

transform it, and produces the output in a variety

of form.

7/27/2019 SE-CH5.ppt

39/42

Analysis Patterns

Certain problems reoccur across all projects withina specific application domain.

The analysis patterns suggest solution within the

application domain that can be reused whenmodeling many applications.

Analysis patterns are integrated into the analysis

model by reference to the pattern name.

They are also stored in a repository so thatrequirements engineers can use search facilities

to find and apply them.

Negotiating Req irements

7/27/2019 SE-CH5.ppt

40/42

Negotiating RequirementsThe intent of the negotiation is to develop a project

plan that meets stakeholders needs while at thesame time reflecting the real-world constraints(e.g. time, people, budget) that have been placedon the software team.

The best negotiations strive for a win-win result.That is stakeholders win by getting the system orproduct that satisfies the majority of their needsand software team win by working to realistic andachievable budgets and deadlines.

Set of activities defined at the beginning of each s.wprocess iteration by Boehm:-

7/27/2019 SE-CH5.ppt

41/42

Set of negotiation activities at the beginning ofeach software process iteration by Bohem :-

1. Identification of the system orsubsystems keystakeholders.

2. Determination of the stakeholders wincondition.

3. Negotiation of the stakeholders win conditionsto reconcile them into a set of win-winconditions for all concerned.

7/27/2019 SE-CH5.ppt

42/42

Validating Requirements

As each element of the requirements model iscreated, it is examined for inconsistency,omissions, and ambiguity.

A review of requirement model addresses a setof questions.

Questions should be asked and answered to

ensure that the requirements model is anaccurate reflection ofcustomer need and that itprovides solid foundation for design.