Requirements vs Specifications

One of the areas of confusion within industry, including the IT Industry itself, concerns the difference between ‘user requirements specifications’, ‘functional specifications’, ‘functional requirements’, etc., when developing computer systems.  The confusion commonly stems from both a lack of standardisation of terms and a failure to give terms a scientific meaning.

This is an important topic, because our ability to implement IT systems that do what we need them to, and provide us with the business value we expect, hinges on a good grasp of Requirements Engineering.  Please note that in this article we are not discussing the problem of knowing if we have ‘built the system right’ (another important topic, traditionally known as ‘Verification’), but the problem of ‘building the right system‘ (the original meaning of ‘Validation’ in the historical software development concept of ‘V&V’ or ‘Validation and Verification'; albeit a narrower meaning than we tend to attach to the concept of ‘Computer Systems Validation‘ in GxP environments these days).

Why do we invest in an IT system?  Presumably it is to bring about useful effects in the World that we could not achieve, or could not cost-effectively achieve, without the system.  Most of these effects, however, will be ones that the system cannot bring about directly.  This idea is illustrated in the diagram by the small yellow star that represents an observable effect in the World. At Virtual PV we simply call an effect we want a ‘Requirement‘ (following Jackson).

Requirements are related to the problem to be solved, and it should be obvious that a poor understanding of Requirements means a poor understanding of the problem and a high likelihood that the eventual System will therefore fail to deliver the benefits anticipated.

In order to bring about the effects we want, we require our System to have a set of appropriate characteristics and behaviours where it interacts with the World (i.e., at its system boundary, or interface).  We need to specify these phenomena appropriately so that Requirements can be met.  At Virtual PV we simply call a phenomenon we want from the System a ‘Specification‘ (again following Jackson).

Now, where a Requirement concerns phenomena in the World outside the System’s interface (as most Requirements will), whether or not we can satisfy that Requirement does not (and cannot) depend directly on the System and its characteristics and behaviours.  In fact, it also depends upon relevant characteristics of the World outside the system; or, if you like, whether our assumptions about the World are correct.  At Virtual PV we call these assumptions ‘Domain Knowledge‘ (again following Jackson).

Hopefully you are beginning to appreciate the key conceptual difference between Requirements and Specifications, and the importance of getting such descriptions ‘right’, as well as of having a good understanding of the environment (World) in which the System will operate.  It is good practice to write a ‘Satisfaction Argument‘ for each Requirement to explain why it will be met; such an argument will show how implementing one or more of the System’s Specifications will bring about the desired effect (Requirement), given certain assumptions (Domain Knowledge) about the World. Such Satisfaction Arguments provide a far more reliable and meaningful way to demonstrate requirements fulfilment and traceability than traditional methods (such as the ‘traceability matrix’).

For completeness, we should note that there are occasions when a Requirement can be met directly by the System (although this is usually accidental), and in such cases a Requirement is simultaneously a Specification and vice versa (ie Requirements and Specifications are not necessarily distinct; the System interface exists in the World, after all!)

What about development documentation and its naming?  Well at Virtual PV we would normally produce (where we were not using a Requirements Management System in place of documents) one combined document typically called ‘Requirements and Specifications for System X'; this is because Requirements and Specifications are closely related and Requirements Engineering tends to be an iterative process.   However, in traditional language you might choose to produce a ‘user requirements document’ as a place to list and describe what in this article we have termed Requirements and Domain Knowledge; and a ‘functional and non-functional specifications document’ (or simply ‘system specifications document’) as a place to list and describe what we have termed Specifications.

In the West we have a tendency to focus on the solution too early and spend too little time understanding the problem to be solved. This tends to manifest as an excessive or too early focus on Specifications (the functional aspects of the system) at the expense of Requirements, including to the extent that user requirements documents may in (poor) practice contain a preponderance of Specifications rather than Requirements, and a dearth of documented knowledge and assumptions about the World in which the System will operate (which would otherwise be made explicit and possible to verify).

In this article we have aimed to bring greater clarity to an area of common confusion and risk in system development. We hope we have also shown why the early phases of system development need to emphasise understanding the problem more than the solution.

Please let us know if you found this article useful, and feel free to ask questions; we can be contacted via our Contact Us page.

Posted in Design, Requirements Engineering, Software Development, Validation