Requirements - to update, or not.

I was copied on an email the other day. It was (yet another) notification of a change in Process.

Basically, it dictated that any change to requirements (aren’t we all familiar with those?) needs to be reflected on both a formal change request form and an updated Business Requirements Specifications document and distributed to Release Management for presentation to the Change Board for approval.

'So what’s wrong with that?', you ask. Well, nothing really. Apart from the fact that it could take a week to get the change approved, the email sparked a lengthy debate regarding the purpose of the Requirements document. You see, there are those who view it as the definition of the Requirements and nothing more, and those who believe it should be used as a basis for test planning and to validate what is delivered to Production.

If you decide to update the Requirements with every clarification or technical compromise, then that document must come under change and version control, with each new version being distributed for signoff.

If you believe that the Requirements are just that, and should always reflect just the baselined requirements, then a separate document is required to capture the Functional Specification. This will be an IT document; signed-off by the Business, and used to define what will be delivered. This is then the document used for test planning as well, while the Requirements document remains in its original baselined form. It is then the Functional Specification that is updated on the basis of an approved change request.

I think both approaches are valid, and the official methodology - sorry, framework - is not specific, and I don't believe that CMMI is, either. PRINCE2 doesn't go down to that level of detail. In the end, it comes down to how your organisation works, or if they have no stipulated preference, then it's your choice.

It is obviously best to define the approach you are going to use (being a lazy PM and not wanting to create another document is not a good reason to ask the Business to update the BRS either) in advance, and agree that with the Business representative. NB. Document the decision in your official Terms of Reference or Project Plan.

Because the change request itself is seldom, if ever, detailed enough to use as a basis for test planning, and cannot easily be appended to the BRS, it is not sufficient to rely solely on the CR. If you are not going to update the BRS with changes, make sure that they are reflected in a Functional Specification, or some other IT-generated document that is signed-off by the Business.