BCS501 SEPM RNSIT VISHESHJ, ISE

MODULE 2
CHAPTER 1 - UNDERSTANDING REQUIREMENTS

1. REQUIREMENTS ENGINEERING
• Requirements analysis, also called Requirements engineering, is the process of determining
user expectations for a new or modified product.

• Requirements engineering is a major software engineering action that begins during the
communication activity and continues into the modeling activity. It must be adapted to
the needs of the process, the project, the product, and the people doing the work.

• Requirements engineering builds a bridge to design and construction.

1.1. Requirements Engineering Task

Requirements engineering provides the appropriate mechanism for understanding what the cus-
tomer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying
the solution unambiguously, validating the specification, and managing the requirements as they
are transformed into an operational system.

It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation, specifi-

cation, validation, and management.

1. Inception: It establishes a 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 other stakeholders and the software team.

2. Elicitation: In this stage, proper information is extracted to prepare and document the
requirements. It certainly seems simple enough ask the customer, the users, and others
what the objectives for the system or product are, what is to be accomplished, how the
system or product fits into the needs of the business, and finally, how the system or product
is to be used on a day- to-day basis.

➢ 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, omit information that is
BCS501 SEPM RNSIT VISHESHJ, ISE

believed to be “obvious,” specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or un testable.
➢ Problems of volatility. In this problem, the requirements change from time to time
and it is difficult while developing the project.

3. Elaboration: The information obtained from the customer during inception and elicitation
is expanded and refined during elaboration. This task focuses on developing a refined re-
quirements model that identifies various aspects of software function, behavior, and in-
formation. 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.

4. Negotiation: To negotiate the requirements of a system to be developed, it is necessary to

identify conflicts and to resolve those conflicts. You have to reconcile these conflicts
through a process of negotiation. Customers, users, and other stakeholders are asked to
rank requirements and then discuss conflicts in priority. Using an iterative approach that
prioritizes requirements, assesses their cost and risk, and addresses internal conflicts, re-
quirements are eliminated, combined, and/or modified so that each party achieves some
measure of satisfaction.

5. Specification: The term specification means different things to different people. A speci-
fication can be a written document, a set of graphical models, a formal mathematical
model, a collection of usage scenarios, a prototype, or any combination of these.

6. Validation: Requirements validation examines the specification to ensure that all software
requirements have been stated unambiguously; that inconsistencies, omissions, and errors
have been detected and corrected; and that the work products conform to the standards
established for the process, the project, and the product. The primary requirements valida-
tion mechanism is the technical review. The review team that validates requirements in-
cludes software engineers, customers, users, and other stakeholders who examine the
specification looking for errors in content or interpretation, areas where clarification may
be required, missing information, inconsistencies, conflicting requirements, or unrealistic
requirements.

7. Requirements management. Requirements for computer-based systems change, and the

desire to change requirements persists throughout the life of the system.
It is a set of activities that help the project team to identify, control and track the require-
ments and changes can be made to the requirements at any time of the ongoing project.
Many of these activities are identical to the software configuration management (SCM)
techniques. These tasks start with the identification and assign a unique identifier to each
of the requirement. After finalizing the requirement traceability table is developed.
BCS501 SEPM RNSIT VISHESHJ, ISE

2. ESTABLISHING THE GROUNDWORK

There could be many issues to start Requirement Engineering Process:

• Customers or end users may be located in a different city/country.

• Customers do not have a clear idea of the requirements.
• Lack of technical knowledge or customers have limited time to interact with
requirement engineer.

Hence by following the below steps we can start a requirement engineering process.

1. Identifying Stakeholders

• Stakeholder is the one who benefits in a direct or indirect way from the system which is
being developed.

• Business operations managers, product managers, marketing people, internal and external
customers, end users, consultants, product engineers, software engineers, support and
maintenance engineers, and others.

• Each stakeholder has a different view of the system, achieves different benefits when the
system is successfully developed, and is open to different risks if the development effort
should fail.

2. Recognizing Multiple Viewpoints

• As many stakeholders exist, they all have different views regarding the system to be de-
veloped, hence it is the duty of software engineers to consider all the viewpoints of stake-
holders in a way that allows decision makers to choose an internally consistent set of re-
quirements for the system.

• For example, the marketing group is interested in functions and features that will excite the
potential market, making the new system easy to sell and End users may want features that
are easy to learn and use.

3. Working toward Collaboration

Collaboration does not necessarily mean that requirements are defined by committee. In many
cases, stakeholders collaborate by providing their view of requirements, but a strong “project
champion” (e.g., a business manager or a senior technologist) may make the final decision about
which requirements make the cut.

4. Asking the First Questions

Questions asked at the inception of the project should be “context free”. The first set of context
- free questions focuses on the customer and other stakeholders, the overall project goalsand
benefits. For example, you might ask:
 BCS501 SEPM RNSIT VISHESHJ, ISE

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

These questions help to identify all stakeholders who will have interest in the software to be built.
In addition, the questions identify the measurable benefit of a successful implementation and
possible alternatives to custom software development.

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.
Gause and Weinberg call these “meta-questions” and propose the following list:

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

These questions will help to “break the ice” and initiate the communication that is essential to suc-
cessful elicitation.

3. ELICITING REQUIREMENTS

Requirements Elicitation (also called requirements gathering) combines elements of problem

solving, elaboration, negotiation, and specification.

1) Collaborative Requirements Gathering

Many different approaches to collaborative requirements gathering have been proposed.
Each makes use of a slightly different scenario, but all apply some variation on the following
basic guidelines:
• 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 worksheets, 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 ap-
proaches, and specify a preliminary set of solution requirements in an atmosphere that is con-
ducive to the accomplishment of the goal.
During inception basic questions and answers establish the scope of the problem and the
overall perception of a solution. Out of these initial meetings, the developer and customers write a
one- or two-page “product request.”

A meeting place, time, and date are selected; a facilitator is chosen; and attendees from the
software team and other stakeholder organizations are invited to participate. The product request
is distributed to all attendees before the meeting date.

While reviewing the product request in the days before the meeting, each attendee is asked to
make a list of objects that are part of the environment that surrounds the system, other objects that
are to be produced by the system, and objects that are used by the system to perform its functions.
In addition, each attendee is asked to make another list of services that manipulate or interact with
the objects. Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria
(e.g., speed, accuracy) are also developed. The attendees are informed that the lists are not expected
to be exhaustive but are expected to reflect each person’s perception of the system.

The lists of objects can be pinned to the walls of the room using large sheets of paper, stuck to
the walls using adhesive-backed sheets, or written on a wall board. After individual lists are pre-
sented in one topic area, the group creates a combined list by eliminating redundant entries,
adding any new ideas that come up during the discussion, but not deleting anything.

Collaborative requirements gathering --- Scenario: Campus Event Management App

Step 1: Identify Stakeholders

• Students: Potential users who will attend events.
• Event Organizers: People who will create and manage events.
• University Administration: They might have specific requirements or policies to comply
with.
• Developers: The team responsible for building the app.

Step 2: Conduct Initial Meetings

Organize a kickoff meeting with all stakeholders to introduce the project and its goals.
• Use this meeting to explain the importance of gathering accurate requirements and how it
will impact the final product.

Step 3: Use Collaborative Techniques

• Brainstorming Session
• Surveys and Questionnaires
• Workshops and User Stories.

Step 4: Document and Validate Requirements

BCS501 SEPM RNSIT VISHESHJ, ISE

Step 5: Create a Prototype or Wireframes

Step 6: Iterate and Improve

2) Quality function deployment (QFD)

QFD is a quality management technique that translates the needs of the customer into
technical requirements for software. QFD “concentrates on maximizing customer satisfaction from
the software engineering process”. To accomplish this, QFD emphasizes an understanding of what
is valuable to the customer and then deploys these values throughout the engineering process.

QFD 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 satis-
fied. Examples of normal requirements might be requested types of graphical displays, spe-
cific 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. These features go beyond the customer’s expectations and prove
to be very satisfying when present.
For example, the mobile phone with standard features, but the developer adds few addi-
tional functionalities like voice searching, multi-touch screen etc. then the customer is
more excited about that feature.

Although QFD concepts can be applied across the entire software process, QFD uses cus-
tomer interviews and observation, surveys, and examination of historical data as raw data for the
requirements gathering activity. These data are then translated into a table of requirements—
called the customer voice table—that is reviewed with the customer and other stakeholders.
BCS501 SEPM RNSIT VISHESHJ, ISE

3) Usage Scenarios

• As requirements are gathered, an overall vision of system functions and features begins to
materialize.
• However, it is difficult to move into more technical software engineering activities until
you 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 that identify a thread
of usage for the system to be constructed. The scenarios, often called use cases, provide a
description of how the system will be used.

4) Elicitation Work Products

The work products produced as a consequence of requirements elicitation will vary de-
pending on the size of the system or product to be built. For most systems, the work products in-
clude:

• 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 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.

Each of these work products is reviewed by all people who have participated in requirements
elicitation.

4. DEVELOPING USE CASES

Use cases are defined from an actor’s point of view. An actor is a role that people (users)
or devices play as they interact with the software.

The first step in writing a use case is to define the set of “actors” that will be involved in
the story. Actors are the different people (or devices) that use the system or product within the
context of the function and behavior that is to be described.

Actors represent the roles that people (or devices) play as the system operates. Formally,
an actor is anything that communicates with the system or product and that is external to the system
itself.
Every actor has one or more goals when using the system. It is important to note that an
actor and an end user are not necessarily the same thing. A typical user may play a number of
BCS501 SEPM RNSIT VISHESHJ, ISE

different roles when using a system, whereas an actor represents a class of external entities (often,
but not always, people) that play just one role in the context of the use case. Different people may
play the role of each actor.

Because requirements elicitation is an evolutionary activity, not all actors are identified
during the first iteration. It is possible to identify primary actors during the first iteration and
secondary actors as more is learned about the system.

Primary actors interact to achieve required system function and derive the intended benefit
from the system. Secondary actors support the system so that primary actors can do their work.
Once actors have been identified, use cases can be developed.

Jacobson suggests a number of questions that should be answered by a use case:

• 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 exceptions 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?
Basic SafeHome requirements, we define four actors: homeowner (a user), setup manager (likely
the same person as homeowner, but playing a different role), sensors (devices attached to the sys-
tem), and the 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:
Considering the situation in which the homeowner uses the control panel, the basic use case for
system activation follows:
BCS501 SEPM RNSIT VISHESHJ, ISE

1. The homeowner observes the SafeHome control panel as shown in Fig 5.1 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.
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 incorrect and reset itself for
additional input. If the password is correct, the control panel awaits further action.
3. The homeowner select the 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. The basic use
case presents a high-level story that describes the interaction between the actor and the system.

Cockburn provides Detailed Description of Use Case:

USE CASE Initiate

Monitor-
ing

Primary actor Home Owner

Goal in context To set the system to monitor sensors when the homeowner leaves the house
or remains inside

Preconditions: System has been programmed for a password and to recognize various
sensors.

Trigger: The homeowner decides to “set” the system, i.e., to turn on the alarm
functions
BCS501 SEPM RNSIT VISHESHJ, ISE

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

1. Control panel is not ready: homeowner checks all sensors to deter-

Exceptions: mine which are open; closes them.
2. Password is incorrect (control panel beeps once): homeowner reen-
ters 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.
When available: First increment

Priority: Essential, must be implemented

Frequency of use: Many times per day

Channel to actor Via control panel interface

Secondary actors: Support technician, sensors

Channels 1. Support technician: phone line

to secondary ac- 2. Sensors: hardwired and radio frequency interfaces
tors:
Open issues: 1. Should there be a way to activate the system without the use of
a password or with an abbreviated 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?
Note:

The basic use case presents a high-level story that describes the interaction between the actor and
the system.

Fig 3.1-Use Case Diagram

- ----Primary Actors-Who initiate/interact directly Ex: Customer and Technician

BCS501 SEPM RNSIT VISHESHJ, ISE

------- --------Secondary Actor—Who supports the system Ex: Bank/Serve

------ Use Case (System) ----Functionality /service provided by the system.

- ---------Relation—It shows relation between actor and the system.

5. BUILDING THE REQUIREMENT 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 analysis model is a snapshot
of requirements at any given time.

3.5.1 Elements of the Requirements Model

The specific elements of the requirements model are dictated by the analysis modeling
method that is to be used. However, a set of generic elements is common to most requirements
models.
Scenario Based Elements: The system is described from the user’s point of view using a scenario-
based approach Ex: Use Case diagrams and Activity diagrams.

Class-based Elements: Each usage scenario implies a set of objects that are manipulated as an
actor interacts with the system. These objects are categorized into classes—a collection of things
that have similar attributes and common behaviors(operations). Ex: Class diagram, Collabora-
tion diagram.

Behavioral Elements: In Software Engineering, the Behavioral Elements Model is a concept used
to describe the dynamic behavior of a software system. It focuses on how the system's components
interact with each other and with external entities to achieve specific tasks or behaviors. The state
diagram is one method for representing the behavior of a system by depicting its states and the
events that cause the system to change state. This model indicates how the software will respond
on occurrence of external event. Ex: State diagram and Sequential Diagram.

Flow-Oriented elements: Information is transformed as it flows through a computer- based sys-

tem. The system accepts input in a variety of forms, applies functions to transform it, and pro-
duces output in a variety of forms. Ex: Data-Flow diagram, Control Flow diagram.

5.1. Analysis Patterns

Analysis patterns suggest solutions (e.g., a class, a function, a behavior) within the application domain
that can be reused when modeling many applications.

Geyer-Schulz and Hahsler suggest two benefits that can be associated with the use of analysis
patterns:
BCS501 SEPM RNSIT VISHESHJ, ISE

First, analysis patterns speed up the development of abstract analysis models that capture the main
requirements of the concrete problem by providing reusable analysis models with examples as well
as a description of advantages and limitations.

Second, analysis patterns facilitate the transformation of the analysis model into a design model
by suggesting design patterns and reliable solutions for common problems. Analysis patterns are
integrated into the analysis model by reference to the pattern name. They are also stored in a
repository so that requirements engineers can use

6. 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 (e.g., time, people, budget) that have been
placed on the software team. The best negotiations strive for a “win-win” result. That is, stake-
holders win by getting the system or product that satisfies the majority of their needs and you win
by working to realistic and achievable budgets and deadlines.

Boehm defines a set of negotiation activities at the beginning of each software process iter-
ation. 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.

Successful completion of these initial steps achieves a win-win result, which becomes the key
criterion for proceeding to subsequent software engineering activities.

7. VALIDATING REQUIREMENTS

As each element of the requirements model is created, it is examined for inconsistency,

omissions, and ambiguity. The requirements represented by the model are prioritized by the
stakeholders and grouped within requirements packages that will be implemented as software
increments.

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? 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
BCS501 SEPM RNSIT VISHESHJ, ISE

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?

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

These and other questions should be asked and answered to ensure that the requirements model is
an accurate reflection of stakeholder needs and that it provides a solid foundation for design