support tools such as RequisitePro and Doors. Whatever approach is adopted, all
requirements need to be thoroughly and consistently documented, and this should
include, ultimately, an agreed resolution of every requirement deﬁned.
Using requirements docu
First, let us consider the typical content of the requirements specication,
which acts as an overall document for the full set of detailed requirements and
any supporting material. Its structure is shown in Table 6.4.
Table 6.4 Content of a
typical requirements speciﬁcation
Introduction and Business context This section is used to explain the
background Business objectives background to the analysis project,
Project context and documents any constraints or
Deﬁnition of scope assumptions on which it is based.
Drivers and constraints It is useful, too, to identify the
Assumptions stakeholders in the project and
Stakeholder list explain what their interests are.
Functional model Context diagram This illustrates what system
Use case diagram processes are likely to be required.
Use case descriptions Use cases are ideal for this, but
Requirements there are other similar techniques
traceability matrix that may be used.
Data model Class diagram An understanding of the data in a
Entity relationship system helps enormously in
diagram understanding the system itself.
Data dictionary We suggest using an object class
model for this, as it ﬁts with the
UML approach, which is becoming
very widespread, but a conventional
relational data model (for example,
an entity-relationship diagram)
would serve the same purpose.