1

Requirements
Engineering
-MS. SWATI VARMA
 2
Requirements Engineering

 Requirement engineering provides appropriate mechanisms for

understanding what the customer wants, analyzing needs, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the
requirements.
 It encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management
 Requirements Engineering

 Inception—ask a set of context free 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

3
 4
Requirements Engineering

Elicitation—elicit requirements from all stakeholders

 What is to be accomplished?
 How the product fits into the business?
 How the system will be used on a day-to-day basis?
Why req. elicitation is difficult?
 Problems of scope: boundary of the system is ill-defined or users specify
unnecessary technical detail that may confuse
 Problems of understanding- user not sure what he wants, have trouble
communicating, omit info. that is believed to be obvious, conflicting req,
ambiguous req
 Problems of volatility- req. change over time
 5
Requirements Engineering

Elaboration—
 The information obtained from the customer during inception and
elicitation is expanded and refined during elaboration.
 Elaboration consists of no. of modeling & refinement tasks.
 Create an analysis model that identifies data, function and behavioral
requirements
 The end result is analysis model that defines the informational, functional &
behavioral domain of the prob
 6
Requirements Engineering

 Negotiation—agree on a deliverable system that is realistic for developers

and customers
 Conflicting req will be there
 Reconcile these conflicts
 Customer, users & other stakeholders are asked to rank requirements &
then discuss conflicts in priority
 Iterate
 Req. are eliminated, combined, modified
 Requirements Engineering

 Specification—can be any one (or more) of the following:

 A written document
 A set of graphical models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 SRS is written

7
 8
Requirements Engineering

 Validation—
 The work products produced as a consequence of req engg are assessed for
quality
 a review mechanism that looks for
 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-
 Identify, control & track req & changes to req
 9
Inception

 Initiating the requirements engineering process

Steps:
1. Identifying the stakeholders
 Sommerville and Sawyer define a stakeholder as “anyone who benefits in a
direct or indirect way from the system which is being developed”
 Every stakeholder has a different view of the system.
 At inception, requirement engineer should create list of people who will
contribute
 E.g of stakeholders:- business operations managers, product managers,
marketing people, customers, end users, consultants, product engineers,
software engineers, support and maintenance engineers,
 10
Inception

2. Recognizing multiple viewpoints

 Because many different stakeholders exist, the requirements of the system
will be explored from many different points of view.
 The marketing group is interested in functions and features that will excite the
potential market, making the new system easy to sell.
 Business managers are interested in a feature set that can be built within budget
and that will be ready to meet defined market windows.
 End users may want features that are familiar to them and that are easy to learn
and use.
 As information from multiple viewpoints is collected emerging req. may be
inconsistent or may conflict with one another
 11
Inception

3. Working toward collaboration

 Customers should collaborate among themselves & with s/w engineering
practitioners
 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
 Inception

4. Asking the first questions

 The first set of “Context-free” questions focusses on the customer &
other stakeholders, over all goals & 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 questions will help in identifying the stakeholders

12
 13
Inception

 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:
 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?
 14
Inception

 The final set of questions focuses on the effectiveness of the

communication activity itself. Called as “meta-questions”
 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

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
 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
15
 Quality Function Deployment

 QFD is a technique that translates the needs of the customer into

technical requirements
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
 Expected requirements. These requirements are implicit to the
product or system and may be so fundamental that the customer
does not explicitly state them.
 Examples of expected requirements are: ease of human/machine
interaction, overall operational correctness and reliability
 Exciting requirements. These features go beyond the customer’s
expectations and prove to be very satisfying when present.
16
 17
User Scenarios

 The scenarios, often called use-cases, provide a description of how the

system will be used.
 Elicitation Work Products

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

18
 Elaboration

Building the Analysis Model

 Elements of the analysis model
 Scenario-based elements
 Functional—processing narratives for software functions
 Use-case—descriptions of the interaction between an “actor” and the system

 Class-based elements
 Implied by scenarios

 Behavioral elements
 State diagram

 Flow-oriented elements
 Data flow diagram

19
 Negotiating Requirements

 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”

20
 Validating Requirements

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

21
 Validating 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?

22