Introduction to Software Engineering

Chapter 5
 Understanding Requirements

Software Engineering: A Practitioner’s Approach, 7/e

by Roger S. Pressman

1
 Requirements Engineering
 Many software developers want to jump right in building software before they
have a clear understanding of what is needed. They argue that things will
become clear as they build, that project stakeholders will be able to
understand need only after examining early iterations of the software, that
things change so rapidly that any attempt to understand requirements in
details is a waste of time. The bottom line is producing a working program
and all else is secondary.
 What makes these arguments seductive is that they contain elements of
truth. But each is flawed and can lead to a failed software project.

 The broad spectrum of tasks and techniques that lead to an understanding of

requirements is called requirements engineering. It beings with
communication activity and continues into the modeling activity. It builds a
bridge to design and construction.

2
 Requirements Engineering
It encompasses seven tasks. Some tasks can occur in parallel.
 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
 Elicitation—ask customers, users what the objectives for the system or product are, , what is
to be accomplished, how the system fits into the needs of the business and how the system is
to be used on a day-today basis. elicit requirements from all stakeholders. A number of
problems that are encountered as elicitation occurs.
 Problems of scope. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail
that may confuse, rather than clarify, overall system objectives.
 Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities
and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the
system engineer,
 Problems of volatility. The requirements change over time.

.
3
 Requirements Engineering…..
 Elaboration—the information obtained from the
customer during inception and elicitation is expanded
and redefined during elaboration. create an analysis
model that identifies, expand and refine data, function
and behavioral requirements. Driven by user
scenarios that describe how the end users and other
actors will interact with the system.

These slides are designed to accompany

Software Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill, 2009).
Slides copyright 2009 by Roger
Pressman.
4
Requirements Engineering…
 Negotiation—agree on a deliverable system that is
realistic for developers and customers
 Specification—can be any one (or more) of the following:
 A written document
 A set of graphical models
 A formal mathematical model
 A collection of user scenarios (use-cases)
 A prototype

These slides are designed to accompany

Software Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill, 2009).
Slides copyright 2009 by Roger
Pressman.
5
 Requirements Engineering…
 Validation—a review mechanism that looks for review team to find errors in
content or interpretation
 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.
 Requirements management— Requirements change and the desire to change
persists throughout the life of the system. Help the project team identify, control
and track requirements and changes to requirements at any time as the project
proceeds.

.
6
 Inception: Establish the Groundwork
1. Identify stakeholders (who benefit directly or indirectly from the system)
 Suggested List and will grow: Business operations managers, product managers,
marketing people, customers, end users, consultants, product engineers, support
engineer, software engineer. Each stakeholder has a different view of the system.
 “who else do you think I should talk to?” is asked for every stakeholder
2. Recognize multiple points of view and category
 As information from multiple viewpoints is collected , emerging requirements may be
inconsistent or may conflict with one another. Categorize all stakeholder information
(including inconsistent and conflicting requirements) in a way that will allow decision
makers to choose an internally consistent set of requirements for the system.

7
3. Work toward collaboration
 If five stakeholders are involved in a software project, it may
have five (or more) different opinions about the proper set of
requirements. Customers (and other stakeholders) must
collaborate among themselves and with software engineering
practitioners if a successful system is to result. But how is this
collaboration accomplished?
 The job of a requirements engineer is to identify areas of
commonality (i.e., requirements on which all stakeholders agree)
and areas of conflict or inconsistency (i.e., requirements that are
desired by one stakeholder but conflict with the needs of another
stakeholder.

8
 Inception Questions
4. Asking the First Questions:
The first set of context-free questions focuses on the customer and other stakeholders, the overall project goals and
benefits.
 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 ?
The next set of questions enables you to gain a better understanding of the problem and allow
customers to voice their perceptions about solutions
 How would you characterize “good” output that would be generated by a successful solution?
 What problems will this solution address?
 Can you show or describe me the business environment in which solution will be used?
 Will special performance issues or constraints affect the way the solution is approached?

The final set of questions focuses on the effectiveness of the communication activity itself.
 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?

.
9
 3. Eliciting or Gathering Requirements
Requirements elicitation combines elements of problem solving, elaboration,
negotiation and specification. Some basic guidelines for productive
collaborative work:
3.1 Collaborative Requirements Gathering
 meetings are conducted and attended by both software engineers and customers
 rules for preparation and participation are established
 an agenda is suggested (formal enough and be flexible)
 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

.
10
 3.2 Quality Function Deployment(QFD)
 QFD is a quality management technique that translates the needs of the customer into
technical requirements for software. It concentrates on maximizing customer satisfaction
from the software engineering process. It identifies three types of requirements.
 Normal requirements.
The objectives and goals that are stated for a product or system during meetings with the customer.If these
requirements are present, the customer is satisfied. Examples of normal requirements might be requested types of
graphical displays, specific system functions, and defined levels of performance.
 Expected requirements.
These requirements are implicit to the product or system and may be so fundamental that the customer does
not explicitly state them. Their absence will be a cause for significant dissatisfaction. Examples of expected
requirements are: ease of human/machine interaction, overall operational correctness and reliability, and ease of
software installation.
 Exciting requirements:
Features go beyond the customer’s expectations and prove to be very satisfying when present. For example,
software for a new mobile phone coupled with a set of additional capabilities, multi-touch screen, visual voice mail
that delight every users of the product.

 Function deployment determines the “value” (as perceived by the customer) of each
function required of the system and deploys these values throughout.

.
11
 3.3 Elicitation Work Product
 Will vary depending on the size of the system or product to be built.
For most systems, the work products include:
 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 define requirements.

.
12
 Developing Use Cases
 As requirements are gathered, an overall vision of system functions
and features beings to materialize. However, it is difficult to move into
more technical software engineering activates until you understand
how these functions and features will be used by different classes of
end users.
 Developers and users can create a set of scenarios that identify a
thread of usage for the system to be constructed. The scenarios often
called use cases, proved a description of how the system will be used.
 In essence, a use case tells a stylized story about how an end user
interacts with the system under a specific set of circumstances.
 The story can be a narrative text, an outline of tasks or interactions, a
template-based description, or a diagrammatic representation.

13
 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 ( not necessarily users). External entities. For example, a machine
in four different modes of programming, test, monitoring and troubleshooting modes. Four actors
can be defined. Programmer, tester, monitor, and troubleshooter. In some cases, the machine
operator can play all of these roles. Or different people can play different roles.
 Once actors are defined, use cases can be developed. Each scenario answers the following
questions:
 Who is the primary actor, the secondary actor (s) ( to support the primary actors)?
 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?

14
 system name
ATM System system boundary

primary actor
1
Withdraw secondary actor
Money

2
Bank Deposit
Customer Money

Customer
Accounts
Database
role 3
Transfer
Money
association

<<Customer
4 Accounts
Check Database>>
use case Balance

alternative actor
notation

stereotype
CMSC 345, Version 9/07
S. Mitchell 15
 Use-Cases for SafeHome

 Four actors are defined: homeowner ( a user), setup manager (likely the same person as
homeowner but playing a different role), sensors (device attached to the system), and the
monitoring and response subsystem ( the central station that monitors the home security
function).
 To simplify the example, we only consider homeowner actor, who interacts with the home
security function in a number of different ways using either the alarm control pane or a PC.
 Enters a password to allow all other interactions
 Inquires about the status of a security zone
 Inquires about the status of a sensor
 Press the panic button in an emergency
 Activates/deactivate the security system
Considering the situation in which the homeowner uses the control panel, the basic use case
(presenting a high-level story) for system activation follows:

1. The homeowner observes the SafeHome control panel to determine if the system is ready for
input. If the system is not ready, a not ready message is displayed, and the homeowner
must physically close windows or doors so that not ready message disappears. ( not ready
means sensor is open when door window is open)

16
 Use-Cases for SafeHome
 2. The homeowner uses the keypad to key in a four-digit password. The password is
compared with the valid password. If it is incorrect, the control panel will beep once and
reset itself for additional input. If the password is correct, the control panel awaits further
actions.
 3. The homeowner selects and keys in stay or away to activate the system. Stay activates
only perimeter sensors ( inside motion detecting sensor are deactivated). Away activates all
sensors.
 4. When activation occurs, a read alarm light can be observed by the homeowner.

 Uses cases are further elaborated to provide more details.

 Precondition: system has been programmed for a password and to recognize various
sensors

 Trigger: the homeowner decided to set the system to turn on the alarm function.

 Scenario: 1. homeowner observes control panel, 2. enter password, 3. select stay or away,
4. observes red alarm light to indicate that the house has been armed.

 Exceptions: 1. control panel is not ready ( check door open) 2. password is incorrect 3.
correct password is not recognized.
These slides are designed to accompany
Software Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill, 2009).
Slides copyright 2009 by Roger
Pressman.
17
 Building The Requirement Models
 The intent of the analysis/requirement model is to provide a description of the required
informational, functional, and behavioral domains for a computer-based system. The model
changes dynamically as you learn more about the system to build. Other stakeholders
understand more about what they rally require.
 There are different modes of representation that force you to consider requirements from
different viewpoints---an approach that has a higher probability of uncovering omissions,
inconsistencies, and ambiguity.
 A set of generic Elements of the analysis model that are common to all models.
 Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the system
 Class-based elements
• Each usage scenario implies a set of objects (actors) that are categorized into classes. State
diagram
 Behavioral elements
• State diagram is one method by depicting its states and the events that cause the system to
change state.
 Flow-oriented element
• Data flow diagram, input, transform it and produce output.

18
UML Use Case Diagram
Ar m s / d is a r m s
s ys t e m

Ac c e s s e s s ys t e m s e ns or s
via Int e r ne t

h om e ow ne r

Re s po n ds t o
a la r m e ve n t

En c o unt e r s a n
e r r or c o nd it io n

s ys t e m Re c on f ig ur e s s e ns o r s
a d m in is t r a t o r a n d r e la t e d
s ys t e m fe a t ure s
Activity Diagrams
 Activity diagram is basically a flow chart to
represent the flow form one activity to another
activity. The activity can be described as an
operation of the system.
 So the control flow is drawn from one operation to
another. This flow can be sequential, branched or
concurrent. Activity diagrams deals with all type of
flow control by using different elements like fork,
join etc.
 The purposes can be described as:
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of
the system.

20
 UML Activity Diagrams
Eliciting Requirements
Co n d u c t FAST
m e e t in g s

Ma k e lis t s o f
fu n c t io n s , c la s s e s

Ma k e lis t s o f
c o n s t ra in t s , e t c .

fo rm a l p rio rit iz a t io n ?
Elic it re q u ire m e n t s
ye s no

Us e Q FD t o in fo rm a lly d e fin e a c t o rs
p rio rit iz e p rio rit iz e
re q u ire m e n t s re q u ire m e n t s

d ra w u s e -c a s e
writ e s c e n a rio
d ia g ra m

Cre a t e Us e -c a s e s
c o m p le t e t e m p la t e
 Activity diagrams
 Useful to specify software or hardware system behaviour
 Based on data flow models – a graphical representation
(with a Directed Graph) of how data move around an
information system

[order reject]

Receive Fill Ship Close

Order Order Order Order
[order
accepted]

Send Accept
Invoice Make Payment
Invoice Payment

22
 UML class diagrams
show the classes of the system, their inter-relationships,
and the operations and attributes of the classes
 Explore domain concepts in the form of a domain
model
 Analyze requirements in the form of a
conceptual/analysis model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23
Classes
A class is a description of a set of
ClassName objects that share the same attributes,
operations, relationships, and
attributes semantics.

Graphically, a class is rendered as a

operations rectangle, usually including its name,
attributes, and operations in separate,
designated compartments.

Software Design (UML)

Class Names

The name of the class is the only

ClassName required tag in the graphical
representation of a class. It always
attributes appears in the top-most compartment.

operations

Software Design (UML)

Class Attributes

Person

name : String An attribute is a named property of a

address : Address class that describes the object being modeled
birthdate : Date In the class diagram, attributes appear in
ssn : Id the second compartment just below the
name-compartment.

Software Design (UML)

Class Attributes (Cont’d)
Attributes are usually listed in the form:
Person attributeName : Type

name : String A derived attribute is one that can be

address : Address computed from other attributes, but
birthdate : Date doesn’t actually exist. For example,
/ age : Date a Person’s age can be computed from
ssn : Id his birth date. A derived attribute is
designated by a preceding ‘/’ as in:

/ age : Date

Software Design (UML)

Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id
eat Operations describe the class behavior
sleep and appear in the third compartment.
work
play

Software Design (UML)

 Depicting Classes
When drawing a class, you needn’t show attributes and
operation in every diagram.

Person Person Person

name : String
birthdate : Date
Person ssn : Id
name Person eat()
address sleep()
birthdate eat work()
play play()

Software Design (UML)

Class Diagram

From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

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

30
 state diagram:
 Depicts data and behavior of a single object
throughout its lifetime.
 set of states (including an initial start state)
 transitions between states
 entire diagram is drawn from that object's perspective

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 31
State diagram example
States
 state: conceptual description of the data in the
object
 represented by object's field values

 entire diagram is drawn from the

central object's perspective
 only include states / concepts that
this object can see and influence
 don't include every possible value
for the fields; only ones that are
conceptually different
 UML State Diagram
Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables

Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities

software embedded within control panel that is

responsible for reading user input.

34
 Negotiating Requirements
 Even after inception, elicitation and elaborations, customer requirements are still
not sufficient in details to proceed to next activity.
 Stakeholders need to balance functionality, performance and other product or
system characteristics against cost and time-to-market.
 Thus, negotiation is to develop a project plan that meets stakeholder needs
while at the same time reflecting the real-world constraints such as time, people
and budget.
 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” for all concerned
including the software team.

35
 Art of Negotiation
 Recognize that is is not a competition. To be successful, both parties
have to feel they’ve won and achieved something. Both will have to
compromise.
 Map out a strategy. Decide what you want to achieve and what the other
party wants to achieve and how you will go about making both happen.
 Listen actively. Do not work on formulating your response while the
other party is talking. Listen and better negotiate your position.
 Focus on the other party’s interest. Do not take hard position if you want
to avoid conflicts.
 Do not let it get personnel. Focus on the problem.
 Be creative. Do not be afraid of think out of the box if you are at an
impasse.
 Be ready to commit. Once an agreement has been reached, do not
waffle, commit to it and move on.

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

37
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.
 Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly
validated? Are all patterns consistent with customer
requirements?

38