I hate it when people embed “other stuff” (<– this is a technical term) inside requirements identifications. Often they include context info or a classification scheme. I’ll refer to this practice as “context sensitive id’s”.
My hatred of context sensitive id’s may sound strange coming from someone who advocates the use of context to reduce ambiguity, so let me explain.
The use of context sensitive requirements id’s is only a minor issue. I suppose it is one of my pet hates, perhaps because I think it is very easily avoided. When I say context sensitive requirements identification I’m talking about id’s like “UR.002a” or “NFR.AVAIL.001“: the identification includes context information or a classification scheme.
Since the id of a requirement is used to identify it and to reference it, the most important characteristics of an id are:
- The id must be unique.
- The id must not change during the lifetime of a requirement.
I use a unique but otherwise meaningless number, preferably generated by a tool so that I’m sure it is unique.
Adding context to the id does not greatly affect the uniqueness: as long you don’t use a tool to generate unique id’s, any numbering scheme runs the risk of accidental duplicates. Adding the context may help a little to keep them unique but there are better ways to ensure uniqueness.
The main problem with context sensitive id’s lies in the second characteristic: it must not change. If you want to assign a context-sensitive id, you must first do a little bit of analysis. This must be short, otherwise you end up with a requirement without an id for some time. A short analysis may lead to an incorrect classification. Not normally a problem, unless it means that the requirement gets an ‘incorrect’ id.
Consider the following example.
Say you’ve assigned an id such as “NFR.AVAIL.001” to the requirement “The help function must always be available”. A few weeks later you find out that what the stakeholder actually meant was “Whichever type of solution you choose, it should have a help function.”. You decide the requirement is not really about availability, but about a particular function being required. You can now choose to keep the misleading id, or to change the id to better reflect your understanding. Neither is great, though changing the id could be acceptable if it has not been referenced yet.
This doesn’t mean you can’t show the classification or the context of a requirement. Just make sure it is distinct from the requirements id. That way you can change the classification or context part, while keeping the unique id unchanged.
Am I being too harsh? Are there good reasons or mitigating circumstances for the use of context sensitive id’s?