Page 331 - Software and Systems Requirements Engineering in Practice

293
C o n f i g u r i n g a n d M a n a g i n g a n R D B
:
x
p
p
e
i
A A p p e n d i x : C o n f i g u r i n g a n d M a n a g i n g a n R D B 293
n
d
• Intrinsic support for tracing, that is, a “drag and drop”
mechanism that is easy to use and supports creating traces
manually between requirements
• Generation of requirements specifications and reports directly
from the repository. The preferred method of working is to
create and edit requirements in the database, and then to use
the documentation facility of the database to create a filtered
and formatted set of requirements in a requirements
specification, usually as either a Word or PDF document.
Commercial requirements databases vary in terms of features,
but all of them have certain core features in order to comply with
corporate mandates (such as achieving a CMMI level) as well as
various sets of regulations. For example, one common attribute of
requirements databases is version control at the requirement level, so
that changes to requirements can be audited.

Prerequisites for the Use of a Requirements Database
A requirements database is a tool to support the requirements
management process. As such, requirements processes should be
defined prior to the selection and installation of the RDB, keeping in
mind issues of productivity, scalability, and usability. For example,
not defining requirements levels when creating traces can result in a
large, unusable report when generating a trace matrix. Some of the
prerequisites for effective use of an RDB are described next.
Glossary of Terms
There needs to be a uniform approach to the definition of terms in
order for specifications to be understood across organizations and
projects. In addition, where consultants are used or implementation
is outsourced, the ramp-up time is much lower if everyone
understands the same term to mean the same thing. Furthermore, when
outsourcing development, a standardized glossary can significantly
reduce ambiguity. A glossary has other advantages in that it can enable
the structuring of a requirements hierarchy (see the next heading).
Multiple glossaries with a defined precedence are used where the same
RDB is used for multiple organizations or projects. An example hierarchy
is given in Table A.1.
If an RDB is shared across projects or organizations, it is important
that there be no name collisions. The use of specific project or product
logins can help to prevent that from happening by keeping project or
product glossaries in separate name spaces.
Hierarchical Requirements Structure A hierarchical requirements
structure is necessary for effective use of trace and query mechanisms.
With requirements decomposition resulting in an expansion of a
single product feature into hundreds (or thousands) of requirements,