Page 335 - Software and Systems Requirements Engineering in Practice

297
n
d
e
p
p
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
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 297
:
i
x
• It should be possible to baseline and perform change control
on requirements.
• Performance should be reasonably good in a fully populated
database (that is, one with several thousand requirements).
• The database should be easy to use; i.e., intuitive with minimal
need to refer to documentation.
• Bidirectional dumps should be possible to and from another
format such as Access and/or Excel (csv).
• It should be possible to work offline; one should be able to
take requirements home, review them, change them, and roll
them back into the database later.
• It should be possible to generate requirements documents
automatically from the database (e.g., Functional Requirements
Specification, System Requirements Specification).
• Rich text and graphics should be supported in a requirement
description.
• Product line support should be available (e.g., create subsets
of requirements that can be reused for different projects and
products).
• It should be possible to create rich traces, that is, to attach a
rationale to a trace and to define traces hierarchically.
• Global support should be available. The ability to have
distributed requirements analysis is more than just the ability
to have people at different locations entering requirements. It
implies the ability to fold in rules to determine routing, review
procedures (e.g., workflow), and scripting for user guidance
and quality assurance.

A.3 RDB Advanced Features

Requirements databases can be augmented with business rules to
assist in managing problems of scale. Some example advanced
features are described under the headings that follow.

Automatic Upward Propagation of Attributes
Product features are fully described by successively lower levels of
requirements, tending from the abstract down to the concrete. At the
leaf level, every requirement is testable. We can then define a business
rule, for example, that a product feature is testable only if it has
level 6 requirements (see Table A.2) for each of those requirements or
all its children that have been reviewed and found testable. In other
words, the trace mechanisms form a tree structure, starting with the
product requirement at the root. The tree is fully traversed in a
downward direction, and where the leaves are testable, that attribute