Requirements Auditing: Is the Specification Fit For its Purpose (part I)
When someone gives you a requirements specification how do you know whether the specification is complete and unambiguous? How do you know whether the specification is fit for its intended purpose? In short, how do you know whether it is a good specification? Requirements come in many different formats and levels of detail, and whenever they pass from one person to another there is a risk of misinterpretation. In these days of large distributed organisations, global projects and outsourcing, the risk of ambiguous or missing requirements is multiplied. A misinterpreted requirement can cost thousands and can mean the difference between project success and failure.
You need some way of determining whether the specification is complete and some way of spotting assumptions and ambiguities. In short you want to know whether the specification is good enough to successfully communicate the intended details to the intended audience. This paper talks about our approach to auditing requirements specifications and finding requirements defects before they cause damage.
Audits in other fields
Every year a professional firm of accountants audits our company’s financial records. The auditors make sure that we have been charging and paying the correct taxes, they check our invoices, payments, purchase orders, receipts and bank accounts. They make sure that we have been running our business according to the laws of the land. The auditors know what our records should contain and how much detail is necessary. They also know how to make sure that the details are consistent. Just like other companies, we keep our records organised according to long established accounting principles; this makes it easier for the auditors to follow what we have done. It also makes it easier for us to find the answers to questions. The point of having the audit is to provide an official checkpoint that we are operating correctly and that our records are consistent and understandable.There are parallels between a requirements audit and a financial records audit. The purpose of both audits is to avoid future problems by identifying problems early. However a key difference is that financial audits are obligatory and have a well-defined set of standards. So the auditors know where to start and they have an objective way of communicating deficiencies and raising questions. The records have a reasonably consistent form, the expected content is well defined, the level of detail is defined and the rules for consistent connections between financial records are not open to debate.
But in the case of requirements specifications we do not have a set of standards that define the obligatory contents. Instead, the form, content, detail and connectivity are all variable depending on the characteristics and choices of the particular project. However, by taking a closer look at these variables we have learnt how to do relevant and productive audits for all manner of requirements specifications.
Form, content, detail and connectivity
The form of a specification refers to characteristics like the way that it is organised, the way the contents are grouped, the use of text and diagrams, the indexing, the typefaces, the colours, the medium (paper or electronic) – everything that determines the document’s arrangement, format and appearance. Particular document design standards or the use of an automated tool quite often dictate the form of the specification.
The content is the classes of subject matter that are contained in the specification. For example a requirements specification might be expected to contain things like an unambiguous definition of the scope of the requirements, a definition of the stakeholders, a specification of the functional and non-functional requirements, a definition of the terms used in the requirements and other pieces of requirements-related information as agreed by the particular project team.
The detail relates to the granularity of each of the essential pieces of subject matter. For example should this document contain measurable atomic requirements or is it a preliminary document that just summarises the business use case scenarios?
The connectivity is the formal structure that connects the requirements knowledge and makes it traceable. If the specification contains atomic requirements then can each requirement be traced to the related parts of the business? Are all the terms in each requirement defined? Can each requirement be proved to be relevant to the scope of the project?
The challenge in doing a requirements audit is to be able to look past the form to discover whether the content, detail and connectivity are adequate for the intended purpose of the specification. In other words, if this specification is given to the people for whom it is intended, then what decisions will they be able to take and what assumptions will they need to make?
Doing an audit
We developed the Volere requirements template (available at http://www.volere.co.uk) as a structure for guiding requirements discovery and organising requirements knowledge. Similar to financial audits, if you have used a formal structure for organising your requirements then it is easier to audit them. The auditor knows precisely what he is looking for, what level of detail should be provided and how all the elements should be connected to each other.
But we come across many specifications that have not been produced using a well-defined structure. So we do the requirements audit by using the requirements template as a checklist for driving the audit. Here’s how to do it:
- A copy of the Volere template
- A selection of coloured post-it notes (the coloured tabs are best) for marking pages
- Coloured pencils
- Index cards
- The specification that you wish to audit
- A spreadsheet program like Exel
- Some peace and quiet