The team is still working to reduce ambiguity on the project and define the requirements, but it’s being done in a different way to an approved scope document. They are using constant iterative development which refines the requirements in practice during the project.
On a non-Agile IT project, which will probably use a waterfall methodology, you may have lived and worked with the system details for weeks, if not longer, before handing over the requirements document to the team who will eventually build it. It’s easy to assume that as you know exactly what you mean, they will too - but this is a dangerous assumption to make.
Documenting scope is a laborious task, but it is essential to the success of your project that you get it right. That means not only including all the relevant details, but also writing it in a way that is unambiguous. A document doesn’t give you the luxury of someone being able to see all those doodles you drew during the requirements meeting or your hand gestures explaining what the new system will be like. So you need to make sure that there is complete clarity in the document, or the customer won’t get what they want. Remember, the project requirements list is not a document for you; it is a list of detailed instructions to someone else.
Tips for compiling business requirements
So where do you start with creating that perfect requirements document? Here are some tips for putting together the business requirements for your project:
- Be absolutely certain that there is no ambiguity between what your business users want and your own understanding. Organise a workshop to elicit what it is they really want from your project. This is an opportunity for complete blue-sky brainstorming - if they could have anything as a result of this piece of work, what would it be? Get them to be clear about their requirements, ask the stupid questions, then negotiate. It might never be possible to have a dedicated customer service representative for each client or response times to customer calls within two seconds but those requirements allow you to form an understanding of what is important to your customer: in this example, the business user.
- Once you have the list, add to it making sure you are being as specific as possible. List colours, materials, brand constraints and any legislation with which the solution must comply. Are there any other systems with which it must integrate? What security is appropriate? Detail exactly what is meant and spell out any assumptions.
- Verify the document with the project customer before it goes to anyone else. In other words, check that you have understood and documented their requirements in a way that is meaningful and clear. Include wireframes, screen mock ups or models if this helps eliminate ambiguity further. Once the customer is happy that their requirements have been adequately captured, you are ready to start the next stage of the project and build the solution.
Allowing the project stakeholders to review the document also means that if the system does not deliver what they were expecting when they first see it you are in a better position to explain why: you gave them plenty of opportunities to add new requirements or clarify existing requirements. If the stakeholders didn’t take those opportunities they will have to use the formal change control procedure to make any alterations or add new requirements to the project scope at this stage. This is where Agile project teams have a huge advantage over traditional, waterfall ways of working. They will quickly pick up changes to requirements and be able to adapt to them - consider how you can continually involve your stakeholders in the project whether you are in an Agile environment or not to ensure that as the design and build progresses that they are getting what they want.
Use your experts
This assumes that you’ll be preparing the requirements yourself, but if you can draw on a skilled business analyst then they will probably be better at doing this than you. Business analysis is a toolset aimed at eliciting requirements and ensuring solutions are fit for purpose, amongst other things. Business analysts are excellent facilitators with a good working knowledge of business processes. They can work alongside you on a project to eliminate ambiguity and provide the ‘translation’ from business-speak to project-speak that you and the rest of the team may need.
A good requirements document (whether it is written by you or a business analyst) should not only ensure your product is built exactly as you wanted, but also forms a way of checking off users’ needs at the testing stage. It will form the basis of the user testing documentation and if it is very detailed, for example including process maps, it may save you (or your expert testers) time in writing test scripts.
When you have to skip the requirements phase
What? You want to skip preparing the requirements documentation for the project? While it isn’t good practice, it’s not as uncommon as all that. It is inevitable that at some point in your career you will work on a project where there is simply not the luxury of time for a full requirements document, even if you do have someone to help or do it all for you.
In these situations it is essential to work with your team to revise things as you go along. It can be risky, but if it is a well-thought out and relatively simple project then this approach can save a lot of time. Just remember to update the requirements document as you go along so at the end you have an accurate record of what has been done.
If you do opt for the make-it-up-as-we-go-along approach, make sure you allow enough time in the plan to test your solution thoroughly, both technically and from a user’s perspective. It is much easier to alter things at the testing phase than after the project moves into a full implementation.
Finally, if you are in any doubt about whether or not your team can handle the ambiguity of not having proper requirements to start with, make the time to fully elicit all the requirements and to document the output - it really will be worth it.
