Presented at the 1993 Complex Systems Engineering Synthesis and Assessment Technology Workshop (CSESAW '93), Calvados, MD, USA
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| Requirement_Quality_Metrics.pdf | application/pdf | 29.28 KB | English | DOWNLOAD! |
Provides definitions
Abstract
Available data demonstrates that defective
requirements are a dominant cause of cost and
schedule overrun in defense and aerospace programs.
This paper presents a structured methodology for
measuring the quality of requirements, individually
and collectively. It is shown that requirements may be
characterized by ten quality factors, each with an
associated metric, and by an overall requirements
quality metric. In addition, the requirements
engineering process itself can be instrumented by
means of five process-related metrics. The paper
describes the author’s experience with application of
both types of metric to engineering decision making.
A tool which automates aspects of metrics collection
is presented.
Introduction
Requirements engineering deals with the capture,
analysis, expression and traceability of requirements.
Requirements engineering may commence at the level
of a broad statement of military need, and will
continue through the definition of the system solution,
right down to the lowest levels of specification of
elements of that solution, for example, C, D and E
specifications in the hardware world and minispecs in
the software world.
Requirements engineering does not simply
happen, it requires management. Classically,
management is considered to comprise planning,
organizing, staffing, monitoring and controlling. If we
accept that “that which cannot be measured cannot be
controlled”, the role of requirements metrics is readily
apparent.
But which metrics? Should we instrument the
product (the requirements) or the process (the
requirements engineering process) or both? How can
requirements metrics be used to help the project team
satisfy project success criteria? These and related
issues are addressed below.
Extract(s)
Data from TRW developed in the early 1980s
showed that, on a range of representative projects, 30
per cent of design problems requiring correction were
due to erroneous or incomplete specifications. Another
24 per cent of errors were due to conscious deviation
from product and process requirements. Other studies
have shown that the cost to correct an error
typically increases by a factor of between 20 and 1000
over the life cycle of a system acquisition. System
solutions which satisfy the contract, but not the need,
are, unfortunately, commonplace.