SOFTWARE REQUIREMENT

ANALYSIS

26th March, 2013 Engr. Ali

Requirement Statement
Characteristics
Complete - Each requirement must fully describe
the functionality to be delivered.
Correct - Each requirement must accurately
describe the functionality to be built. A user
requirement that conflict with a corresponding
system requirement isn’t correct.
Feasible - It must be possible to implement each
requirement within the known capabilities and
limitations of the system and its environment.
Necessary -Each requirement should document
something that the customer really need or
something that is required for conformance to an
external system requirement or standard.
Requirement Statement
Characteristics
Prioritized - Assign an implementation priority to
each requirement, feature or use case to indicate
how essential it is to a particular product release.
Unambiguous - All readers of a requirement
statement should arrive at a single, consistent
interpretation of it.
Verifiable - Examine each requirement to see
whether you can plan a small number of tests or
use other verification approaches, such as
inspection or demonstration, to determine whether
the requirement was properly implemented
Requirement Specification
Characteristics
A good Requirements specification
document(SRS) should possess the
following characteristics.
Complete - No requirement or necessary
information should be missing.
Consistent – No requirement should conflict
with other software
Continued

Modifiable - One must be able to revise the Software

Requirement Specification when necessary and maintain a
history of changes made to each requirement.
Traceable - One should be able to link each requirement to
its origin and to the design elements, source code, and test
cases that implement and verify the correct implementation
of the requirement.(Traceability in software engineering is
the ability to trace work items across the development
lifecycle. It's used to keep track of what's going on in the
development lifecycle — and show what's happened.
Achieving regulatory compliance is a common purpose for
traceability in software engineering.)
How to meet those characteristics??

Through Requirement Analysis

Need of Requirement Analysis and
Specification
Goal of Requirement Analysis and
Specification
Activities of Requirement Analysis and
Specification

SRS
Requirements Analysis Stages

1. Necessity checking

2. Consistency and completeness checking

3. Feasibility checking

11
1. Necessity Checking

The NEED for the requirement is analyzed.

What exactly the goals are?
The goals should be clearly analyzed according to the
necessities.

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

12
2. Consistency and Completeness Checking

The requirements are cross-checked for consistency and

completeness.

Consistency means that no requirements should be

contradictory; (no overlaps, no contradictions, no
duplications)

Completeness means that no services or constraints

which are needed have been missed out. 13
3. Feasibility Checking

The requirements are checked to ensure that they

are feasible in the context

Budget

Schedule

Available for the system development

14
Requirements Analysis Process

Requirements Analysis

Necessity Consistency and Feasibility

checking completeness checking
checking

Conflicting and
Unnecessary Infeasible
incomplete
requirements requirements
requirements

15
Analysis Techniques
1. Analysis checklists
A checklist is a list of questions which analysts may use to assess each requirement

2. Interaction matrices
Interaction matrices are used to discover interactions between requirements and to
highlight conflicts and overlaps

16
 Analysis Checklists
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
They are useful as they provide a reminder of what
to look for and reduce the chances that you will
forget some requirements checks 17
 Analysis Checklists
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
Checklists should not include more than ten
items, because people forget items on long
checklists reading through a document
Example of analysis checklist
18
1. Checklist Items

1. Premature design

2. Combined requirements

3. Unnecessary requirements

4. Use of non-standard hardware

19
Checklist Items Description

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?
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 20
software must be used? To make this decision, you need to know
the computer platform requirements
2. Checklist Items

1. Conformance with business goals

2. Requirements ambiguity

3. Requirements realism

4. Requirements testability

21
 Checklist Items Description

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?
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 22
way that test engineers can derive a test which can show
if the system meets that requirement?
 Requirements Interactions

A very important objective of requirements

analysis is to discover the interactions between
requirements and to highlight requirements
conflicts and overlaps.(how requirements interact
with each other). It is possible that all requirements
of one project may interact and there is possibility
of conflict or requirement overlapped).

A requirements interaction matrix shows how

requirements interact with each other, which can be
constructed using a spreadsheet
May be R2 is done and R3 is to be done
which is opposite then what to do?
Rule
Each requirement is compared with other requirements, and the matrix is filled as
follows:
For requirements which conflict, fill in a 1
For requirements which overlap, fill in a 1000
For requirements which are independent, fill in a 0
Example
 R1 and
R5 over
lapped

All s/w can be blue(R1) but data entry form

should be in red color only(over lapped b/c data
entry form is the part of whole s/w)
 R2 and R4
are
contradicting
Comments - Interaction Matrices

If you can’t decide whether requirements conflict, you

should assume that a conflict exists. If an error is made it
is usually fairly cheap to fix; it can be much more
expensive to resolve undetected conflicts
The advantage of using numeric values for conflicts and
overlaps is that you can sum each row and column to find
the number of conflicts and the number of overlaps
Requirements which have high values for one or both of
these figures should be carefully examined.
31
 Comments - Interaction Matrices

A large number of conflicts or overlaps means that any

changes to that requirement will probably have a major
impact of the rest of the requirements
“Interaction matrices work only when there is relatively
small number of requirements”, as each requirement is
compared with every other requirements.
The upper limit should be about 200 requirements
These overlaps and conflicts have to be discussed and
resolved during requirements negotiation.
32
 Reference
49

1.
s Managing Software Requirements: A Use Case Approach, Second Edition
By Dean Leffingwell, Don Widrig, Addison- Wesley
2. http://en.wikipedia.org/wiki/Functional_requirement ht
3. tp: //en.wikipedia.org/wiki/Non-functional_requirement
4. http://www.webopedia.com/TERM/O/open_source_tools.html
5.

6. http://www.sei.cmu.edu/reports/90cm019.pdf
7. http://finntrack.co.uk/learners/business_society.htm
8. http://en.wikipedia.org/wiki/Requirement
9. http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/Require
ments/DomainReq.html
http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-
bullet.pdf
10. http://en.wikipedia.org/wiki/Requirements_management

Engr. Ali Javed