Creating good requirements — a simple guide for Business Analysts
How do I know my requirements are good enough?
This is a common question asked both by junior and experienced Business Analysts (BAs) who deal with more ambiguous or complex problems, e.g. large transformation programmes.
Collating requirements for this type of project can be a challenge due to scale and complexity, and it’s not always easy to know when you’ve captured enough information to be able to present requirements to a development team. So, how can BAs make sure their requirements are ‘good enough’?
This article talks a lot about analysing requirements upfront, but this doesn’t mean I am referring to the the Waterfall process only. It’s also necessary in Agile to have high-level requirements and understand the scope of the project in order to start development — you can work on the detail later on. It’s also important in Agile to capture the most impactful high-level requirements accurately as this can determine solution design/size of the project as well as resources required.
What is a good requirement?
According to Business Analysis by Debra Paul, James Cadle and Donald Yeates (Chapter 10) — a good quality business requirement has the below characteristics:
1. Clear
2. Concise
3. Consistent
4. Relevant
5. Unambiguous
6. Correct
7. Testable
8. Traceable
The above attributes are a useful indication, but quite often in reality, projects are run at a fast pace — there can be a lot of ambiguity, which means there’s very little time to assess every requirement. As a result, a Business Analyst will need to make quick decisions to stop refining the requirement and progress to the next stage.
Since starting my career, I’ve improved how I deal with time pressure during projects and have developed a filtering process which gives me greater confidence when it comes to my requirements.
First filter — good selection of stakeholders and techniques
First of all, you can never be 100% certain that you’ve captured all the important details. On big projects we capture requirements from a large number of stakeholders and there’s always a risk that we won’t have met some individuals who may be able to contribute to the overall picture. Stakeholders can also miss or fail to mention certain details.
To reduce this risk, I think it’s important to concentrate on the most important business users in the given context— think about who the main user is, who is going to be the most impacted by this change (or lack of change), which area of the business has the highest number of impacted users. One technique I find useful when identifying stakeholders involved in business process is a responsibility matrix RACI. The matrix describes who is:
· Responsible (the person who does the work to complete a task)
· Accountable (the person who approves the output of a task)
· Consulted (the person whose opinions are sought)
· Informed (the person kept up to date)
Secondly, you can use different techniques to gather your requirements, e.g. interviews are very popular. However, there’s always a risk that a stakeholder will miss some important details or elements of the process. Holding workshops with more than one representative from the same area can mitigate this risk — other users can contribute and fill in the gaps.
Another benefit of a workshop is that when you invite representatives from different areas, not only are you able to gather a lot of requirements at the same time, but users can identify where there might be possible requirement clashes.
In addition to these standard techniques, you can also observe users operating in their everyday job to ensure you’ve captured all the important steps.
On the larger transformation programmes, business stakeholders may change, mainly because of project size and duration. Normally we progress with requirements that have been signed off regardless of this. What I find beneficial is to take your new stakeholders through the requirements so that they’re aware of what’s been discussed previously — they also may be able to contribute further detail by looking at the project through a different lens.
Second filter — seek advice from development team
To seek advice from the development team you don’t need all your requirements nailed down, but you do need to have an idea of what is required, what is the scope and what are the high-level, key requirements. To avoid presenting incomplete material to a larger team, I think it’s best to seek advice from people whom you trust the most. Their feedback is invaluable — they may look at the problem from different angles, will ask lots of questions which can help you with next steps and actions or generate additional queries to stakeholders. You can then go back to the user to get necessary clarifications.
Once you’ve gained clarifications from stakeholders (after initial developer review), you’re in a position to meet the whole development team involved in the project for your first refinement session.
Third filter — peer review
It’s recommended that you have your requirements peer reviewed — asking your colleagues to have a look at your initial set can have a number of benefits:
- Another BA looking at the problem with fresh eyes can prompt questions and generate new ideas
- A colleague with more experience in a given area can check if you’ve covered all of the impacted business areas and stakeholders
- Having someone else review your work can make you feel more comfortable, particularly if you’re new to business analysis
Fourth filter — your own judgement
The more experience you have as a BA the more you can trust your judgement, but it’s really important to start adopting these thought processes at the beginning of you career. To guide your instinct, try to answer the below questions:
- Do I understand the process and the requirement?
- Is it logical for me?
- Do I feel comfortable with what I know at this point?
- Do I have confidence in this idea?
- Am I able to support this concept when someone challenges it?
These questions can also help you connect with a problem, which is invaluable when it comes to effective stakeholder management (check out another blog of mine to see why interest in the area is important). Being passionate about a topic makes BA process easier and more fun!
Recently I decided to take a step back during the requirements elicitation process because I personally didn’t understand the full picture. This can happen especially when you take over a set of requirements from another BA. It can make the process longer, but I’m confident that you can get your project manager on board if you justify reasoning behind it.
If you do decide to go over something again, remember to manage your stakeholder’s expectations and explain why you are doing it — being new to a project is always a good reasoning.
Documentation
Documentation is vital to achieving strong requirements. That being said, you must work on your documentation throughout the project (refining requirements can be a long process, and no one wants to lose the detail captured at the very beginning). In Agile you will document requirements in User Stories whilst in Waterfall projects you will most likely create a Business Requirements Document — it doesn’t matter which methodology you follow; robust documentation is crucial to both. I’m extremely passionate about the visualisation of my requirements and so always have a supporting slide/document which is added to a User Story as an appendix. Because people consume content in different ways, e.g. some prefer images and some prefer longer descriptions, I’ve found that using a mixture works well.
There are many situations where you can use pictures; two are described below:
- When you describe complex relationships: e.g. if I was working on a report looking at movement of goods between different locations, I might find it easier to draw a diagram like the below.
2. When you compare things, e.g. on one project we were defining different types of metrics which should be exposed in our Business Intelligence (BI) tool. All of them were either including or excluding two types of transactions. You can use simple colouring to make it easier to understand.
Encourage your development team to contribute to your documentation — this will make it more complete.
Putting all of this into practice
Theory is quite often easy to understand, it starts to be more complex in reality. Therefore, I’d like to share a working example of how I’ve used my filters.
Whilst on this programme of work, I took over requirements from another BA, learning about them both from documentation and discussions with stakeholders.
One of the requirements was to build a regular monthly report which is sent to a third party. Although the report already existed, it had to be rebuilt to reflect changes to the programme. Initially, I wanted to take over the initial requirements as they were (already signed off by the business stakeholder), but I sought advice from the development team (filter no. two) and it completely changed the delivery approach. I also asked for a peer review (filter no. three). Filter number four (Do I have confidence in this idea?) — my own judgement proved to be particularly important in this example. Even after a number of conversations with stakeholders, I still didn’t feel like I understood every step of the business process, fundamental to creating this report. I also wasn’t sure about the third party’s input and needs. To gain more confidence, I contacted them directly, which actually led to requirements changing again, for the better.
In this particular example, the process was longer, but I still think that the end goal was highly beneficial for all parties involved and wouldn’t have been achieved had I omitted the last and arguably most important filter in the requirement validation process.
The role of a Business Analyst can sometimes be overwhelming, especially if there’s pressure to collate all requirements in a very short space of time. Although it can sometimes look a bit chaotic, I’m a big believer in structuring our work as much as possible.
I hope after reading this you will find gathering requirements a little simpler and next time you’re asked to hit the ground running, you’ll know when your requirements are good enough to move forward with.
Kaja Kurowska is a Business Analyst at ASOS. Kaja is passionate about her role and believes that good team work can make anything possible. Outside of work, she enjoys cooking healthy dishes and loves baking paleo cakes!
