1. Chapter 7
Requirements Engineering
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e1

2. Objectives

Introduce Requirements Engineering concepts

Introduce major tasks of Requirements Engineering
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e2

3. Overview

Requirements engineering helps software engineers better understand the
problems they are trying to solve.

Building an elegant computer solution that ignores the customer's needs
helps no one.

It is very important to understand the customer's wants and needs before
you begin designing or building a computer-based solution.

The requirements engineering process begins with inception, moves on to
elicitation, elaboration, negotiation, problem specification, and ends with
review or validation of the specification.

The intent of requirements engineering is to produce a written
understanding of the customer's problem.

Several different work products might be used to communicate this
understanding (user scenarios, function and feature lists, analysis models,
or specifications).
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e3

4. Requirements Engineering

Requirement: A function, constraint or other property that the
system must provide to fill the needs of the system’s intended
user(s)
Engineering: implies that systematic and repeatable
techniques should be used to ensure that system
requirements are complete, consistent, relevant . . . etc.
 Requirement Engineering covers all of the activities
involved in discovering, documenting, and maintaining
a set of requirements for a system.
 RE means that requirements for a product are defined,
managed and tested systematically
SWE311_Ch07 (071)
Slid
Software & Software Engineering
e4


5. Requirements Engineering

Must be adapted to the needs of a specific process,
project, product, or people doing the work.

Begins during the software engineering communication
activity and continues into the modeling activity.

In some cases requirements engineering may be
abbreviated, but it is never abandoned.

It is essential that the software engineering team
understand the requirements of a problem before the team
tries to solve the problem.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e5

6. Types of Requirements

Functional requirement


A requirement that specifies a function or service
that a system must be capable of performing from
user’s point of view.
Non-functional requirement
A requirement that describes the property of the
system including performance, reliability, usability
etc.
SWE311_Ch07 (071)
Slid

Software & Software Engineering
e6

7. What do we achieve by end of RE

Full understanding of what the stakeholders really
need of the system

Complete and accurate representation of that to be
communicated to system developers
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e7

8. Characteristics of a Good Requirement

Clear and Unambiguous




Correct


A requirement contributes to a real need
Understandable


standard structure
has only one possible interpretation
Not more than one requirement in one sentence
A reader can easily understand the meaning of the requirement
Verifiable

A requirement can be tested
Complete
 Consistent
 Traceable
SWE311_Ch07 (071)
Software & Software Engineering

Slid
e8

9. Why is Getting Good Requirements Hard?





Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting
requirements.
Organisational and political factors may influence the
system requirements.
The requirements change during the RE process. New
stakeholders may emerge and the business environment
change.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e9

10. Requirements Engineering Tasks

Inception

Elicitation

Elaboration

Negotiation

Specification

Requirements Validation
Requirements management
SWE311_Ch07 (071)
Software & Software Engineering

Slid
e 10

11. Requirements Engineering-I

Inception—ask a set of questions that establish
…
 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary
communication and collaboration between the
customer and the developer
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 11

12. Elicitation

Elicitation—elicit requirements from all stakeholders
 Find out from customers what the product
objectives are
 what is to be done
 how the product fits into business needs, and
 how the product is used on a day to day basis
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 12

13. Elaboration

Elaboration—create an analysis model that identifies
data, function and behavioral requirements

Focuses on developing a refined technical model of software
functions, features, and constraints using the information
obtained during inception and elicitation
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 13

14. Negotiation

Negotiation—agree on a deliverable system that is
realistic for developers and customers
 Requirements are categorized and organized
into subsets
 Relations among requirements identified
 Requirements reviewed for correctness
 Requirements prioritized based on customer
needs
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 14

15. Requirements Engineering-II

Specification—can be any one (or more) of
the following:
 A written document
 A set of models
 A formal mathematical specification
 A collection of user scenarios (use-cases)
 A prototype
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 15

16. Requirements Validation

Requirements Validation—formal technical 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.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 16

17. 
Requirements management

Set of activities that help project team to identify, control, and track
requirements and changes as project proceeds

Many of these activities are identical to those that make up the
software configuration management (SCM) process

Requirements are first identified, tagged with a unique identifier and
classified by type (functional, data, behavioral, interface, or output)

Traceability tables (e.g., features, source, dependency, subsystem,
interface) are developed and updated any time a requirement is
modified)

Database systems are invaluable in helping software teams track
requirement changes
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 17

18. Traceability Tables

Features traceability table (shows how requirements relate to
customer observable features)

Source traceability table (identifies source of each
requirement)

Dependency traceability table (indicate relations among
requirements)

Subsystem traceability table (requirements categorized by
subsystem)
Interface traceability table (shows requirement relations to
internal and external interfaces)
SWE311_Ch07 (071)
Slid
Software & Software Engineering
e 18


19. Initiating Requirements Engineering Process
Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first 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?
SWE311_Ch07 (071)
Software & Software Engineering

Slid
e 19

20. 
The next set of questions enable developers to better
understand the problem and the customer's perceptions of the
solution

How would you characterize good output form a successful solution?

What problem(s) will this solution address?

Can you describe the business environment in which the solution will
be used?

Will special performance constraints affect the way the solution is
approached?
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 20

21. 
The final set of questions focuses on communication
effectiveness

Are you the best person to give "official" answers to these questions?

Are my questions relevant to your problem?

Am I asking too many questions?

Can anyone else provide additional information?

Should I be asking you anything else?
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 21

22. Eliciting Requirements

meetings are conducted and attended by both software engineers and
customers

rules for preparation and participation are established

A flexible 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
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 22

23. Eliciting Requirements
Conduct FA ST
m eet ings
Mak e lis t s of
f unc t ions , clas s es
Mak e list s of
c onst raint s, et c.
f orm al priorit iz at ion?
El i c i t re q u i re m e n t s
no
y es
Use QFD t o
priorit iz e
requirem ent s
def ine act ors
inf orm ally
priorit ize
requirem ent s
draw use-cas e
diagram
writ e s cenario
Creat e Use-cas es
c om plet e t em plat e
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 23

24. Quality Function Deployment




Function deployment determines the “value” (as perceived by
the customer) of each function required of the system
Information deployment identifies data objects and events
Task deployment examines the behavior of the system
Value analysis determines the relative priority of requirements
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 24

25. User-scenarios/use-cases

describe how the system will be used

Developers and users create a set of usage threads for
the system to be constructed
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 25

26. Elicitation Work Products

a statement of need and feasibility.

a bounded statement of scope for the system or product.

a list of customers, users, and other stakeholders who
participated in requirements elicitation

a description of the system’s technical environment.

a list of requirements (preferably organized by function)
and the domain constraints that apply to each.

a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.

any prototypes developed to better understand
requirements.
requirements
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 26

27. Use-Cases



A collection of user scenarios that describe the thread of usage of a system
Each scenario is described from the point-of-view of an “actor”—a person or
device that interacts with the software in some way
Each scenario answers the following questions:










Who is the primary actor, the secondary actor (s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What extensions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external
environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 27

28. Use-case Drawbacks

Lack of formality in use-case descriptions

Not all systems have explicitly defined actors

Use-cases are not inherently object-oriented

Developers have a tendency to functionally decompose usecases.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 28

29. Use Case Modeling

A full use-case model comprise of:



Use Case



A diagram, describing relations between use-cases and actors.
A document describing the use case in details
A sequence of actions a system performs to yield an observable result
of value to a particular actor
Stevens/Pooley: A task which an actor needs to perform with the help
of the system
Actor
Someone or something outside the system that interacts with the
system
 A user of the system in a particular role
SWE311_Ch07 (071)
 Actors are NOT part of the system

Software & Software Engineering
Slid
e 29

30. Use Case Diagram Objective
1.
2.
Create a semi-formal model of the functional requirements
Analyze and define:



Scope
External interfaces
Scenarios and reactions
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 30

31. What Makes Good Use-Case Specification?

Lack of ambiguity


Completeness


They should cater for all current demands of the system.
Consistency


Each requirement must be interpreted in a single manner.
Requirements should not conflict with each other. If there are,
tradeoffs must be detected and discussed.
Avoid design

Requirements should raise a need, not answer it. (Why?)
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 31

32. Use Cases



Each use case has a name
In the UML, a use case is represented as an oval
A family (or set, or class) of scenarios



A sequence of interactions
A set of different but related scenarios
Documenting Use Cases

A UML Diagram showing all of them




Actors are stick-figures; use cases are ovals
For each use case define using English
A clear textual description
A set of scenarios in outline form
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 32

33. Relationships between Use Cases

UML supports two relationships between two use cases
 <<includes>>



before UML 1.3 <<includes>> was <<uses>>
The source use case always includes the actions specified in the
target use case
<<extends>>

The target use case my include the behavior of the source use
case
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 33

34. Documenting Use Cases

Use case name


Summary


A brief description of the use case, typically one or two sentences.
Dependency


Each use case is given a name.
Description of whether the use case depends on other use cases, that is,
whether it includes or extends another use case.
Actors

Names of the actors that participate in the use case
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 34

35. Documenting Use Cases (Cont’d)

Preconditions


Description


Description of the main sequence of the use case, which is the most
usual sequence of interactions between the actor and the system.
Alternatives


One or more conditions that must be true at the start of the use case
Description of alternative branches off the main sequence.
Postcondition

Condition that is always true at the end of the use case if the main
sequence has been followed.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 35

36. Preconditions
•
•
One or more conditions that must be true at the start of the use
case
Examples



User account exists
User has enough money in her account
There is enough disk space
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 36

37. Post-Conditions


Condition that is always true at the end of the use case if the
main sequence has been followed.
Examples



Money was transferred to the user account
User is logged in
The file is saved to the hard-disk
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 37

38. Use-Cases – Common Mistakes




Complex diagram
No system
No actor
Too many user interface details


“User types ID and password, clicks OK or hits Enter”
Very low goal details




User provides name
User provides address
User provides telephone number
…
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 38

39. Example 1: Validate PIN Use Case

Use case name


Summary


System validates customer PIN.
Actor


Validate PIN
ATM Customer
Precondition
ATM is idle, displaying a Welcome message.
SWE311_Ch07 (071)
Software & Software Engineering

Slid
e 39

40. Example 1: Validate PIN
Use Case (Cont’d)

Description
1. Customer inserts the ATM card into the Card Reader.
2. If the system recognizes the card, it reads the card number.
3. System prompts customer for PIN number
4. Customer enters PIN
5. System Checks the expiration date and whether the card is lost or
stolen.
6. If card is valid, the system then checks whether the user-entered PIN
matches the card PIN maintained by the system.
7. numbers match, the system checks that accounts are accessible with the
ATM card.
8. System displays customer accounts and prompts customer for
transaction type: Withdrawal, Query, or Transfer.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 40

41. Example 1: Validate PIN
Use Case (Cont’d)

Alternatives







If the system does not recognize the card, the card is ejected.
If the system determines that the card date has expired, the card is confiscated.
If the system determines that the card has been reported lost or stolen, the card
is confiscated.
If the customer-entered PIN does not math the PIN number for this card, the
system re-prompts for the PIN.
If the customer enters the incorrect PIN three times, the system confiscates the
card.
If the customer enters Cancel, the system cancels the transaction and ejects the
card.
Postcondition

Customer PIN has been validated.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 41

42. Example 2: Withdraw Funds
Use Case

Use case name


Summary


ATM Customer
Dependency


Customer withdraws a specific amount of funds from a valid bank account.
Actor


Withdraw Funds
Include Validate PIN abstract use case
Precondition

ATM is idle, displaying a Welcome message.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 42

43. Example 2: Withdraw Funds
Use Case (Cont’d)

Description
1.
Include Validate PIN abstract use case.
2.
Customer selects Withdrawal, enters the amount, and selects the account
number.
3.
System checks whether customer has enough funds in the account and whether
the daily limit will not be exceeded.
4.
If all checks are successful, system authorizes dispensing of cash.
5.
System dispenses the cash amount.
6.
System prints a receipt showing transaction number, transaction type, amount
withdrawn, and account balance.
7.
System ejects card.
8.
System displays Welcome Message.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 43

44. Example 2: Withdraw Funds
Use Case (Cont’d)

Alternatives


If the system determines that there are insufficient funds in the
customer’s account, it displays an apology and eject the card.

If the system determines that the maximum allowable daily withdrawal
amount has been exceeded, it displays an apology and ejects the card.


If the system determines that the account number is invalid, it displays
an error message and ejects the card.
If the ATM is out of funds, the system displays an apology, ejects the
card, and shuts down the ATM.
Postcondition
Customer funds have been withdrawn.
Customer funds have
SWE311_Ch07 (071) been withdrawn.
Software & Software Engineering

Slid
e 44

45. The sections of a use case

Name. The name should implicitly express the user's intent or
purpose of the use case

Identifier [Optional]. A unique identifier, such as "UC1701,"
that can be used in other project artifacts to refer to the use
case.

Description. Several sentences summarizing the use case.

Actors [Optional]. The list of actors associated with the use
case.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 45

46. The sections of a use case (cont.)

Status [Optional]. An indication of the status of the use case,
typically one of: work in progress, ready for review, passed
review, or failed review.

Frequency. How often this use case is invoked by the actor.
Example, once per each user login or once per month.

Preconditions. A list of the conditions, if any, that must be
met before a use case may be invoked.
Postconditions. A list of the conditions, if any, that will be
true after the use case finishes successfully.
SWE311_Ch07 (071)
Slid
Software & Software Engineering
e 46


47. The sections of a use case (cont.)

Extended use case [Optional]. The use case that this use case extends (if
any).

Included use cases [Optional]. A list of the use cases this one includes.

Assumptions [Optional]. Any important assumptions about the domain
that you have made when writing this use case.

Basic course of action. The main path of logic an actor follows through a
use case. Often referred to as the main path because it describes how the
use case works when everything works as it normally should.

Alternate courses of action. The infrequently used paths of logic in a use
case, paths that are the result of an alternate way to work, an exception, or
an error condition.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 47

48. The sections of a use case (cont.)

Change history [Optional]. Details about when the use case
was modified, why, and by whom.

Issues [Optional]. A list of issues or action items, if any, that
are related to the development of this use case.

Decisions . A list of critical decisions pertaining to the content
of the use case. It is important to record these decisions to
maintain a group memory.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 48

49. An Example

A complete example may be found in the following site

http://www.cs.gordon.edu/courses/cs211/ATMExample/index.htm
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 49

50. Negotiating Requirements

Identify the key stakeholders


Determine each of the stakeholders “win conditions”


These are the people who will be involved in the negotiation
Win conditions are not always obvious
Negotiate

Work toward a set of requirements that lead to “win-win”
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 50

51. Key points







It's not a competition
Map out a strategy
Listen actively
Focus on other party's interests
Don't let it get personal
Be creative
Be ready to commit
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 51

52. Validating Requirements-I

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?
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 52

53. Validating Requirements-II

Is each requirement achievable in the technical environment that will house the
system or product?

Is each requirement testable, once implemented?

Does the requirements model properly reflect the information, function and
behavior of the system to be built.

Has the requirements model been “partitioned” in a way that exposes progressively
more detailed information about the system.
SWE311_Ch07 (071)
Software & Software Engineering
Slid
e 53