1

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

Chapter 4:Chapter 4:Requirements EngineeringRequirements Engineering

MELJUN P. CORTES,MBA,MPA,BSCSMELJUN P. CORTES,MBA,MPA,BSCS

2

Requirements EngineeringRequirements Engineering

Stages:Stages: InceptionInception ElicitationElicitation ElaborationElaboration NegotiationNegotiation SpecificationSpecification ValidationValidation ManagementManagement

3

Requirements EngineeringRequirements Engineering 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

ElicitationElicitation—elicit requirements from all stakeholders—elicit requirements from all stakeholders address problems of scopeaddress problems of scope address problems of understandingaddress problems of understanding

customers not sure about what is needed, skip “obvious” issues, customers not sure about what is needed, skip “obvious” issues, have difficulty communicating with the software engineer, have poor have difficulty communicating with the software engineer, have poor grasp of problem domaingrasp of problem domain

address problems of volatilityaddress problems of volatility

4

Requirements EngineeringRequirements Engineering

ElaborationElaboration—create an analysis model that identifies —create an analysis model that identifies data, function, features, constraints and behavioral data, function, features, constraints and behavioral requirementsrequirements

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

rank requirements by priority (conflicts arise here …)rank requirements by priority (conflicts arise here …) identify and analyze risks assoc. with each requirementidentify and analyze risks assoc. with each requirement ““guestimate” efforts needed to implement each requirementguestimate” efforts needed to implement each requirement eliminate, combine and / or modify requirements to make eliminate, combine and / or modify requirements to make

project realisticproject realistic

5

Requirements EngineeringRequirements Engineering

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 mathematical modelA formal mathematical model A collection of user scenarios (use-cases)A collection of user scenarios (use-cases) A prototypeA prototype

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 inconsistencies (a major problem when large products or

systems are engineered)systems are engineered) conflicting or unrealistic (unachievable) requirementsconflicting or unrealistic (unachievable) requirements

6

Requirements EngineeringRequirements Engineering

Requirements management involves managing change:Requirements management involves managing change:

Feature traceability:Feature traceability: how requirements relate to how requirements relate to observable system/product featuresobservable system/product features

Source traceability:Source traceability: identifies source of each identifies source of each requirementrequirement

Dependency traceability:Dependency traceability: how requirements are related how requirements are related to each otherto each other

Subsystem traceability:Subsystem traceability: categorizes requirements by the categorizes requirements by the subsystem(s) they governsubsystem(s) they govern

Interface traceability:Interface traceability: how requirements relate to both how requirements relate to both external and internal system interfacesexternal and internal system interfaces

7

InceptionInception Identify stakeholdersIdentify stakeholders

““whom else do you think I should talk to?”whom else do you think I should talk to?” Recognize multiple points of viewRecognize multiple points of view Work toward collaborationWork toward collaboration

The first questions:The 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

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

8

InceptionInception

The subsequent questions:The subsequent questions: What constitutes a “good” output from the What constitutes a “good” output from the

system?system? What problem(s) does this solution address?What problem(s) does this solution address? What is the intended business environment What is the intended business environment

for this solution?for this solution? What performance issues or constraints What performance issues or constraints

should affecting my approach to the solutionshould affecting my approach to the solution

9

InceptionInception

The final questions:The final questions: Are your answers official?Are your answers official? Are my questions relevant?Are my questions relevant? Am I asking too many questions?Am I asking too many questions? Can anyone else provide additional info?Can anyone else provide additional info? Should I be asking anything else?Should I be asking anything else?

10

Eliciting RequirementsEliciting Requirements 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 A "definition mechanism" (can be work sheets, flip

charts, or wall stickers or an electronic bulletin board, charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is usedchat room or 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

11

Use QFD to prioritize

requirements

informally prioritize

requirements

formal prioritization?

Create Use-cases

yes noElic it requirements

write scenario

define actors

complete template

draw use-case diagram

Conduct FASTmeetings

Make lists offunctions, classes

Make lists ofconstraints, etc.

12

Quality Function Quality Function DeploymentDeployment

A technique of translating customer needs into A technique of translating customer needs into technical system requirements:technical system requirements:

Normal requirements:Normal requirements: reflect stated customer reflect stated customer goals and objectivesgoals and objectives

Expected requirements:Expected requirements: implicit to the product implicit to the product or system; their absence will cause significant or system; their absence will cause significant customer dissatisfactioncustomer dissatisfaction

Exciting requirements:Exciting requirements: featured going beyond featured going beyond customer expectations, causing customer euphoria customer expectations, causing customer euphoria (;-)(;-)

13

Quality Function Quality Function DeploymentDeployment

Function deploymentFunction deployment determines the “value” (as determines the “value” (as perceived by the customer) of each function required perceived by the customer) of each function required of the systemof the system

Information deploymentInformation deployment identifies data objects and identifies data objects and eventsevents

Task deploymentTask deployment examines the behavior of the examines the behavior of the systemsystem

Value analysisValue analysis determines the relative priority of determines the relative priority of requirementsrequirements

14

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.

15

Use-CasesUse-Cases A collection of user scenarios that describe the thread of usage of a A collection of user scenarios that describe the thread of usage of a

systemsystem

Each scenario is described from the point-of-view of an “actor”—a Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some wayperson 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 external Will the actor have to inform the system about changes in the external

environment?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?

16

Use-Case DiagramUse-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

17

Building the Analysis ModelBuilding the Analysis Model

Intent: to provide a description of the Intent: to provide a description of the required informational, functional and required informational, functional and behavioral domains of the computer-based behavioral domains of the computer-based systemsystem

The model changes dynamically as the The model changes dynamically as the system engineers learn more about the system engineers learn more about the systemsystem

Is a series of time-ordered snapshots of Is a series of time-ordered snapshots of requirementsrequirements

18

Building the Analysis ModelBuilding the Analysis Model

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

19

Class DiagramClass Diagram

Sensor

name/id type location area characteristics

identify() enable() disable() reconfigure()

From the From the SafeHomeSafeHome system … system …

20

State DiagramState Diagram

Figure 7.6 Preliminary UML state diagram for a photocopier

Initialization

system status=“not ready” display msg = “please wait” display status = blinking

entry/ switch machine on do: run diagnostics do: initiate all subsystems

turn copier “on“

subsystems ready system status=“Ready”

display msg = “enter cmd” display status = steady

entry/ subsystems ready do: poll user input panel do: read user input do: interpret user input

Readingcommands

system status=“Copying” display msg= “copy count =” display message=#copies display status= steady

entry/ start copies do: manage copying do: monitor paper tray do: monitor paper flow

Making copies

start copies

system status=“Jammed” display msg= “paper jam” display message=location display status= blinking

entry/ paper jammed do: determine location do: provide corrective msg. do: interrupt making copies

problem diagnosis

paper jammed

system status=“load paper” display msg= “load paper” display status= blinking

entry/ paper empty do: lower paper tray do: monitor fill switch do: raise paper tray

load paper

paper tray empty

not jammed

paper full

turn copier “off”

not jammed

copies complete

21

Analysis PatternsAnalysis PatternsPattern 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.

22

Negotiating RequirementsNegotiating 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-win”Work toward a set of requirements that lead to “win-win”

23

Validating RequirementsValidating RequirementsChecking Checking for Consistency, Omissions, for Consistency, Omissions,

AmbiguityAmbiguity

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 add-on feature that may not be essential to the objective of the system?the system?

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

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

24

Validating RequirementsValidating Requirements Is each requirement achievable in the technical environment that Is each requirement achievable in the technical environment that

will house the system or product?will house the system or product?

Is each requirement testable, once implemented?Is each requirement testable, once implemented?

Does the requirements model properly reflect the information, Does the requirements model properly reflect the information, function and behavior of the system to be built.function and behavior of the system to be built.

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 system.exposes progressively more detailed information about the system.

Have requirements patterns been used to simplify the Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?Are all patterns consistent with customer requirements?