Chapter Comments 7-1

Chapter 7
Requirements Engineering
CHAPTER OVERVIEW AND COMMENTS
The intent of this chapter is to present requirements engineering tasks and basic
requirements analysis concepts and principles.
Regardless of the process model used by software engineers, requirements
engineering is an essential part of a successful software development project.
The focus of this chapter is gathering the information needed to build the
information, function, and behavioral portions of the analysis model.
Understanding the requirements of a problem is among the most difficult tasks
that face a software engineer.
7.1 The Bridge to Design and Construction
In this section, requirements engineering is described as a bridge between
communication and analysis modeling, design and construction.
or all new systems, the requirements engineering process should start with a
feasibility study.
The input to the feasibility study is a set of preliminary business requirements, an
outline description of the system and how the system is intended to support
business processes.
The results of the study should be a report that recommends whether or not it is
worth carrying on with the requirements engineering and system development
process.
!any software engineering developers want to jump right in before they have a
clear understanding of what is needed.
" feasibility study is a short, focused study that aims to answer a number of
questions#
$. %oes the system contribute to the overall objectives of the organi&ation'
7-2 SEPA, 6/e Instructors Guide
(. )an the system be implemented using current technology and within given
cost and schedule constraints'
*. )an the system be integrated with other systems which are already in
place'
+The hardest single part of a software engineering system is deciding what to
build. No part of the work so cripples resulting system if done wrong. Not other
part is more difficult to rectify later, red -rooks.
Requirement .ngineering is a software engineering action that begins during
communication activity and continues into the modeling activity.
It is essential that the software engineering team attempts to make a real effort to
understand the requirements of a problem before the team attempt to solve the
problem.
R. establishes a solid base for design and construction. /ithout it, the resulting
software has a high probability of not meeting customers0 needs.
7.2 Requirements Engineering Tasks
R. provides the appropriate mechanism for understanding what the customer
wants, analy&ing 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.
7.2.1 Inception
1ow does a software engineering project get started' Is there a single event that
becomes the catalyst for a new computer2based system or product, or does the
need evolve over time'
There are no definitive answers to these questions.
"t project inception, software engineers ask a set of questions that establish 3
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
7.2.2 Elicitation
)hristel and 4ang identify a number of problems that help us understand why
requirements elicitation is difficult#
Probems o! scope. The boundary of the system is ill2defined.
Probems o! understandin". The customers5users are not completely
sure of what is needed, have poor understanding of the capabilities and
limitations of their computing environment, don0t have a full understanding
Chapter Comments 7-#
of the problem domain, specify requirements that conflict with the needs of
other customers5users, or specify requirements that are ambiguous or
unstable.
Probems o! $oatiit%. The requirements change over time.
7.2.3 Elaboration
Elaboration is an analysis modeling action that is composed of a number of
modeling and refinement tasks.
Elaboration is driven by the creation and refinement of user scenarios that
describe how the end2user will interact with the systems.
7.2.4 Negotiation
It is not unusual for customers and users to ask for more than can be achieved
given limited business resources.
The requirements engineer must reconcile these conflicts through a process of
negotiation.
)ustomers, users, and other stakeholders, are asked to rank requirements and
then discuss conflicts in priority.
Risks associated with each requirement are identified and analy&ed6 hence,
rough +guestimates, of development efforts are made.
7.2.5 Specifcation
" specification can be any one 7or more8 of the following#
" written document
" set of models
" formal mathematical
" collection of usage scenarios 7use2cases8
" prototype
The specification is the final work product produced by the requirements
engineer.
It serves as the foundation for subsequent software engineering activities.
It describes the function and performance of a computer2based system and the
constraints that will govern its development.
7.2.6 Validation
Requirements validation e9amines the specification to ensure that all software
requirements have been stated unambiguously6 that inconsistencies, omissions,
and errors have been detected and corrected6 and that the work products
7-& SEPA, 6/e Instructors Guide
conform to the standards established for the process, the project and the
product.
The primary requirements validation mechanism is the formal technical review.
The review team that validates requirements includes software engineers,
customers, users, and other stakeholders who e9amine the specification looking
for errors in content or interpretation, areas where clarification may be required,
missing information, inconsistencies, conflicting requirements, or unrealistic
requirements.
7.2.7 Requirements Management
Requirements Management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at any time
as the project proceeds.
Read book page $:; for more details.
7.3 Initiating the Requirements Engineering Process
The process of initiating engineering is the subject of this section. The point of
view described is having all stakeholders 7including customers and developers8
involved in the creation of the system requirements documents.
The following are steps required to initiate requirements engineering#
7.3.1 Identifying the Stakeholders
" stakeholder is anyone who benefits in a direct or indirect way from the system
which is being developed. <=ommerville and =awyer>
In the book stakeholders are# operations managers, product managers,
marketing people, internal and e9ternal customers, end2users, consultants,
product engineers, software engineers, support and maintenance engineers, etc.
"t inception, the requirements engineer should create a list of people who will
contribute input as requirements are elicited.
The initial list will grow as stakeholders are contacted because every stakeholder
will be asked,/ho else do you think I should talk to',
7.3.2 Recognizing Multiple Viewpoints
.ach of the stockholders will contribute to the R. process.
"s information from multiple viewpoints is collected, emerging requirements may
be inconsistent or may conflict with one another.
The requirements engineer is to categori&e all stakeholder information including
inconsistencies and conflicting requirements in a way that will allow decision
makers to choose an internally inconsistent set of requirements for the system.
Chapter Comments 7-'
7.3.3 Working toward Collaboration
)ollaboration 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, 7business manager, or a senior
technologist8 may make the final decision about which requirements make the
final cut.
7.3.3 Asking the First Questions
The first set of conte9t2free questions focuses on the customer and other
stakeholders, overall goals, and benefits.
The first questions#
/ho is behind the request for this work'
/ho will use the solution'
/hat will be the economic benefit of a successful solution'
Is there another source for the solution that you need'
The ne9t set of questions enables the software engineering team to gain a better
understanding of the problem and allows the customer to voice his5her voice#
1ow would you characteri&e +good, output that would be generated by a
successful solution'
/hat problems will this solution address'
)an you show me the business environment in which the solution will be
used'
/ill 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. ?ause and /einberg call these questions +meta questions,
"re you the right person to answer these questions' "re your answers
+official,'
"re my questions relevant to the problem that you have'
"m I asking too many questions'
)an anyone else provide additional information'
=hould I be asking you anything else'
+He who asks a question is a fool for 5 minutes, he who doesnt ask a question is
a fool fore!er., )hinese proverb
7-6 SEPA, 6/e Instructors Guide
7.4 Eliciting Requirements
The @A" session should be used for the first encounter only and then replaced
by a requirements elicitation format that combines elements of problem solving,
elaboration, and specification.
7.4.1 Collaborative Requirements Gathering
In this approach the stakeholders collaborate under the supervision of a neutral
facilitator to determine the problem scope and define an initial set of
requirements.
"ollaborati!e Requirements #athering all apply some variation on the following
guidelines#
meetings are conducted and attended by both software engineers and
customers
rules for preparation and participation are established
an agenda is suggested
a BfacilitatorB 7can be a customer, a developer, or an outsider8 controls the
meeting
a Bdefinition mechanismB 7can be work sheets, flip charts, or wall stickers
or an electronic bulletin board, chat room or virtual forum8 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
Read the scenario presented in the book page $C*.
7.4.2 Quality Function Deployment (QFD)
In this technique the customer is asked to prioriti&e the requirements based on
their relative value to the users of the proposed system.
@% is a technique that translates the needs of the customer into technical
requirements for software engineering. @% identifies three types of
requirements#
(orma re)uirements# These requirements reflect objectives and goals stated
for a product or system during meetings with the customer.
E*pected re)uirements# These requirements are implicit to the product or
system and may be so fundamental that the customer does not e9plicitly state
them.
Chapter Comments 7-7
E*citin" re)uirements# These requirements reflect features that go beyond the
customer0s e9pectations and prove to be very satisfying when present.
In meeting with the customer, function deployment is used to determine the value
of each function that is required for the system. $nformation deployment
identifies both the data objects and events that the systems must consume and
produce.
inally, task deployment e9amines the behavior of the system within the conte9t
of its environment. "nd !alue analysis determines the relative priority of
requirements determined during each of the three deployments.
7.4.3 User Scenarios
"s requirements are gathered an overall version of system functions and
features begins to materiali&e
%evelopers and users create a set of scenarios that identify a thread of usage for
the system to be constructed in order for the software engineering team to
understand how functions and features are to be used by end2users.
7.4.3 Elicitation Work Products
or most systems, the work product includes#
" statement of need and feasibility.
" bounded statement of scope for the system or product.
" list of customers, users, and other stakeholders who participated in
requirements elicitation.
" description of the system0s technical environment.
" list of requirements 7preferably organi&ed by function8 and the domain
constraints that apply to each.
" set of usage scenarios that provide insight into the use of the system or
product under different operating conditions.
"ny prototypes developed to better define requirements.
7.5 Developing Use-Cases
Use2cases are defined from an actor0s point of view. "n actor is a role that users
or devices play as they interact with the software engineer.
The first case in writing a use2case 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 conte9t of the functions and behavior that is to be described.
"n actor is anything that communicates with the system or product and that is
e9ternal to the system itself.
-ecause requirements elicitation is an evolutionary activity, not all actors are
identified during the $
st
iteration.
7-+ SEPA, 6/e Instructors Guide
Primar% actors interact to achieve required system functions and derive the
intended benefit from the system.
Secondar% actors support the system so that primary action can do their work.
Dnce actors have been identified, use2cases can be developed.
" number of questions that should be answered by a use2case#
/ho is the primary actor, the secondary actor 7s8'
/hat are the actor0s goals'
/hat preconditions should e9ist before the story begins'
/hat main tasks or functions are performed by the actor'
/hat e9tensions might be considered as the story is described'
/hat variations in the actor0s interaction are possible'
/hat system information will the actor acquire, produce, or change'
/ill the actor have to inform the system about changes in the e9ternal
environment'
/hat information does the actor desire from the system'
%oes the actor wish to be informed about une9pected changes'
7.6 Building the Analysis Model
This section discusses analysis modeling. The elements of the analysis model
7scenario2based, class2based, behavioral, and flow2oriented8 are introduced.
The intent of the analysis model is to provide a description of the required
informational, functional, and behavioral domains for a computer2based system.
The model changes dramatically as software engineers learn more about the
system, and the stakeholders understand more about what they really require.
7.6.1 Elements of the Analysis Model
The specific elements of the analysis model are dictated by the analysis
modeling method that is to be used. 1owever, a set of generic elements is
common to most analysis models.
Scenario-based eements# The system is described from the user0s point of
view using a scenario2based approach.
It always a good idea to get stakeholders involved. Dne of the best ways to do
this is to have each stakeholder write use2cases that describe how the software
engineering models will be used.
unctionalEprocessing narratives for software functions
Use2case2 descriptions of the interaction between an +actor, and the system.
Chapter Comments 7-,
Cass-based eements# .ach usage scenario implies a set of +objects, that are
manipulated as an actor interacts with the system.
These objects are categori&ed into classes2 a collection of things that have
similar attributes and common behaviors.
Dne way to isolate classes is to look for descriptive nouns in a use2case script.
"t least some of the nouns will be candidate classes.
-eha$iora eements# 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.
" state is any observable mode of behavior. !oreover, the state diagram
indicates what actions are taken as a consequence of a particular event.
.o/-oriented eements# Information is transformed as it flows through a
computer2based system.
The system accepts input in a variety of forms6 applies functions to transform it6
and produces output in a variety of forms.
7.7 Negotiating Requirements
The customer and the developer enter into a process of negotiation, where the
customer may be asked to balance functionality, performance, and other product
or system characteristics against cost and time to market.
The intent of the negotiations is to develop a project plan that meets the needs of
the customer while at the same time reflecting the real2world constraints 7time,
people, and budget8 that have been imposed on the software engineering team.
-oehm defines a set of negotiation activities at the beginning of each software
process iteration. The following activities are defined#
Identify the key stakeholders. These are the people who will be involved
in the negotiation.
%etermine each of the stakeholders +win conditions,. /in conditions are
not always obvious.
Fegotiate6 work toward a set of requirements that lead to +win2win,
7.8 Validating Requirements
The purpose of requirements validation is to make sure that the customer and
developer agree on details of the software requirements 7or prototype8 before
beginning the major design work. This implies that both the customer and
developer need to be present during the validation process.
"s each element of the analysis model is created, it is e9amined for consistency,
omissions, and ambiguity.
7-10 SEPA, 6/e Instructors Guide
The requirements represented by the model are prioriti&ed by the customer and
grouped within requirements packages that will be implemented as software
increments and delivered to the customer.
" review of the analysis model addresses the following questions#
Is each requirement consistent with the overall objective for the
system5product'
1ave 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 add2on feature
that may not be essential to the objective of the system'
Is each requirement bounded and unambiguous'
%oes each requirement have attribution' That is, is a source 7generally, a
specific individual8 noted for each requirement'
%o 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'
%oes the requirements model properly reflect the information, function and
behavior of the system to be built'
1as the requirements model been +partitioned, in a way that e9poses
progressively more detailed information about the system.
1ave requirements patterns been used to simplify the requirements
model. 1ave all patterns been properly validated' "re 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 the customer0s needs and that it
provides foundation for design.