Module 2

Understanding
Requirements
Software Engineering
 Understand Requirements
 Understanding the requirements of a problem is among the most difficult
tasks that face a software engineer.

 When you first think about it, developing a clear understanding of

requirements doesn’t seem that hard.

 After all, doesn’t the customer know what is required?

 Shouldn’t the end users have a good understanding of the features and
functions that will provide benefit?

 Surprisingly, in many instances the answer to these questions is “no.”

 REQUIREMENTS ENGINEERING
The broad spectrum of tasks and techniques that lead to an understanding of requirements
is called requirements engineering.

Requirements engineering builds a bridge to design and construction.

Requirements engineering provides the appropriate mechanism for understanding

what the customer wants
Inception.
How does a software project get started?

Elicitation.
It certainly seems simple enough(objectives, accomplished, product fits and fi-
nally, product is to be used.

• Problems of scope (customers specify unnecessary technical detail that may confuse)

• Problems of understanding (a poor understanding of the capabilities and limitations)

• Problems of volatility (The requirements change over time.)

To help overcome these problems, you must approach requirements gathering in an

organized manner.
Elaboration.
The information obtained from the customer during inception and elicitation is
expanded and refined during elaboration.

Elaboration is driven by the creation and refinement of user scenarios that de-
scribe how the end user (and other actors) will interact with the system

Negotiation.
It isn’t unusual for customers and users to ask for more than can be achieved,
given limited business resources.

You have to reconcile these conflicts through a process of negotiation.

Specification.
A specification can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios, a prototype.

Validation.
Requirements validation examines the specification to ensure Correctness

Requirements management.
Requirements for computer-based systems change

Help the project team to identify, control, and track requirements and changes
to requirements at any time as the project proceeds
 ESTABLISHING THE GROUNDWORK
1) Identifying Stakeholders
“anyone who benefits in a direct or indirect way from the system which is being
developed.”

2) Recognizing Multiple Viewpoints

Requirements of the system will be explored from many different points of view

3) Working toward Collaboration

stakeholders collaborate by providing their view of requirements

4) Asking the First Questions

These questions help to identify all stakeholders who will have interest in the software
to be built:
 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
allows the customer to voice his or her perceptions about a solution:

 How would you characterize “good” output that would be generated by a successful
solution?
 What problem(s) will this solution address?
 Can you show me (or describe) the business environment in which the 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?
 ELICITING REQUIREMENTS

Requirements elicitation (also called requirements gathering) combines

elements of problem solving, elaboration, negotiation, and specification.

To encourage a collaborative, team-oriented approach to requirements

gathering, stakeholders work together.
1) Collaborative Requirements Gathering: Many different approaches to
collaborative requirements gathering have been proposed.

 Meetings are conducted and attended by both software engineers and other
stakeholders.

 Rules for preparation and participation are established.

 An agenda is suggested that is formal enough to cover all important points but
informal enough to encourage the free flow of ideas.

 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.
2) Quality Function Deployment - (QFD) is a quality management technique that
translates the needs of the customer into technical requirements for software.

 Normal requirements. The objectives and goals that are stated for a product or
system during meetings with the customer

 Expected requirements. These requirements are implicit to the product or system

and may be so fundamental that the customer does not explicitly state them.

 Exciting requirements. These features go beyond the customer’s expectations and

prove to be very satisfying when present.
3) Usage Scenarios
 As requirements are gathered, an overall vision of system functions and
features begins to materialize.

 Understand how these functions and features will be used by different

classes of end users.

 To accomplish this, developers and users can create a set of scenarios.

 Often called use cases, provide a description of how the system will be used.
4) Elicitation Work Products – Product produced as a consequence of
elicitation will vary depending on the size of the product to be built.

 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.
 DEVELOPING USE CASES
The first step in writing a use case is to define the set of “actors” that will be
involved in the story.

Once actors have been identified, use cases can be developed. Jacobson
suggests 10 questions that should be answered by a use case:
1) Who is the primary actor, the secondary actor(s)?
2) What are the actor’s goals?
3) What preconditions should exist before the story begins?
4) What main tasks or functions are performed by the actor?
5) What exceptions might be considered as the story is described?
6) What variations in the actor’s interaction are possible?
7) What system information will the actor acquire, produce, or change?
8) Will the actor have to inform the system about changes in the external environment?
9) What information does the actor desire from the system?
10)Does the actor wish to be informed about unexpected changes?
 USE CASE: CASE STUDY ON “SAFEHOME”

Basic SafeHome requirements, we define four actors:

1) Homeowner (a user),

2) Setup manager (likely the same person as homeowner, but playing a

different role),

3) Sensors (devices attached to the system), and

4) Monitoring and response subsystem (the central station that

monitors the SafeHome home security function).
For the purposes of this example, we consider only the homeowner
actor.
The homeowner actor interacts with the home security function in a number
of different ways using either the alarm control panel 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.

 Presses the panic button in an emergency.

 Activates/deactivates the security system.

Considering the situation in which the homeowner uses the control panel, the
basic use case 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 on the LCD
display, and the homeowner must physically close windows or doors so that the not
ready message disappears. [A not ready message implies that a sensor is open; i.e.,
that a door or window is open.]

2. The homeowner uses the keypad to key in a four-digit password. The password is
compared with the valid password stored in the system. If the password is incor-
rect, the control panel will beep once and reset itself for additional input. If the
password is correct, the control panel awaits further action.
3. The homeowner selects and keys in stay or away to activate the system. Stay activates
only perimeter sensors (inside motion detecting sensors are deactivated). Away
activates all sensors.

4. When activation occurs, a red alarm light can be observed by the homeowner.
 Uses cases are further elaborated to provide considerably more detail about the
interaction.
 For example, Cockburn suggests the following template for detailed
descriptions of use cases:
Scenario:
1. Homeowner: observes control panel
2. Homeowner: enters password
3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that SafeHome has been armed

Exceptions:
1) Control panel is not ready: homeowner checks all sensors to determine which are
open; closes them.
2) Password is incorrect: homeowner reenters correct password.
3) Password not recognized: monitoring and response subsystem must be contacted to
reprogram password.
4) Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are
activated.
5) Away is selected: control panel beeps three times and an away light is lit; all sensors
are activated.
Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors
Channels to secondary actors:
Support technician: phone line
Sensors: hardwired and radio frequency interfaces

Open issues:
1) Should there be a way to activate the system without the use of a password or with
anabbreviated password?
2) Should the control panel display additional text messages?
3) How much time does the homeowner have to enter the password from the time the
first key is pressed?
4) Is there a way to deactivate the system before it actually activates?
UML Use Case diagram
for
“SafeHome”
Home Security
Function
 BUILDING THE REQUIREMENTS MODEL

 The intent of the analysis 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 be built, and
other stakeholders understand more about what they really require.
1) Elements of the Requirements Model
Scenario-based elements: The system is described from the user’s point of
view using a scenario-based approach
Class-based elements: Each usage scenario implies a set of objects that are
manipulated as an actor interacts with the system.
Behavioral elements: the requirements model must provide modeling
elements that depict behavior

Flow-oriented elements: Information is transformed as it flows through a

computer-based system.
 2) Analysis Patterns
Geyer-Schulz and Hahsler suggest two benefits that can be associated with the use of
analysis patterns:

1) Analysis patterns speed up the development of abstract analysis models with main
requirements and also reusable analysis models.

2) Analysis patterns facilitate the transformation of the analysis model into a design
model by suggesting design patterns and reliable solutions.
 Problem Statement for Students

Title: Ensuring timely Parcel delivery and collecting customer’s feedback for the
offered services in tamperproof manner

Description: Currently, postman delivers a parcel and takes signature from customer
in paper format. No live/online feedback mechanism is available to check customer’s
satisfaction. Also, chances are that postmen can tamper with the feedback to
suit their requirements. We wish to have a foolproof system which will enable user
to collect customer’s feedback without allowing postman to tamper with the
feedback
 NEGOTIATING REQUIREMENTS
The intent of negotiation is to develop a project plan that meets stakeholder needs
while at the same time reflecting the real-world constraints

Rather than a single customer communication activity, the following activities are
defined:

1) Identification of the system or subsystem’s key stakeholders.

2) Determination of the stakeholders’ “win conditions.”

3) Negotiation of the stakeholders’ win conditions to reconcile them into a set of

win-win conditions for all concerned (including the software team).
 VALIDATING REQUIREMENTS
A review of the requirements model addresses the following questions:

 Is each requirement consistent with the overall objectives for the system/product?

 Have all requirements been specified at the proper level of abstraction?

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

 Do any requirements conflict with other requirements?

 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?
Requirements Modeling:
Scenarios, Information,
and Analysis Classes
 REQUIREMENTS ANALYSIS
Requirements analysis results in the specification of software’s operational characteristics

The requirements modeling action results in one or more of the following types
of models:

 Scenario-based models - requirements from “actors” point of view

 Data models - information domain for the problem

 Class-oriented models - object-oriented classes (attributes and operations)

 Flow-oriented models - functional elements and data flow

 Behavioral models - software behaves because of external “events”

 1) Overall Objectives and Philosophy

Throughout requirements modeling, your primary focus is on what, not how:

What user interaction occurs in circumstance?
What objects does the system manipulate?
What functions must the system perform?
What behaviors does the system exhibit?
What interfaces are defined? and
What constraints apply?

The requirements model must achieve three primary objectives:

(1) To describe what the customer requires,
(2) To establish a basis for the creation of a software design, and
(3) To define a set of requirements that can be validated once the software is built.
 2) Analysis Rules of Thumb
Rules of thumb that should be followed when creating the analysis model:

 The model should focus on requirements that are visible within the problem

 Each element of the requirements model should add to an overall understanding

 Delay consideration of infrastructure and other nonfunctional models until design

 Minimize coupling throughout the system

 Be certain that the requirements model provides value to all stakeholders

 Keep the model as simple as it can be.

 3) Domain Analysis
Software domain analysis is the identification, analysis, and specification of common
requirements from a specific application domain
4) Requirements Modeling Approaches
SCENARIO-BASED MODELING
 1) Creating a Preliminary Use Case
Characterizes a use case as a “contract for behavior”

(1) What to write about,

(2) How much to write about it,
(3) How detailed to make your description, and
(4) How to organize the description?

These are the questions that must be answered if use cases are to provide
value as a requirements modeling tool.
 2) Refining a Preliminary Use Case
A description of alternative interactions is essential for a complete understanding
of the function that is being described by a use case.

Each step in the primary scenario is evaluated by asking the following questions:

 Can the actor take some other action at this point?

 Is it possible that the actor will encounter some error condition at this point?

 Is it possible that the actor will encounter some other behavior at this point
 3) Writing a Formal Use Case
Use Case Template can be included (It may vary depend on Problem statement):
1) Iteration
2) Primary actor
3) Goal in context
4) Preconditions
5) Trigger
6) Scenario
7) Exceptions
8) Priority
9) When available
10)Frequency of use
11)Channel to actor
12)Secondary actors
13)Channels to secondary actors
14)Open issues
UML MODELS THAT SUPPLEMENT
THE USE CASE
1) Developing an
Activity Diagram
The UML activity diagram
supplements the use case
by providing a graphical
representation of
the flow of interaction
within a specific sce-
nario.
2) Swimlane Diagrams

The UML swimlane diagram is a

useful variation of the activity
diagram and allows you to repre-
sent the flow of activities described
by the use case and at the same time
indicate which actor
 DATA MODELING CONCEPTS

If software requirements include the need to create, extend, or interface

with a database or if complex data structures must be constructed and
manipulated, the software team may choose to create a data model as
part of overall requirements modeling.
 1) Data Objects
 A data object is a representation of composite information that must be understood
by software.

 A data object can be an external entity, a thing, an occurrence or event, a role, an

organizational unit, a place, or a structure.

 A data object encapsulates data only—there is no reference within a data object to

operations that act on the data.

 The data object can be represented as a table as shown in Figure

 2) Data Attributes
 Data attributes define the properties of a data object and take on one of three
different characteristics.

 They can be used to

(1) name an instance of the data object,
(2) describe the instance, or
(3) make reference to another instance in another table.

 In addition, one or more of the attributes must be defined as an identifier—that is,

the identifier attribute becomes a “key” when we want to find an instance of
the data object.
 3) Relationships
 Data objects are connected to one another in
different ways.

 A connection is established between objects

because the two objects are related.

 But what are the relationships?

 To determine the answer, you should

understand the role of objects within the
context of the software to be built.
 CLASS-BASED MODELING
Class-based modeling represents the objects that the system will manipulate.

The operations that will be applied to the objects to effect the manipulation, relation-
ships between the objects, and the collaborations that occur between the classes that
are defined.

The elements of a class-based model include

o Classes and Objects,
o Attributes,
o Operations,
o Class Responsibility- Collaborator (CRC) models,
o Collaboration diagrams, and
o Packages.
 1) Identifying Analysis Classes
Analysis classes manifest themselves in one of the following ways:
 External entities that produce or consume information to be used by a
computer-based system.
 Things that are part of the information domain for the problem.
 Occurrences or events that occur within the context of system operation.
 Roles played by people who interact with the system.
 Organizational units that are relevant to an application.
 Places that establish the context of the problem and the overall function of the
system.
 Structures that define a class of objects or related classes of objects.
To identify classes by examining the usage scenarios developed as part of the
requirements model and performing a “grammatical parse” on the use cases de-
veloped for the system to be built.
 Coad and Yourdon suggest six selection characteristics that should be
used as you consider each potential class for inclusion in the analysis model:

1) Retained information: information about it must be remembered.

2) Needed services: must have a set of identifiable operations.

3) Multiple attributes: the focus should be on “major” information;

4) Common attributes: these attributes apply to all instances of the class.

5) Common operations: these operations apply to all instances of the class.

6) Essential requirements: produce or consume information essential to the operation

 2) Specifying Attributes
 Attributes describe a class that has been selected for inclusion in the requirements
model.

 To develop a meaningful set of attributes for an analysis class, you should study each
use case and select those “things” that reasonably “belong” to the class.

 To illustrate, we consider the System class defined for SafeHome:

 3) Defining Operations
Operations define the behavior of an object. Although many different types of operations
exist, they can generally be divided into four broad categories:

(1) Operations that manipulate data in some way,

(2) Operations that perform a computation,

(3) Operations that inquire about the state of an object, and

(4) Operations that monitor an object for the occurrence of a controlling event.
 4) Class-Responsibility-Collaborator (CRC)
Modeling
 CRC modeling provides a simple means for identifying and organizing the classes
that are relevant to system or product requirements.

 Ambler describes CRC modeling in the following way:

 A CRC model is really a collection of standard index cards that represent classes. The
cards are divided into three sections.

(1) Along the top of the card you write the name of the class.
(2) In the body of the card you list the class responsibilities on the left and
(3) the collaborators on the right.
 Responsibilities. Basic guidelines for identifying responsibilities
(attributes and operations)
1) System intelligence should be distributed across classes to best address the needs of
the problem.

2) Each responsibility should be stated as generally as possible.

3) Information and the behavior related to it should reside within the same class.

4) Information about one thing should be localized with a single class, not distributed
across multiple classes.

5) Responsibilities should be shared among related classes, when appropriate.

Collaborations. Classes fulfill their responsibilities in one of two ways:

(1) A class can use its own operations to manipulate its own attributes, thereby
fulfilling a particular responsibility, or

(2) A class can collaborate with other classes.

Collaborations are identified by determining whether a class can fulfill each

responsibility itself.

If it cannot, then it needs to interact with another class. Hence, a collaboration.

 5) Associations and Dependencies
 In many instances, two analysis classes are related to one another in some fashion,
much like two data objects may be related to one another.

 In UML these relationships are called associations.

 In some cases, an association may be further defined by indicating multiplicity.

 In many instances, a client-server relationship exists between two analysis classes.

 In such cases, a client class depends on the server class in some way and a
dependency relationship is established.
Multiplicity Dependencies
 6) Analysis Packages
An important part of analysis modeling is categorization.

That is, various elements of the analysis model are categorized in a manner
that packages them as a grouping—called an analysis package—that is given a
representative name.
End of Module 2