Page 332 - Software and Systems Requirements Engineering in Practice

294 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

Type of Precedence
Glossary Description Sample Term (1=highest)
Corporate Standardized Stakeholder: A 3
glossary terms across corporate officer, who
all business may be a member of
organizations the board of directors.
Organization Terms that Stakeholder: An 2
glossary are unique organization manager
to a specific of rank department
organization within head or above.
a corporation
Project or Definitions that The product manager, 1
product are customer, designated customer
glossary domain, product, representatives, and
or project specific project management
staff.

TABLE A.1 Example Glossary Hierarchy

a well-thought-out hierarchy is necessary to manage scale and
support coverage and impact analysis. An example requirements
hierarchy is shown in Table A.2.
By rigorously defining requirements levels and defining rules for
traces, queries relying on trace mechanisms can be considerably more
effective. For example, an impact analysis is performed to determine
the cost of a change to a product feature. The feature traces to level 6
system requirements, and the system requirements trace to a specific
level of design, resulting in a reduced set of objects coming back from
the query, i.e., only those directly impacted by the proposed feature
change. Furthermore, restricting and enforcing traces by levels
increases the number of metrics available for RDB analysis.

Metrics Definition Metrics must be defined in advance in order to
configure some requirements attributes and business rules for
evaluating metrics. Table A.3 shows typical metrics and their
implementation in an RDB.

Requirement Type Possible Levels Can Trace Only to Level
Stakeholder request 1 2
Customer requirement 2–4 3
Product feature 3–5 6
System requirement 6–9 Design Component

TABLE A.2 Example Requirements Hierarchy