Register  |  Login

This page discusses a number of traps related to requirements numbering schemes. On this page you’ll find:

       Why consecutively numbered requirements cannot exist

       Why re-numbering should be avoided at all cost

       Why you should never use paragraph auto-numbering

       Why requirements numbers should not be hierarchical


Most of these issues stem from the need to easily obtain the next new requirement number, for example if you write your requirements in MS-Word or Excel. In addition, there are several requirements management tools on the market which use some of these conceptually poor numbering schemes discussed below.


Why consecutively numbered requirements cannot exist

For some reason our minds would like to see consecutive numbering of requirements in documentation. However, as a result of change – reordering, adding, deleting – it is inevitable that soon the numbers won’t be sequential anymore. At that stage people may be tempted to renumber, but this would be disastrous...


Why renumbering should be avoided at all cost

Renumbering is fatal since other people (clients, users, software architects, testers, developers, etc) may already have referred to a particular requirement in some document or project external document. But renumbering is also fatal because we soon are used to the fact that, for example, requirement #25 is about a specific performance aspect. Hence:


Never re-number requirements!!

Why you should never use paragraph auto-numbering

It may seem such a logical and easy thing to do, to just use the auto-numbering feature on MS-Word styles, or to click that number-button in MS-Word to get a numbered list. All will be fine, until you find you have to insert a requirement in the middle of your list. Doing so will renumber the requirements below the insertion point, and whoever, or whatever artefact, was referencing those numbers, will now have to adjust their numbering too.


The same applies if you use a paragraph number as requirement number; say you reference performance requirements in paragraph 2.3 and now a new paragraph 2.3 is inserted (turning the current 2.3 into 2.4)– all your referencing is now out of sync.


So even though it may seem an easy good idea, clearly this is going to cause you much grief. Automatic numbering is only easy right at the start before you have issued the first release. Thereafter you’ve got a real maintenance nightmare. So:

Never use paragraph auto-numbering

Why requirements numbers should not be Hierarchical

There is a school of thought which views requirements as a numbered hierarchy. However this has significant conceptual issues, which are discussed on the page Requirements are not Hierarchical.


A hierarchical numbering scheme, for example 2.4, 2.4.1, 2.4.2 and so on, will have similar issues to that of paragraph auto numbering. What happens to the requirements identifier when you insert a “node”? What happens when you move a node or insert a requirement? Have a look at these examples:



So when you insert, or move, what happens to all those artefacts which reference the original identifiers?! (e.g. 2.4.1)


For these reasons again it is clear that requirements identifiers should not reflect a hierarchical numbering like 2.1, or 2.3.1. Instead keep it simple and just use a whole number identifier like 1, 2, 25, 103, 501. Much easier to maintain, much easier to remember.


Use unique numbers & don’t worry if they don’t list sequentially

As a result of the above, by its very nature, requirements numbers will/can never be in sequential order in the documents, test scripts or code. Don’t worry about it, just treat the requirement’s identification number as simply a unique reference number.


As is shown above, it is paramount that the requirements identification number, once issued, never changes again. Of course you can still group the requirements in their logical presentation order, but that doesn’t have to affect their requirements identification (reference) number.


The power of having a never-changing number is that it can be referenced and searched for across all your documents, tests and code to assess impacts when things change, to find root-causes of defects, etc. Having unique identifiers in documentation, tests and code ensures cost-efficient long-term maintainability and quality.


Of course, if you work with several people on requirements (BA’s, Architects, Testers, Developers) you’ll need to be able to “grab” a next number. This auto-issuing of numbers is one of the features our freeware ReqDb tool provides.


 mail to colleague


Your Rating: 0.0   Average Rating: 0   Ratings: 0
Site Software v2.2.0, 26 Oct 2016