8iktucv7biyu

1. CHAPTER 4
REQUIREMENTS SPECIFICATION
Lalise D.SWEG 2021 1

2. • Requirements document is a formal document used to
communicate the requirements to customers, system and
software engineers and managers of the systems
engineering process.
• There is no standard name for this document.
• In different organizations, this document may have
different names such as the requirements document, the
functional specification, the system requirements
specification, etc.
Lalise D.SWEG 2021 2

3. • The requirements document describes:
– The services and functions which the system should provide.
– The constraints under which the system must operate.
– Overall properties of the system i.e.. constraints on the system’s
emergent properties.
– Definitions of other systems which the system must integrate with.
– Information about the application domain of the system e.g. how
to carry out particular types of computation.
– Constraints on the processes used to develop the system.
Lalise D.SWEG 2021 3

4. A requirement document includes:
• The purpose of the software being developed
• An overall description of the software
• The functionality of the software or what it is supposed
to do
• Performance of the software in a production situation
• Non-functional requirements
• External interfaces or how the software will interact
with hardware or other software it must connect to
• Design constraints or the limitations of the
environment that the software will run in
Lalise D.SWEG 2021 4

5. Different system stakeholders from different backgrounds will read the requirements
document and use it in different ways.
System
customers
Specify the requirements and
read them to check that they
meet their needs. They specify
changes to the requirements.
Project
Managers
Use the requirements
document to plan a bid for the
system and to plan the system
development process.
System engineers
Use the requirements to
understand the system being
developed.
System test
engineers
Use the requirements to
develop validation tests for the
system.
System
maintenance
engineers
Use the requirements to help
understand the system and the
relationships between its parts.
Lalise D.SWEG 2021
5

6. Requirements document structure(1)
• A number of different large organizations such as US Department
Defence and The IEEE (Institute of Electrical and Electronics
Engineers) have standards for requirements documents.
• IEEE/ANSI 830-1993 standard proposes a structure for software
requirements documents.
1.Introduction:
– 1.1 Purpose of requirements document.
– 1.2 Scope of the product.
– 1.3 Definitions and abbreviations.
– 1.4 References.
– 1.5 Overview of the remainder of the document.
Lalise D.SWEG 2021 6

7. Requirements document structure(2)
2. General description:
– 2.1 Product perspective.
– 2.2 Product functions.
– 2.3 User characteristics.
– 2.4 General constraints.
– 2.5 Assumptions and dependencies.
3.Specific requirements: Covering functional, non-functional and
interface requirements. These should document external interfaces,
functionality, performance requirements, logical database requirements,
design constraints, system attributes and quality characteristics.
Lalise D.SWEG 2021 7

8. 4. Appendices:
The appendixes are not always considered as a part of the actual SRS and are
not always necessary. They may
include
– Hardware interface specification.
– Software components which must be reused in the system implementation.
– Data structure specification.
– Data-flow models of the software system.
– Detailed object models of the software system.
When appendixes are included, the SRS should explicitly state whether or not
the appendixes are to be considered as a part of the requirements.
5. Index: Several indexes to the document may be included. Eg. normal
alphabetic index, there may be an index of diagrams, an index of functions,
and so on.
Requirements document structure (3)
Lalise D.SWEG 2021 8

9. Adapting the standard
• The IEEE standard is a generic standard which is
intended apply to a wide range of requirements
documents.
• In general, not all parts of the standard are required for all
requirements documents.
• Each organization should adapt the standard depending on
the type of systems it develops.
Lalise D.SWEG 2021 9

10. Writing requirements
• Requirements are usually written as paragraphs of natural
language text(English, French, Japanese, etc.), supplemented by
diagrams and equations.
Common Problems with requirements:
1.The requirements are written using complex conditional clauses(if
A then if B then If C…) which are confusing.
2.Terminology is used in a disordered and inconsistent way.
3.The writers of the requirement assume that the reader has specific
knowledge of the domain or the system and they leave essential
information out of the requirement.
• These problems make it difficult to check the set of requirements
for errors and omissions.
Lalise D.SWEG 2021 10

11. Three essential things you should bear in mind when
writing requirements
1.Requirements are read more often than they are written. You should
invest time to write readable and understandable requirements.
2.Do not assume that all readers of the requirements have the same
background and use the same terminology as you.
3.Allow time for review, revision and re-drafting of the requirements
document.
Lalise D.SWEG 2021 11

12. Writing guidelines
• Define standard templates for describing requirements:
– You should define a set of standard format for different types of
requirements and always express requirements using that format.
– This makes is less likely that important information will be missed
out and makes it easier for the reader to understand the different
parts of the requirement.
• Use language simply, consistently and briefly:
– Don’t write requirements using complex language but follow good
writing practice such as using short sentences and paragraphs,
using lists and tables and avoiding jargon whenever possible.
Lalise D.SWEG 2021 12

13. • Use diagrams appropriately:
– You should not develop complex diagrams but should use
diagrams to present broad overviews and to show
relationships between entities.
• Supplement natural language with other description of
requirements:
– Don’t try to write everything in natural language. If readers
of the requirements document are likely to be familiar with
other types of notation (e.g. equations), you should not
hesitate to use these.
• Specify requirements quantitatively.
– Whenever possible, you should specify your requirements
quantitatively, this is often possible when you are specifying
the properties of a system such as reliability, usability or
performance.
Lalise D.SWEG 2021 13