Friday, November 13, 2009
Chapter 22: Measuring Requirements
Chapter 22: Measuring Requirements
Disciplined
software organizations collect a focused set of metrics about each of
their projects. These metrics provide insight into the size of the
product; the effort, time, and money that the project or individual
tasks consumed; the project status; and the product's quality. Because
requirements are an essential project component, you should measure
several aspects of your requirements development and management
activities (Costello and Liu 1995; Wiegers 2001). An effective
technique for choosing the right metrics for your organization is
called goal-question-metric, or GQM (Basili
and Rombach 1988). GQM is a structured thought process that helps you
identify the metrics that will answer questions about whether your
teams are achieving project and organizational goals.
Product Size
The most fundamental metric is the number of
requirements in a body of work. Your project might represent
requirements by using a mix of use cases, functional requirements,
feature descriptions, business rules, event-response tables, and
analysis models. However, the team implements functional requirements.
Begin your requirements measurement by simply counting the individual
functional requirements that are allocated to the baseline for a given
product release. If different team members can't count the requirements
and get the same answer, you have to wonder what other sorts of
ambiguities and misunderstandings they'll experience. Knowing how many
requirements are going into a release will help you judge how the team
is progressing toward completion because you can monitor the backlog of
work remaining to be done. If you don't know how many requirements you
need to work on, how will you know when the project is done?
It's true that not all functional requirements are the
same size or consume the same implementation and testing effort. If
you're going to count functional requirements as an indicator of system
size, your analysts will need to write them at a consistent level of
granularity. One guideline is to decompose high-level requirements
until the child requirements are all individually
testable (Wilson 1995). That is, a tester can design a few logically
related tests to verify whether a requirement was correctly
implemented. Count the total number of child requirements because those
are what the developers will implement and the testers will test.
Alternative requirements sizing techniques include use case points and
story points. See Chapter 5, "Estimating Based on Requirements," for details about these measures of size.
Functional requirements are not the whole story, of
course. Stringent nonfunctional requirements can consume considerable
design and implementation effort. Some functional requirements are
derived from specified nonfunctional requirements, so those would be
incorporated into the functional requirement size estimate. But not all
nonfunctional requirements will be reflected in this size estimate.
Consider the following situations:
If the user must have multiple ways to access
specific functions to improve usability, more development effort will
be necessary than if only one access mechanism is needed, even though
the same functional requirements are being implemented in both cases.Imposed design and implementation constraints,
such as multiple external interfaces to achieve compatibility with an
existing operating environment, can lead to a lot of interface work
even though no additional new product functionality is added.Extensive algorithm and database design work
could be needed to satisfy strict performance requirements, whereas
less effort might be needed to implement the same functionality in a
less severely constrained environment.Rigorous availability and reliability requirements can imply significant work to build in failover and data recovery mechanisms.
For these reasons, be sure to consider the impact of
nonfunctional requirements upon the effort you estimate it would take
to implement the defined functional requirements. The team's
productivity might be lower than expected if they have to expend a lot
of effort to comply with demanding performance, external interface, and
quality requirements.
You'll also find it informative to track the
growth in requirements as a function of time, no matter what
requirements size metric you use. One of my clients found that their
projects typically grew in size by about 25 percent before delivery.
They were also about 25 percent over the planned schedule on most of
their projects. Coincidence? I think not.
No comments:
Post a Comment