1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 7Chapter 7Requirements EngineeringRequirements Engineering

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

2

Requirements EngineeringRequirements Engineering

1.1. InceptionInception

2.2. ElicitationElicitation

3.3. ElaborationElaboration

4.4. NegotiationNegotiation

5.5. SpecificationSpecification

6.6. ValidationValidation

7.7. managementmanagement

3

Requirements Engineering-IRequirements Engineering-I

1.1. InceptionInception—ask a set of questions that establish …—ask a set of questions that establish … basic understanding of the problembasic understanding of the problem the people who want a solutionthe people who want a solution the nature of the solution that is desired, and the nature of the solution that is desired, and the effectiveness of preliminary communication and the effectiveness of preliminary communication and

collaboration between the customer and the developercollaboration between the customer and the developer

2.2. ElicitationElicitation—elicit requirements from all stakeholders—elicit requirements from all stakeholders

3.3. ElaborationElaboration—create an analysis model that identifies —create an analysis model that identifies data, function and behavioral requirementsdata, function and behavioral requirements

4.4. NegotiationNegotiation—agree on a deliverable system that is —agree on a deliverable system that is realistic for developers and customersrealistic for developers and customers

4

Requirements Engineering-IIRequirements Engineering-II5.5. SpecificationSpecification—can be any one (or more) of the following:—can be any one (or more) of the following:

A written documentA written document A set of modelsA set of models A formal mathematicalA formal mathematical A collection of user scenarios (use-cases)A collection of user scenarios (use-cases) A prototypeA prototype

6.6. ValidationValidation—a review mechanism that looks for—a review mechanism that looks for errors in content or interpretationerrors in content or interpretation areas where clarification may be requiredareas where clarification may be required missing informationmissing information inconsistencies (a major problem when large products or systems inconsistencies (a major problem when large products or systems

are engineered)are engineered) conflicting or unrealistic (unachievable) requirements. conflicting or unrealistic (unachievable) requirements.

7.7. Requirements managementRequirements management Requirements are identifiableRequirements are identifiable Forward traceabilityForward traceability Backward traceabilityBackward traceability

5

1. 1. InceptionInception

Identify stakeholdersIdentify stakeholders Business operations managers, product managers, Business operations managers, product managers,

marketing people, internal & external customers, end-marketing people, internal & external customers, end-users, consultants, product engineers, software users, consultants, product engineers, software engineers, support and maintenance engineers, etcengineers, support and maintenance engineers, etc

““who else do you think I should talk to?”who else do you think I should talk to?” Recognize multiple points of viewRecognize multiple points of view

Different stakeholders have different interestsDifferent stakeholders have different interests Emerging requirements may conflict with each other.Emerging requirements may conflict with each other.

Work toward collaborationWork toward collaboration The first questionsThe first questions

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

solutionsolution Is there another source for the solution that you need?Is there another source for the solution that you need?

6

2. Eliciting 2. Eliciting RequirementsRequirements meetings are conducted and attended by both software meetings are conducted and attended by both software

engineers and customersengineers and customers rules for preparation and participation are establishedrules for preparation and participation are established an agenda is suggested an agenda is suggested a "facilitator" (can be a customer, a developer, or an a "facilitator" (can be a customer, a developer, or an

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

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

the goal is the goal is to identify the problemto identify the problem propose elements of the solutionpropose elements of the solution negotiate different approaches, andnegotiate different approaches, and specify a preliminary set of solution requirementsspecify a preliminary set of solution requirements

7

Elicitation Work ProductsElicitation Work Products a statement of need and feasibility.a statement of need and feasibility. a bounded statement of scope for the system or product.a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who a list of customers, users, and other stakeholders who

participated in requirements elicitation participated in requirements elicitation a description of the system’s technical environment.a description of the system’s technical environment. a list of requirements (preferably organized by function) a list of requirements (preferably organized by function)

and the domain constraints that apply to each.and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use a set of usage scenarios that provide insight into the use

of the system or product under different operating of the system or product under different operating conditions.conditions.

any prototypesany prototypes developed to better define requirementsdeveloped to better define requirements.

8

3. Elaboration: Use-Cases3. Elaboration: Use-Cases A collection of user scenarios that describe the thread of usage A collection of user scenarios that describe the thread of usage

of a systemof a system Each scenario is described from the point-of-view of an “actor”—Each scenario is described from the point-of-view of an “actor”—

a person or device that interacts with the software in some waya person or device that interacts with the software in some way Each scenario answers the following questions:Each scenario answers the following questions:

Who is the primary actor, the secondary actor (s)?Who is the primary actor, the secondary actor (s)? What are the actor’s goals?What are the actor’s goals? What preconditions should exist before the story begins?What preconditions should exist before the story begins? What main tasks or functions are performed by the actor?What main tasks or functions are performed by the actor? What extensions might be considered as the story is described?What extensions might be considered as the story is described? What variations in the actor’s interaction are possible?What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change?What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the Will the actor have to inform the system about changes in the

external environment?external environment? What information does the actor desire from the system?What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?Does the actor wish to be informed about unexpected changes?

9

Elaboration: Use-Case Elaboration: Use-Case DiagramDiagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

10

Elaboration: Building the Analysis Elaboration: Building the Analysis ModelModel

Elements of the analysis modelElements of the analysis model Scenario-based elementsScenario-based elements

Functional—processing narratives for software Functional—processing narratives for software functionsfunctions

Use-case—descriptions of the interaction between Use-case—descriptions of the interaction between an “actor” and the systeman “actor” and the system

Class-based elementsClass-based elements Implied by scenariosImplied by scenarios

Behavioral elementsBehavioral elements State diagramState diagram

Flow-oriented elementsFlow-oriented elements Data flow diagramData flow diagram

11

Elaboration: Analysis Elaboration: Analysis PatternsPatterns

Pattern name:Pattern name: A descriptor that captures the essence of the pattern. A descriptor that captures the essence of the pattern.

Intent:Intent: Describes what the pattern accomplishes or represents Describes what the pattern accomplishes or represents

Motivation:Motivation: A scenario that illustrates how the pattern can be used to A scenario that illustrates how the pattern can be used to address the problem.address the problem.

Forces and context:Forces and context: A description of external issues (forces) that can A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be affect how the pattern is used and also the external issues that will be resolved when the pattern is applied. resolved when the pattern is applied.

Solution:Solution: A description of how the pattern is applied to solve the A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues.problem with an emphasis on structural and behavioral issues.

ConsequencesConsequences: Addresses what happens when the pattern is applied : Addresses what happens when the pattern is applied and what trade-offs exist during its application.and what trade-offs exist during its application.

DesignDesign: Discusses how the analysis pattern can be achieved through : Discusses how the analysis pattern can be achieved through the use of known design patterns.the use of known design patterns.

Known usesKnown uses: Examples of uses within actual systems.: Examples of uses within actual systems.

Related patternsRelated patterns: On e or more analysis patterns that are related to : On e or more analysis patterns that are related to the named pattern because (1) it is commonly used with the named the named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern.variation of the named pattern.

12

4. Negotiating Requirements4. Negotiating Requirements

Identify the key stakeholdersIdentify the key stakeholders These are the people who will be involved in the These are the people who will be involved in the

negotiationnegotiation Determine each of the stakeholders “win Determine each of the stakeholders “win

conditions”conditions” Win conditions are not always obviousWin conditions are not always obvious

NegotiateNegotiate Work toward a set of requirements that lead to “win-Work toward a set of requirements that lead to “win-

win”win”

13

Validating RequirementsValidating Requirements Is each requirement consistent with the overall objective for Is each requirement consistent with the overall objective for

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

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

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

Is each requirement bounded and unambiguous?Is each requirement bounded and unambiguous? Do any requirements conflict with other requirements?Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment Is each requirement achievable in the technical environment

that will house the system or product?that will house the system or product? Is each requirement testable, once implemented?Is each requirement testable, once implemented? Has the requirements model been “partitioned” in a way that Has the requirements model been “partitioned” in a way that

exposes progressively more detailed information about the exposes progressively more detailed information about the system.system.