Page 333 - Software and Systems Requirements Engineering in Practice

295
x
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
n
d
i
e
:
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 295
Metric RDB Implementation
% Ambiguity Ambiguity pass/fail attribute
% Modifiable Modifiable pass/fail attribute
% Complete Depends on level
% Traceable Depends on level
% Feasible Feasible pass/fail attribute
TABLE A.3 Example Metrics and Implementation

Note that since other database attributes such as the assignment
of a requirement to a release are known, completeness, correctness,
ambiguity, etc., for a specific specification or release can be computed
once the appropriate reviews have been conducted.

A.2 RDB Basic Features
Key features for an RE database are listed here:

• All fields/attributes should be definable on a per-company
or per-project basis, such that the same corporate data
dictionary is used on multiple projects for consistency,
but each project can still have its own glossary of terms,
keywords, etc.
• At a minimum, the following requirements attributes should
be available:
• Priority, Stability, Status, Author, Title, Category
Attributes should be user definable on a per-project basis.
• Keywords (note: multiple items dragged/dropped into
one field) As the ability to do queries is of critical need,
a keyword mechanism is mandatory.
• Requirement type (see the preceding discussion of
levels) It should be possible to create requirements of
different types with different attributes and business
rules.
• Project-specific tags (graphics, GUI, etc.) It should be
possible to create attributes that are project specific, so
that if more than one project is stored in the same database
there are no name space conflicts.
• It should be possible to have a parent-child relationship, and
where there is such a relationship, it should be possible to