Requirements Engineering-I

 Inception—ask a set of 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

 Elicitation—elicit requirements from all stakeholders
 Elaboration—create an analysis model that identifies data, function
and behavioral requirements
 Negotiation—agree on a deliverable system that is realistic for
developers and customers
1
 Requirements Engineering-II

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

 A written document

 A set of models

 A formal mathematical

 A collection of user scenarios (use-cases)

 A prototype

 Validation—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

2
 Requirements Engineering-III

 Requirements management
 Set of activities that help the project team identify, control, and
track requirements and changes to requirements at any time as
the project proceed.
 Begins with identification
 Unique Identifier
 Traceability tables
1. Features traceability table
2. Source traceability table
3. Dependency traceability table
4. Subsystem traceability table
5. Interface traceability table

3
 Inception
 Identify stakeholders
 “who else do you think I should talk to?”

 Recognize multiple points of view

 Work toward collaboration
 The first questions
 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?

4
 Inception
 Next set of Questions
 How would you characterize “good” output that would be generated by
successful solution?
 What problems will this solution address?
 Can you show me 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
 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?

5
Elicitation
 The following techniques are used to elicit
requirements.
1. Personal Interviews
2. Questionnaires
3. Customer/market surveys
4. Observation
5. Demonstration of product prototypes or the
product itself
6. Brainstorming
6
Personal Interview
 The following steps would aid in the collection of
right information using personal interviews
1. Planning of personal interviews
2. Study the preliminary information and relevant
subject literature to understand the domain at hand
3. Prepare a set of questions to ask to aid in the
structured elicitation of information
4. Prepare formats and templates to capture
information efficiently
7
Personal Interview
5. Fix appointments with the identified executives
6. Conduct the interview effectively
7. Capture information

8
Questionnaires
 Most of the product development scenarios are based
on an existing product.
 Therefore, the questionnaires enumerate all the
existing features of the product as well as new ones
and the respondent is requested to:

9
Questionnaires
1. Set the order of importance of the features

2. The features that are most essential

3. The features that are not essential

4. The features that may motivate the respondent to either buy or

switch to the new product

5. Any other additional features the respondent would like to see in

the new product.

10
Customer/market surveys
• Normally surveys are conducted in three ways:
1. Face-to-Face
2. Postal Method
3. Web based Surveys

11
Obsevations
• In some cases, the analyst simply observes the
operations e.g.

1. the point of sales in a super market/mall

2. a busy bank teller

3. a guest registration counter in a busy hospital/hotel

4. an online registration/reservation system

12
 Eliciting Requirements
 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

13
 Eliciting Requirements

Co n d uc t FAST
m e e t in g s

Ma k e lis t s of
fu nc t io n s , c la s s e s

Ma k e lis t s o f
c on s t ra in t s , e t c .

fo rm a l p riorit iz a t ion ?
Elic it re q u ire m e n t s
ye s no

Us e QFD t o info rm a lly d e fin e a c t o rs

p rio rit iz e prio rit iz e
re q u ire m e n t s re q u ire m e n t s

d ra w u s e -c a s e
writ e s c e n a rio
d ia g ra m

Cre a t e Us e -c a s e s
c o m p le t e t e m p la t e

14
 Quality Function Deployment

 QFD identifies three types of requirements

 Normal requirement
 Expected requirements
 Exciting requirements
 Function deployment determines the “value” (as perceived by the
customer) of each function required of the system
 Information deployment identifies data objects and events
 Task deployment examines the behavior of the system
 Value analysis determines the relative priority of requirements
 Use Scenarios

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

16
 Use-Cases
 A collection of user scenarios that describe the thread of usage of a system
 Each scenario is described from the point-of-view of an “actor”—a person
or device that interacts with the software in some way
 Each scenario answers the following questions:
 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 extensions 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?

17
 Use-Case Diagram
Arms / dis a rms
s ys t e m

Ac c e s s e s s ys t e m s e ns or s
via Int e r ne t

home ow ne r

Re s ponds t o
a la rm e ve nt

Enc ount e rs a n
e rror c ondit ion

s ys t e m Re c onfigure s s e ns ors
a dminis t ra t or a nd re la t e d
s ys t e m fe a t ure s

18
 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-I

 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-II
 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
 Why prioritize requirements?

 Limited resources Customer

 Schedule expectations
 Budget are high
 Effort  Too many Reqs
Resources  Changing Reqs
Requirements
 Conflicting Reqs

All requirements are mandatory, but some are

essential/critical while others are not.
23
Prioritization

24
 Challenges of prioritization

 Different stakeholders have usually different opinions about requirement’s

importance and urgency.
 People naturally have their own interest and they aren’t always willing

to compromise their needs for someone else’s benefit.

 Customers may try to avoid prioritization, because
 they suspect that low priority requirements will never be implemented

 Developers may try to avoid prioritization, because

 they feel bad to admit, that they can’t implement all requirements

 Many of the prioritization methods are either too complicated and time
consuming or insufficient

25
 Prioritization techniques

 Prioritization scales
 Assign each requirement to a priority classification category

 Example categories: high, medium, low

 Prioritization model - cost-value approach

 Analytic Hierarchy Process (AHP)

 value, cost, and risk estimation model

 Kano method
 Other approaches
 Quality function deployment (QFD)


Total quality management (TQM)

26
Prioritizing requirements (MoSCoW)
 Must haves: top priority requirements

 Should haves: highly desirable

 Could haves: if time allows

 Won’t haves: not today

27
Prioritizing requirements (Kano model)
 Attractive: more satisfied if +, not less satisfied if –
 Must-be: dissatisfied when -, at most neutral
 One-dimensional: satisfaction proportional to number
 Indifferent: don’t care
 Reverse: opposite of what analist thought
 Questionable: preferences not clear

28
 Kano diagram satisfied

one-dimensional
attractive

dysfunctional functional
must-be

dissatisfied
29