Metrics For The Requirements Model

Purpose :
Record information about metrics applicable to Requirements Management as a result of a literature search.
Record what sources were found and summarize the relevant contents. Propose a starting list of RM
measures or metrics
Some ideas of the status of requirements metrics:

A lot of the material reviewed does not address requirements metrics. Other requirements
material (books and articles) mention that (obviously) we should measure stuff. They do not say
what, specifically.
Examples:
• The INCOSE matrix that compares RM tools has no entry for metrics.
• [Gause 1989] addresses some generic measurements in the Technical Reviews chapter.
• [Weinberg 1997] also addresses generic measurements of process improvement, but he has
no real substance on RM measures.
As Requirements evolve
• We should measure the current set of requirements for size (can we call this requirements
complexity?)
• We should measure RM process values:
• For the elicitation phase we can measure requirements size (this will tell us how much
progress we are making).
• When requirements are approved by users (baselined) we can measure how much they
change over time (to establish requirements churn)
• We should measure how requirements trace to design elements
• We should measure how requirements trace to test elements
• We should measure the “goodness” of requirements for users
• We should measure the “goodness” of requirements for design
• We should measure the “goodness” of requirements for test
Size metrics
• Project size: Number of Features + Number of Use-cases (modified by the number of Events-
in the-flow and the number of Scenarios) – weights needed to develop a single figure.
• Another possibility is to estimate Project size using a multiple set of figures (www Features,
xxx
• Use-cases, yyy Events-in-the-flow, and zzz Scenarios).
• Number of Features
• Number of Use-cases
• For estimates: average number of Events-in-the-flow for all Use-cases
• For actuals: real number of Events-in-the-flow for a given Use-case
• For estimates: average number of Scenarios per Use-case
• For actuals: real number of Scenarios per Use-case
Goodness metrics
It does not seem useful to estimate measures of goodness before the
artifact is defined.
For textual information, the research shows that useful measures are:
• Word count - textual length: this measure is conceptually similar to
lines-of-code for programs and should indicate the complexity of the
element.
• Fog index: this measure of grammatical complexity similar to
cyclomatic complexity for programs.
• Target user understanding: this is an objective measure of clarity and
potential usefulness.
• For Features: user/domain expert understanding rating and fog index.
• For Use-cases: designer understanding rating and fog index for the
entire document (all sections)
• For Events-in-the-flow: tester understanding
Traceability metrics
• As soon as an element is defined we can estimate “how many” elements it should connect to
in a
• downstream fashion. This is equivalent to establishing an estimate of its complexity.
• For example:
• Given that we have identified a Feature, we should be able to estimate how many Use-cases
• it will need.
• Given that we have identified a Use-case, we can estimate how many Events-in-the-flow it
• will need and how many Scenarios it will need.
• Hence, in each iteration assessment phase we can adjust our estimates and compare our
estimates to actuals in a progressive manner. The estimates tell us how much work we have
left and as items get completed we can report actuals VS estimates.
• Traces from Use-cases to Events-in-the-flow can be obtained from the
RM tool.
• Traces from Use-cases to Scenarios may need to be imported from
Rose for actual figures.
• Traces from Events-in-the-flow to Test-requirements can be obtained
from QA personnel as they get completed.
Change metrics
It seems that there are two types of changes we may want to track:
• Changes in content: some requirement needed to be modified for
reasons having to do with user needs or reasons having to do with
project difficulties. Both of these changes have the effect of forcing
the project to evaluate impacts and possibly re-direct some efforts.
• Changes due to progress: some things are getting done and we need
to now about them. For example a Use-case got approved, or
completed, or…
• The project would want to track both types. The details and reporting
schemes need to be
• matched to the process, but we may want to know, at the end of an
iteration:
• How many Features were modified.
• How many Test-requirements passed.
• How many Use-cases were exercised and approved by the user (not
on paper but in real execution mode)
References
• https://sceweb.sce.uhcl.edu/helm/READ_ReqEngSWEN5130/myfiles/
ATM_Example/RMUCv2000_WP1%20Metrics%20for%20RM.pdf

Metrics For The Requirements Model

Uploaded by

Copyright:

Available Formats

Metrics For The Requirements Model

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metrics For The Requirements Model

Uploaded by

Copyright:

Available Formats

Purpose :

Some ideas of the status of requirements metrics:

You might also like