Abstract:

I believe that most requirements specifications in practice are very poor in clarity, and in content. I believe that in addition to tackling the clarity problem by a variety of rich specification devices, we need to make a requirement specification ‘work harder’ to satisfy a large number of needs by adding ‘background’ to the requirement.

The needs I am referring to include: prioritisation, risk management, change management, presentation, justification, testability, integration, quality control, and other purposes.

To do this I have, over the years developed a requirement specification language, as a subset of my Planning Language (Planguage). This is has been developed by practical need in international industry over decades, and supplemented with some recent ideas. The more detailed version of the Requirements Language is documented in my book manuscript Competitive Engineering, which is a handbook defining concepts rigorously (www.gilb.com).

This paper will give an overview of the conceptual basis and some detail as a sample. By ‘rich’ I mean substantially more detail for each requirement than is usual. By ‘background’ I mean information related to the requirement that is not the requirement itself.

I will present the Requirements Language in terms of some basic principles:

A requirement needs to be referenced by a large number of instances in the totality of project documentation; tests, design, architecture, risk analysis, quality control – for example.

Each requirement must be specified once, one single master version should exist, and all uses of the requirement must refer to that master version. They should in particular not copy and paste an instance of it, or rewrite it in subtly different versions.

This lays the basis for an investment in the master requirement. It is worth doing properly, to a high level of quality, clarity and sophistication. You only have to do it once, for the master, and then all reuse of that master requirement benefits.

Here are some of the parameters that are useful to fulfill this principle:
 

This is a simple starting point requirement. The only thing that helps make it reusable here is a unique tag (Reliability). This tag cannot be used by any other requirement in the project (without some qualification to make it unique). The Scale of measure and the Goal level specifications are core requirement specification.

Now we can add some additional optional parameters ('Scale' and 'Goal' were parameters in the requirement language, in the example above).
 

The added specifications in this example are not core requirement specification. They are background specification. They add something to the core specification.

Now notice that many of these types of things are traditionally done at the level of a requirements document, for a set of ‘all’ requirements for a project. The fact that we are moving them to the level of a single requirement implies:

• we are treating the requirement as a distinct ‘object’
   

• we intend to update this requirement independently of others
   

• we intend to consult (owner, stakeholders) about changes to this requirement alone
   

• we intend to quality control this requirement independently of others
   

• there can be many individual authors, each writing their individual requirements, but each clearly accountable for their ‘baby’. No hiding in the committee

The requirement is reusable in the sense of reusable on this project.

more...
 

©Tom Gilb 2005