Measuring Requirements and Changes


When a set of requirements is prepared for a software artefact there are two very important attributes of well formed requirements, they must be testable and measurable.

What is a requirement?

A requirement is a statement which describes what a system should do or how it should behave. There are two types of requirements these are functional and non-functional.

A functional requirement is a statement of what the system must do – thus a requirement might be: "Display the heart rate, blood pressure and temperature of a patient connected to the patient monitor".

A non-functional requirement is a statement of how a system must behave, it is a constraint upon the systems behaviour. For example: "The display of the patient's vital signs must respond to a change in the patient's status within 2 seconds".

Now clearly both of these requirements are testable because we can manually monitor the various vital signs and confirm that they are correctly displayed. We can also check that any changes are displayed within 2 seconds.

The functional requirements can also be measured using one of the Functional Sizing methods available (COSMIC-FFP, IFPUG FPA and MKII FPA).

Controlling requirements change

The measurement of requirements is very useful if we wish to prepare an estimate of the cost of producing the software. However there are many more innovative uses for the measurement of a requirement.

Among the problems that beset software projects is that they are often delivered late and/or over budget. By measuring the original requirements and the effects of any change requests it is possible to manage their growth, which is the usual cause of increased cost and delays.

An excellent example of this process is that devised by the State Government of Victoria – SouthernSCOPE. (Visit or contact us if you would like to know more).

Whichever method is being used, it is imperative that changes to requirements are measured so that their effect can be predicted.

Changes can have effects other than delaying a project. If an outsourcing company has undertaken to improve the productivity of software development, but continues to accept late changes, it will discover that these have a negative effect on productivity and this should be accounted for in the contract.

GIFPA Ltd. 2016

Copyright 2016

All Trademarks Acknowledged

Applying Software Metrics
Assessing Capability     
Estimating and Risk       
Improving Processes     
Measuring Performance
Tools and Techniques   
About GIFPA         
Copyright & Legal