Information Technology Reference
In-Depth Information
10.3.2.1 Requirements Stability Metric
Requirements Stability Metric (RSM) metrics normally indicate the requirements
stability.
The
following
formula
is
used
to
compute
requirements
stability
expressed as a percentage:
RSM
¼
Total no
:
of requirements
No
:
of CRs
½
ð
Þ=
Number of Requirements
100
Another variant of this formula is:
RSM
¼
No
:
of CRs
=
Number of Requirements
ð
Þ
100
where, RSM is the Requirements Stability Metric.
We derive this metric to gauge the stability of requirements. There is no
industry benchmark for the requirements stability. We need to establish an
organizational benchmark collating the data from past projects. We compare the
metric for a just completed project with this benchmark to draw inferences and
take corrective and preventive actions. We also use this metric for process
improvement of requirements engineering.
The data for deriving this metric can be obtained from the project CRR and the
traceability matrix or the URS. We can derive this metric only after the project is
completed.
10.3.2.2 Relative Effort Spent on a Change Category
Another analysis that is carried out is the classification of changes into various
categories so that the origin of changes can be determined and inferences drawn to
see if any trend is emerging. Examples of scenarios are:
1. Suppose that the bulk of CRs are emanating from poor coding—then the
organization will be alerted that additional training for coders is necessary.
2. Suppose that the bulk of CRs show that the understanding of customer
requirements was not satisfactory, the organization will realize that Business
Analysts need to be trained to be more effective in the process of requirements
elicitation/gathering.
3. Suppose the bulk of CRs were due to defective design, then the organization
would learn that software designers/architects should be improved.
In my opinion most categories of change requests could be reduced by one or
more of the following suggestions:
1. Training to improve the skills of the personnel.
2. Better software development process.
3. Better tools and techniques.
4. Better standards and guidelines for coding, design, architecture and review.
Search WWH ::
Custom Search