Requirements Reuse – what is it all about anyway?

Requirements reuse is both an interesting and frustrating subject and one which comes up periodically on discussion fora. There is a wealth of discussion about it, but no general consensus on what it actually is.

Re-use as a concept is a familiar one within the software development world and has been around for a while. However in the requirements engineering field it isn’t common, either at the knowledge or the artefact level even although local pockets of reuse seem to exist. There is an increased management expectatReuseion of requirements re-use in parallel with the introduction of Requirements Management Tools. The perceived benefits are significant savings in terms of reduced analysis time, improved quality and elimination of redundant development effort, all leading to a reduction in the overall delivery time of a project.

But what is Requirements reuse anyway? There doesn’t seem to be a single agreed definition of what it actually is. The best definition I’ve found so far defines reuse as “the ability to use an item again after it has been used already”. This includes conventional reuse where the item is used again for the same function and new-life reuse where it is used again for a different function.

There appear to be flavours of reuse within this such as sharing, copying, selecting and extending requirements, but do these really constitute reuse?

Sharing Reuse occurs where a requirement is shared in its entirety between two projects. If something is shared – then it exists once and as such could be classed more as a dependency rather than reuse.

Copying Reuse occurs when a requirement is copied and used as part of another project, with no traceability back to the original. A change made to this version of the requirement do not affect the original, the two requirements are completely independent. There isn’t a single version of the truth for the requirement and the master copy can be difficult to establish. Does this matter? Is knowledge of the genealogy of an artefact a pre-requisite for it to be classed as reuse?

Selecting Reuse occurs when a requirement is selected from a pre-defined set or list, such as is commonly used for NFRS. This is essentially reusing a structure or template. In most cases the content or values will vary e.g. volumes will need to be established. If selected and re-used in its entirety it probably falls under the Copying flavour.

Extending Reuse occurs when a requirement is extended to cover additional scenarios or variations, with traceability back to the parent requirement. In this case the geology is known. One single version of the parent requirements exists with the new requirement linked to this. Is this reuse, enhancement or even inheritance?

What happens where a set of documented requirements which for some reason did not progress further through the Software Development Life Cycle are re-initiated? These requirements have not technically been used at all so is it really reuse?

There may be more flavours and I may be getting down to a level of semantics in assessing whether they classify as reuse. I could accept all of the above as varieties of reuse to some degree. It would be useful to get wider agreement on this as without understanding what is meant by reuse, it’s difficult to put in place a strategy to achieve it, and metrics enable reuse targets to be established.

Leave a Reply