Page 334 - Software and Systems Requirements Engineering in Practice

296 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

have a parent and children of different core requirement
types, for example,
FEAT101
SECRQT101.5
PERFRQT 101.3.3
Note that some commercial databases do not allow parent-
child requirements to be of different types, which can increase
the amount of tracing that has to be done in the database.
• The tool used shall enable end-to-end traceability, as well as
vertical and horizontal traceability. This may require
integration with other tools such as IDEs and/or modeling
and testing tools.
For example,
• Requirement to requirement
• Requirement to test case
• Requirement to PDF
• Requirement to external document (In this case, the need
is to extract a requirement from text and to drag and drop
it into a new requirement; then when the requirement is
selected, the document pops up with the text highlighted.
This is used when extracting requirements from large,
complex documents. Note that it is important to keep
links from getting broken when a document is updated.)
• Bidirectional tracing to and from CASE tool artifacts
(hopefully synchronized)
• What components implement this requirement? (Impact
Analysis)
• What requirements caused this component to be
developed? (Development QA)
• Who is implementing this requirement?
• Automatic generation of warning indicators should a trace
become suspect
• Protection of critical traces with locks that prevent them
from becoming suspect
• It should be possible to generate ad hoc reports based on
advanced searches using combinations of the attributes; e.g.,
“give me all requirements where priority=high and
status=approved OR subsystem=graphics”.
• It should be possible to extract all detailed requirements that
are approved and used to generate/update the test plan.
• It should be possible to create hyperlink references to Word
documents, web sites, etc.