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-
Scope management 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.
How to create the perfect 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.
1. Remove ambiguity
Be absolutely certain that there is no ambiguity between what your business users want and your own understanding.
Organize 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.
2. Be specific
Complete the list making sure you are being as specific as possible.
List colors, 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.
Remember to include non-functional requirements as well as the stuff the customer will be able to actually see.
3. Get customer input (and get a lot of it)
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
Consider how you can continually involve your stakeholders in the project whether you are in an
4. Use your experts
All of this so far 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.
5. Plan for change
Most projects, in my experience, end up with a bunch of change requests. Make sure you have a plan to manage constantly changing requirements because it might happen, and it’s a pain.
In that situation, it’s valuable that the client knows what the steps are so they can properly frame the request. They won’t be shocked by the fact there is an actual process to go through — unlike one of my colleagues who complained he couldn’t have what he wanted all the time because the pesky
(He was fine about it after we chatted. He was just being overly optimistic with what could be done in the time.)
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.