Requirements Engineering
Eliciting Requirements
Eliciting Requirements
• The goal of requirements elicitation is to understand what the
system or product is supposed to achieve, how it fits into the
business's needs, and how it will be used on a daily basis. In
other words, it's about getting a clear picture of what the
software needs to do.
The techniques of eliciting requirements
1. Collaborative requirement gathering
2. Quality Function Deployment (QFD)
3. User scenarios
4. Elicitation Work Products
Eliciting Requirements
• 1.Collaborative requirement gathering:
In order to encourage a collaborative, team-oriented approach to
requirements gathering, a team of stakeholders and developers
work together to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a
preliminary set of solution requirements.
• Many different approaches to collaborative requirements
gathering have been proposed. Each of these approaches follow
some basic guidelines:
• Meetings are conducted and attended by both software engineers
and customers (along with other interested stakeholders).
• Rules for preparation and participation are established.
Eliciting Requirements
• An agenda is suggested to cover all important points and it
also encourages 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.
• The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a
preliminary set of solution requirements in an atmosphere
that is conducive to the accomplishment of the goal.
Eliciting Requirements
• 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 stakeholders
write a one- or two-page "product request.
• A meeting place, time , and date are selected and
a facilitator is chosen.
• Members of the software team and other
stakeholder organizations are invited to attend.
• The product request is distributed to all attendees
before the meeting date.
Eliciting Requirements
• 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 list services(processes
or functions) 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.
Eliciting Requirements
• An pre-meeting document is provided to illustrate how
different participants might contribute information about the
system's functionality and requirements.
• The requirements gathering team is composed of
representatives from marketing , software and hardware
engineering, and manufacturing. An outside facilitator is to be
used.
Eliciting Requirements
Example: Safe home project
• Each person develops the lists.
• Objects described for Safe-Home might include the control panel,
smoke detectors, window and door sensors ,motion detectors, an alarm,
an event (a sensor has been activated), a display, a PC,telephone
numbers, a telephone call, and so on.
• The list of services might include configuring the system, setting the
alarm, monitoring the sensors, dialing the phone, programming the
control panel, and reading the display (note that services act on objects).
• In a similar fashion, each attendee will develop lists of constraints (e.g.,
the system must recognize when sensors are not operating, must be
user-friendly, must interface directly to a standard phone line) and
performance criteria (e.g., a sensor
event should be recognized within one second an event priority scheme
should be implemented ).
Eliciting Requirements
• As the requirements gathering meeting begins, the first topic of
discussion is the need and justification for the new product—
everyone should agree that the product meets he
requirements.
• Once agreement has been established, each participant
presents his lists for discussion.
• The lists 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.
• Alternatively, the lists may have been posted on an electronic
bulletin board, at an internal Web site, or posed in a chat room
environment for review prior to the meeting.
Eliciting Requirements
• At this stage, critique and debate are strictly prohibited.
• After individual lists are presented and a combined list is created
by the group.
• The combined list eliminates redundant entries, adds any new
ideas that come up during the discussion, but does not delete
anything.
• After combined lists have been created, the facilitator
coordinates discussion.
• The combined list is shortened to properly reflect the
product/system to be developed.
• The objective is to develop a agreement list in each topic area
(objects, services, constraints, and performance). The lists are
then set aside for later action.
Eliciting Requirements
• Once the agreement lists have been completed, the team is
divided into smaller sub teams.
• Each works to develop mini- specifications for one or more
entries on each of the lists .
• Each mini-specification is an elaboration of the word or
phrase contained on a list.
• For example, the mini-specification for the Safe Home object
Control Panel might be:
• The Control Panel is a wall-mounted unit that is approximately
9x5 inches in size. The control panel has wireless connectively
to sensors and a PC. User interaction occurs through a keypad
containing 12 keys. A 2 x 2 inch LCD display provides user
feedback..
Eliciting Requirements
• Each sub team then presents its mini-specs to all attendees
for discussion. Additions , deletions, and further elaboration
are made.
• In some cases, the development of mini-specs will uncover
new objects, services, constraints, or performance
requirements that will be added to the original lists.
• During all discussions, the team may raise an issue that
cannot be resolved during the meeting.
• An issues list is maintained so that these ideas will be acted
on later.
• After the mini-specs are completed, each attendee makes a
list of validation criteria for the product/system and presents
the list to the team.
Eliciting Requirements
• A consensus list of validation criteria is then created.
• Finally, one or more participants (or outsiders) is assigned
the task of writing a complete draft specification using all
inputs from the meeting.
2. Quality Function Deployment
• Quality Function deployment (QFD) is a 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.
Eliciting Requirements
• QFD identifies three types of requirements
• Normal requirements: These requirements reflect objectives
and goals 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.
Eliciting Requirements
• 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 requirements reflect features
that go beyond the customer's expectations and prove to be
very satisfying when present.
• For example , word processing software is requested with
standard features. The delivered product contains a number
of page layout capabilities that are quite pleasing and
unexpected.
Eliciting Requirements
• In meetings with the customer ,
• Function deployment is used to determine the value of each
function that is required for the system.
• Information deployment identifies both the data objects and
events that the system must consume and produce. These are
tied to the functions.
• Task deployment examines the behavior of the system or
product within the context of its environment.
• Value analysis is conducted to determine the relative priority
of requirements determined during each of the three
deployments.
• exciting requirements |BOS91].
Eliciting Requirements
• QFD uses customer interviews and observation, surveys, and
examination of historical data (e.g., problem reports) 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.
• A variety of diagrams, matrices, and evaluation methods are
then used to extract expected requirements and to attempt.to
derive exciting requirements
Eliciting Requirements
3.User Scenarios
• As requirements are gathered, an overall vision of system
functions and features begins to materialize.
• It is difficult to move into more technical software engineering
activities until the software team understands 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.
Eliciting Requirements
4.Elicitation Work Products:
• The work products produced as a consequence of
requirements elicitation 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.
Eliciting Requirements
• 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.
Each of these work products is reviewed by all people who
have participated in requirements elicitation.
