The 5Ws of Requirements Sign-off

I've worked on a number of projects where I had to chase stakeholders for sign-off on requirements. I have also worked on projects where sign-offs were not required or even necessary, due to the "agile" approach adopted. For whose benefit do we really seek requirements sign-off?

1. The Why

Signing off on requirements can become necessary for different reasons. Before you decide it is a complete waste of time, let's explore some of the reasons why business analysts seek sign-off:

1. Some analysts seek sign-off on their requirements because it is "procedure". Procedure says stakeholders should sign off on requirements, so that's what they should do. Getting the sign-off provides some assurance when the auditors come knocking. When a requirement is questioned, the stakeholder approval/stamp is presented as "evidence" of their approval.

2. To protect the ICT Department. This is common with business analysts attached to the ICT Department. If something goes wrong and questions are asked, the ICT department can use the document as leverage and say to users, "See, you signed off on it. We just followed suit". Stakeholders are thus held accountable for their requirements.

3. For regulatory reasons. For mission/safety-critical systems, requirements are usually presented for sign-off as part of regulatory requirements.

4. Signed-off requirements represent a minimum set of requirements, which serve as a baseline for implementation. Requirements sign-off can be used as a risk-reduction technique for avoiding the introduction of late changes to projects. Any changes to requirements after baselining would typically involve a change control process and subsequent approvals. Seeking sign-off with the objective of locking stakeholders into a set of requirements can however, quickly become a futile exercise. This is because stakeholders can and will change their minds about one or two requirements at some point, regardless of the processes in place.

2. The What

So you've decided you need to get "something" signed-off. What exactly should be signed off? Is it the software specification document, the process documentation, the business rules, the requirements or all of these? In our team, we found that it is much easier to get stakeholders to sign off on user requirements, process documentation and business rules. We realized that stakeholders would find the technical/design specification document too complex and time-consuming to understand.

In identifying exactly what you want stakeholders to sign off on, be realistic about your expectations. Lumping ERDs and a couple of DFDs together may lead to an unnecessarily complex document. Consider whether they really need to sign off on technical specifications that have been written for developers. What benefits are there to be had, if any? Also, remember that the simpler the sign-off process, the easier it will be to get the sign-off you need.

3. The Who

Who should sign off on the requirements? Answering this question might require some stakeholder profiling if you are not sure. Identify those interested in the project as well as those with the relevant authority to sign off on the requirements. Some stakeholders may only need to be informed or consulted and may not have the relevant authority to sign off on requirements. Identifying who needs to sign what will not only ease the sign-off process, but will also ensure that the signatures you get carry the weight you need.

4. The How

In what form should requirements be presented for sign-off? Is an email sign-off enough or would you need a physical document to be signed? The reasons why you are seeking sign-off will guide you in determining the most appropriate medium.

5. The When

Requirements are typically presented for sign-off after they have been elicited and analysed, as part of managing scope. If you adopt the Waterfall approach, requirements would have to be signed off before any line of code can be written.

6. The Where

Where will the sign-off take place? Will it be done in a presentation-like setting or are you going to organize a one-to-one stakeholder review after which each stakeholder will be required to sign off on their requirements?

Avoiding common mistakes in chasing sign-offs will ensure that you do it right the first time and experience a smooth sign-off process. Depending on the nature of your project, a formal sign-off may or may not be required. Understanding why you are seeking sign-off in the first place will help you determine the best way to go about it, if at all.