specification or SRS) is the official statement of what the system developers should
implement. It should include both the user requirements for a system and a detailed
specification of the system requirements. In some cases, the user and system
requirements may be integrated into a single description. In other cases, the user
requirements are defined in an introduction to the system requirements specification.
If there are a large number of requirements, the detailed system requirements
may be presented in a separate document.
The requirements document has a diverse set of users, ranging from the senior
management of the organisation that is paying for the system to the engineers responsible
for developing the software. Figure 6.16, taken from my book with Gerald
Kotonya on requirements engineering (Kotonya and Sommerville, 1998) illustrates
possible users of the document and how they use it.
The diversity of possible users means that the requirements document has to be
a compromise between communicating the requirements to customers, defining the
requirements in precise detail for developers and testers, and including information
about possible system evolution. Information on anticipated changes can help system
designers avoid restrictive design decisions and help system maintenance engineers
who have to adapt the system to new requirements.
The level of detail that you should include in a requirements document depends
on the type of system that is being developed and the development process used.
When the system will be developed by an external contractor, critical system specifications
need to be precise and very detailed. When there is more flexibility in
the requirements and where an in-house, iterative development process is used, the
requirements document can be much less detailed and any ambiguities resolved during
development of the system.
A number of large organisations, such as the US Department of Defense and the
IEEE, have defined standards for requirements documents. Davis (Davis, 1993) discusses
some of these standards and compares their contents. The most widely known
standard is IEEE/ANSI 830-1998 (IEEE, 1998). This IEEE standard suggests the
following structure for requiremems documents:
I. Introduction
1.1 Purpose of the requiremt:nts document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
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 cover functional, non··functional and interface requirements.
This is obviously the most substantial part of the document but because
of the wide variability in organisational practice, it is not appropriate to define
a standard structure for this section. The requirements may document external
interfaces, describe system functionality and performance, specify logical
database requirements, design constraints, emergent system properties and
quality characteristics.
4. Appendices
5. Index
Although the IEEE standard is not ideal, it contains a great deal of good advice
on how to write requirements and how to avoid problems. It is too general to be
an organisational standard in its own right. It is a general framework that can be
tailored and adapted to define a standard geared to the needs of a particular organisation.
Figure 6.17 illustrates a possible organisation for a requirements document
that is based on the IEEE standard. However, I have extended this to include information
about predicted system evolution. This was first proposed by Heninger
(Heninger, 1980) and, as I have discussed, helps the maintainers of the system and
may allow designers to include support for future system features.
Of course, the information that is included in a requirements document must depend
on the type of software being developed and the approach to development that is
used. If an evolutionary approach is adopted for a software product (say), the requirements
document will leave out many of detailed chapters suggested above. The focus
will be on defining the user requirements and high-level, non-functional system requirements.
In this case, the designers and programmers use their judgement to decide
how to meet the outline user requirements for the system.
By contrast, when the software is part of a large system engineering project that
includes interacting hardware and software systems, it is often essential to define
the requirements to a fine level of detail. This means that the requirements documents
are likely to be very long and should include most if not all of the chapters
shown in Figure 6.17. For long documents, it is particularly important to include a
comprehensive table of contents and document index so that readers can find the
information that they need.
Requirements documents are essential when an outside contractor is developing
the software system. However, agile development methods argue that requirements
change so rapidly that a requirements document is out of date as soon as it is written,
so the effort that is largely wasted. Rather than a formal document, approaches
such as extreme programming (Beck, 1999) propose that user requirements should
be collected incrementally and written on cards. The user then prioritises requirements
for implementation in the next increment of the system.
=======================================================
Preface
This should define the expec:ted readership of the document
and describe its version history, including a rationale for the
creation of a new version and a summary of the changes
made in each version.
------------------------------------------------------
Introduction
This should describe the neE~d for the system. It should briefly
describe its functions and explain how it will work with other
systems. It ~;hould describe how the system fits into the
overall busi ness or strategic ,objectives of the organisation
commission1ing the software.
------------------------------------------------------
Glossary
This should define the technical terms used in the document
You should not make assumptions about the experience or
expertise of the reader.
------------------------------------------------------
User requirements definition
The service!; provided for thE~ user and the non-functional
system requirements should be described in this section. This
description may use natural language, diagrams or other
notations that are understandable by customers. Product
and proces!; standards which must be followed should be
specified.
------------------------------------------------------
System architecture
This chapter should present a high-level overview of the
anticipated system architecture showing the distribution of
functions ac:ross system modules. Architectural components
that are reused should be highlighted.
------------------------------------------------------
System requirements specification
This should describe the funlctional and non-functional
requirements in more detail. If necessary, further detail
may also bl! added to the Mn-functional requirements,
e.g. interfaces to other systems may be defined.
------------------------------------------------------
SystE!m models
This should set out one or more system models showing
the relationships between the system components and the
system and its environment These might be object models,
data-flow models and semantic data models.
------------------------------------------------------
System evolution
This should describe the fundamental assumptions on which
the system is based and anticipated changes due to hardware
evolution, changing user needs, etc.
------------------------------------------------------
Appendices
These should provide detailed, specific information which
is related tCI the application which is being developed.
Examples o·f appendices that may be inclUded are hardware
and database descriptions. Hardware requirements define the
minimal and optimal configurations for the system. Database
requirements define the logical organisation of the data used
by the system and the relaticmships between data.
------------------------------------------------------
Index
several indElxes to the document may be included. As well
as a nonmal alphabetic indeJ~ there
=======================================================
For business systems where requirements are unstable, I think that this approach
is a good one. However, I would argue that it is still useful to write a short supporting
document that defines the business and dependability requirements for the
system. It is easy to forget the requirements that apply to the system as a whole
when focusing on the functional requirements for the next system release.
No comments:
Post a Comment
Your comments are welcome!