REQUIREMENTS ENGINEERING
JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS
CHAPTER FOUR
REQUIREMENTS SPECIFICATION & DOCUMENTATION
Topics we will cover
Requirements Specification
Requirements Document
Methods for Software requirements Specification
Free documentation in unrestricted natural language
Disciplined documentation in structured natural language
Requirements Specifications
3
A software requirements specification is a collection of the set of all
requirements that are to be imposed on the design and verification of the
product/software.
Requirements specification: It's the activity of writing down the
requirements gathered during the elicitation and analysis activity into a
document that defines a set of requirements.
Input for requirement specification are outputs of requirement analysis &
negotiation
Output of requirement specification is a complete description of a system
to be developed: : Requirements Document
What do you think are the activities for
requirements4specification?
Discussion
Requirements Specifications
During software requirements specification :
Define your product's purpose and scope.
Describe what you're building.
Details the requirements.
Supporting information.
Results a requirements document
Requirements Document
Requirements document is a reference document.
Once the a requirement document is approved by the customer,
any subsequent controversies are settled by referring the document.
Purpose of SRS:
Interface (communication) between the Customer, requirement
engineers Analyst, designers, system developers, testers and
maintainers.
Agreement between Purchaser and Supplier
Support verification and validation of requirements.
Support system testing activities
Support project management activities
Controlling the evolution of overall system
Characteristics of a Software
Requirements Specification
7
Document
Discussion
What do you mean by good requirements, and what are
characteristics of a good software requirements specification
document?
Characteristics of a Software
Requirements Specification Document
A good SRS is:
Unambiguous,
Complete,
Verifiable,
Consistent,
Modifiable, and
Traceable
Unambiguous
Every requirement has only one interpretation.
Each characteristics of the final product is described using a
single unique term.
A glossary should be used when a term used in a particular
context could have multiple meanings.
Complete
A complete SRS must possess the following qualities:
Inclusion of all significant requirements,
Definitions of the responses of the software to all realizable
classes of input,
Conformity to any standard that applies to it.
Full labeling and referencing of all tables and diagrams and
definitions of all terms.
Verifiable
Every requirement must be verifiable.
There must exist some finite cost- effective process with
which a person or machine can check that the software
meets the requirement.
Consistent
No set of individual requirements described in the SRS can be in
conflict.
Types of likely conflicts:
Two or more requirements describe the same real world
object in different terms.
The specified characteristics of real world objects might
conflict.
There may be a logical or temporal conflict between two
specified actions.
Modifiable
The structure and style of the SRS are such that any necessary
changes to the requirements can be made easily, completely and
consistently.
Requirements:
A coherent and easy-to-use organization(including a table of
contents, index and cross-referencing),
Not be redundant-this can lead to errors.
Traceable
The origin of each requirement must be clear.
The SRS should facilitate the referencing of each requirement in future
development or enhancement documentation.
Types:
1. Backward traceability: each requirement must explicitly reference
its source in previous documents.
2. Forward traceability: each requirement must have an unique name
or reference number.
Problems without a SRS document
The important problems that an organization would face if it does not
develop a SRS document are as follows:
Without developing the SRS document, the system would not be implemented
according to customer needs.
Software developers would not know whether what they are developing is what
exactly required by the customer.
Without SRS document, it will be very much difficult for the maintenance
engineers to understand the functionality of the system.
It will be very much difficult for user document writers to write the users’
manuals properly without understanding the SRS document.
Methods for Software requirements
Specification
16
The formality and format of a specification varies with the size and
the complexity of the software to be built.
For large systems, disciplined documentation in structured natural
language may be the best methods.
For small systems or product, free documentation in unrestricted
natural language
Free documentation
in unrestricted natural language
Unconstrained prose writing in natural language.
Unlimited expressiveness, communicability, no training needed
Prone to many of the spec errors & flaws
Cons: Frequent confusions among logical connectives in natural
language and order of the contents.
Example: case analysis:
if Case1:then <Statement1>
AND
if Case2: then <Statement2>
Use Disciplined documentation in
structured in natural languages
Use standardized statement templates.
Title of standard:
“IEEE Recommended Practice for Software
Requirements Specification”
Describes the content and qualities of a good SRS
Presents several sample SRS outlines
IEEE 830-1998 Standard – Structure of the
SRS
IEEE 830-1998 Standard – Structure of the SRS
IEEE 830-1998 Standard – Structure of
the SRS
IEEE 830-1998 Standard – Structure of the
SRS
Key Points
Requirements Specification
Requirements Document
Methods for Software requirements Specification
Any Question?