Requirements Analysis

Lecture # 12

1
 Recap of Requirements
Elicitation - 1
• Requirements elicitation deals with
discovering requirements for a software
product
• It is an iterative process and consists of
many activities including establishing
objectives, understanding background,
organizing knowledge, and collecting
requirements
2
 Recap of Requirements
Elicitation - 2
• Introduced the concept of elicitation and
requirements elicitation process
• Basics of knowledge acquisition (reading,
listening, asking, & observing)
• Knowledge acquisition techniques
(individual, group, modeling, cognitive)
• Elicitation problems (scope,
understandability, volatility)
3
 Recap of Requirements
Elicitation - 3
• Context (organization, environment,
project, constraints imposed by people)
• Guidelines for knowledge acquisition
• Discussed in detail some requirements
elicitation techniques, especially
interviews

4
 Requirements Engineering Process

Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.
5
 Requirements Analysis and
Negotiation
• We’ll discuss requirements analysis and
negotiation separately, in order to
understand them clearly and to appreciate
that different skills are needed to perform
them
• They are inter-leaved activities and join to
form a major activity of the requirements
engineering process
6
 Requirements Analysis - 1
• The aim of requirements analysis is to
discover problems with the system
requirements, especially incompleteness
and inconsistencies
• Some analysis is inter-leaved with
requirements elicitation as problems are
sometimes obvious as soon as a
requirement is expressed
7
 Requirements Analysis - 2
• Detailed analysis usually takes place
after the initial draft of the
requirements document is produced
• Analysis is concerned with incomplete
set of requirements, which has not been
discussed by stakeholders

8
Iterative Aspects of Elicitation,
Analysis, and Negotiation
Draft
Statement of
Requirements
Requirements
Elicitation

Requirements
Analysis

Requirements Requirements
Documents Problems

Requirements
Negotiation 9
 Comments on Requirements
Analysis - 1
• Analysts read the requirements,
highlight problems, and discuss them
in requirements review meetings
• This is a time-consuming and
expensive activity

10
 Comments on Requirements
Analysis - 2
• Analysts have to think about
implications of the draft statements of
requirements
• People do not think in the same way
and different analysts tackle the
process in different ways

11
 Comments on Requirements
Analysis - 3
• It is not possible to make this activity a
structured and systematic process
• It depends on the judgment and
experience of process participants

12
 Requirements Analysis Stages
• Necessity checking
• Consistency and completeness
checking
• Feasibility checking

13
 Necessity Checking
• The need for the requirement is
analyzed. In some cases, requirements
may be proposed which don’t
contribute to the business goals of the
organization or to the specific problem
to be addressed by the system

14
 Consistency and Completeness
Checking
• The requirements are cross-checked for
consistency and completeness.
Consistency means that no
requirements should be contradictory;
Completeness means that no services
or constraints which are needed have
been missed out
15
 Feasibility Checking
• The requirements are checked to
ensure that they are feasible in the
context of the budget and schedule
available for the system development

16
Requirements Analysis Process
Requirements Analysis

Necessity Consistency and Feasibility

checking completeness checking
checking

Conflicting and
Unnecessary Infeasible
incomplete
requirements requirements
requirements

17
 Analysis Techniques
• Analysis checklists
– A checklist is a list of questions which
analysts may use to assess each
requirement
• Interaction matrices
– Interaction matrices are used to discover
interactions between requirements and to
highlight conflicts and overlaps
18
 Analysis Checklists - 1
• Each requirement may be assessed against
the checklist
• When potential problems are discovered,
these should be noted carefully
• They can be implemented as a spreadsheet,
where the rows are labeled with the
requirements identifiers and columns are
the checklist items

19
 Analysis Checklists - 2
• The are useful as they provide a reminder of
what to look for and reduce the chances that
you will forget some requirements checks
• They must evolve with the experience of
the requirements analysis process
• The questions should be general, rather than
restrictive, which can be irrelevant for most
systems

20
 Analysis Checklists - 3
• Checklists should not include more
than ten items, because people forget
items on long checklists reading
through a document
• Example of analysis checklist

21
 Checklist Items - 1
• Premature design

• Combined requirements

• Unnecessary requirements

• Use of non-standard hardware

22
 Checklist Items Description - 1
• Premature design
– Does the requirement include premature
design or implementation information?
• Combined requirements
– Does the description of a requirement
describe a single requirement or could it
be broken down into several different
requirements?
23
 Checklist Items Description - 2
• Unnecessary requirements
– Is the requirement ‘gold plating’? That is, is the
requirement a cosmetic addition to the system
which is not really necessary
• Use of non-standard hardware
– Does the requirement mean that non-standard
hardware or software must be used? To make
this decision, you need to know the computer
platform requirements
24
 Checklist Items - 2
• Conformance with business goals

• Requirements ambiguity

• Requirements realism

• Requirements testability
25
 Checklist Items Description - 3
• Conformance with business goals
– Is the requirement consistent with the
business goals defined in the introduction to
the requirements document?
• Requirements ambiguity
– Is the requirement ambiguous i.e., could it
be read in different ways by different
people? What are the possible
interpretations of the requirement?

26
 Checklist Items Description - 4
• Requirements realism
– Is the requirement realistic given the
technology which will be used to implement
the system?
• Requirements testability
– Is the requirement testable, that is, is it
stated in such a way that test engineers can
derive a test which can show if the system
meets that requirement?

27
 Summary
• Discussed requirements analysis, which is
an iterative activity and checks for
incomplete and inconsistent requirements
• Studied analysis checklists, and will
continue our discussion of requirements
analysis in the next lecture
• We’ll talk about requirements negotiation
also in the next lecture

28
 References
• ‘Requirements Engineering: Processes
and Techniques’ by G. Kotonya and I.
Sommerville, John Wiley & Sons,
1998

29