How to measure software

There is no such thing as ‘the’ size of a piece of software. There is no size measurement scale for software such as the metric system for measuring length that is universally agreed on. There are only various methods for measuring ‘a’ software size of varying usefulness, accuracy, ease of use and value.

Basically, there are two types of software size measures,  Either you can measure the amount of ‘functionality’ that the software is required to provide, or you can measure the size of the physical components of the software when it is created.

A ‘functional size’ is defined in the standard ISO/IEC 14143/1:2011 as “a size of software derived by quantifying the functional user requirements”.  The latter, usually abbreviated as ‘FUR’, are defined as “a sub-set of the user requirements. Requirements that describe what the software shall do, in terms of tasks and services.”  Functional user requirements exclude quality, organizational, environmental and implementation constraints.


Some very simplified examples of FUR, whose functionality can be measured would be:

  • the software must be able to record data about new employees, and to update that data as they change their marital status, get promoted, leave or die

  • the software must be able to receive signals about the actual temperature, compare it against a pre-set target temperature and send control signals to a heater to maintain the temperature within plus or minus 1 degree Centigrade of the target temperature

  • the software must retrieve the given record from disk storage and either return it or return a message indicating failure to retrieve

Some examples of user requirements that would NOT be considered to contribute to a functional size measurement would be:

  • the software must have no occurrences of a major defect in its first month of operation

  • the software must be made available only on the company’s PC’s in secure locations

  • the software must be written in C and operate on a standard PC

  • the software’s average response time must not exceed 1 second averaged over the weekday period of 11:00 to 12:00 for all types of standard operational transactions and enquiries

Advantages of functional size

Functional size measures have the advantages therefore that they:

  • are independent of the technology used for developing and implementing the software; it follows they are ideal as the size component of project performance measures, since project performance can be compared across varying technologies, platforms, etc;

  • can be estimated from statements of requirements early in the life of a project; they are therefore valuable for project estimating and for project scope control purposes

Physical size measures

Physical size measures include counts of source line of code (‘SLOC’), modules, object-classes and such like, even lines of documentation.  Whilst they can be measured precisely and even automatically in some cases, such measures suffer from several important disadvantages, for example:

  •  a size of any piece of software is not known accurately until the software is built; these measures are therefore of limited value for estimating purposes;

  • the size measures are technology-dependent, making it difficult to use them to compare project performance across varying technologies;

  • there are almost no agreed standards for such size measures.  Measurements of SLOC, for example, can vary hugely depending on the line-counting conventions adopted;

  • an experienced programmer writing efficient code may encode a problem in a few lines of source code.  An inexperienced programmer may write more lines for the same problem.  A SLOC count as a measure of ‘work-output’ may therefore be entirely misleading.


In summary, functional size measures of software are generally preferred to physical size measures where the functional size measures can be shown to work effectively for their intended purpose.  See also the ‘uses’ of functional size measures.