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 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:1997 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. The Functional User Requirements represent the user practices and procedures that the software must perform to fulfil the user's needs. They exclude Quality Requirements and any Technical Requirements.'

So 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
• The software must retrieve the given record from disk storage and either return it or return a message indicating failure to retrieve

Some example of user requirements that would NOT be considered to contribute to a functional size measurement, as they are technical or quality requirements would be:

• the software must have no occurrences of a major defect in its first month of operation
• the software must be written in C and operate 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

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.