Measurement and Metrics - Requirements Engineering and Management for Software Development Projects - page 140

Where:
PER Productivity for Establishing the Requirements

EPR Effort spent in person hours for all requirements engineering activities for

establishing the requirements including, documenting, verifying, validat-
ing, implementing the feedback and approving the URS and SRS

N Number of requirements as established in the requirements traceability

matrix or URS

Data for this metric can be collated from:

1. Project timesheets from which the effort spent would be available.
2. Number of requirements can be collated from the traceability matrix or URS.

This metric can be derived after the project requirements are established and are
subjected to configuration management. We need not wait till the project is
completed. It is not easy to derive this metric because, we do not get the effort data
in the usual timesheets used in the industry. We have to utilize special timesheets
to extract effort data required for computing this metric.
Most organizations do not compute this metric because of the difficulty in
obtaining the effort data. If computed, it gives better insight into how each of the
major requirements engineering activities are consuming the total effort and
thereby allows us an opportunity to effect focused improvement.
Another aspect of this metric is that this activity is being downgraded from
being ''business analysis'' to ''technical writing'' in many organizations by
utilizing ''technical writers.'' This is an emerging trend because this activity
(documenting requirements) does not need fully qualified business analysts. It can
be performed using the information collected during elicitation and gathering
activities under the guidance of a business analyst. The advantage is reduction in
the cost of requirement engineering as a whole. This practice is catching up in the
industry. This metric helps us in determining the productivity of the technical
writers and to set targets for them during project execution and better granularity
during cost estimation.

10.3.2 Change Request Metrics

CRs are a reflection of the stability of the requirements. The argument is that if the
requirements analysis is carried out diligently applying all necessary QA activities,
CRs would not be needed. The CRR (Change Request Register) is the source of
information

for measuring the stability of requirements. These metrics are

normally referred to as change request metrics or CR metrics.