What does success look like?
I like to challenge Business Analyst to look at requirements as an opportunity to define what success looks like for the requestor.
Too often teams fall into a trap focused on prescriptive requirements that are to serve as a roadmap for developers and testers to know what to build and how to make sure it is working. When you start viewing requirements with this prescriptive lens you lose sight of the overall objective and stifle creativity that comes from meeting problems with fresh solutions.
Why do we need requirements?
Requirements are the union between the customer and the solution. They define expectations and how to meet them. Requirements illustrated through user stories or through waterfall documentation play a large role in helping shape technical solutions and the steps it will take to implement. They also lay out the acceptance criteria and use cases for said requested change. This leads to creation of test scenarios and the ability for the team to sign off and say, “yes this is what I requested. It checks all the boxes”.
But what if we offered more with our requirements. What if we could connect those requirements to broader objectives that the customer is trying to solve? What if we could get requirements in such a way that could lead to solutions to problems, they maybe never realized they had? These solutions could ultimately lead to increases in productivity, profits, and/or customer satisfaction. When you shift the mindset that requirement gathering sessions are to get “technical specifications”, to an opportunity to learn about a problem and bring it back to the group for a creative solution; meaningful technical solutions begin to emerge that are readily adopted by users and integrated into processes.
How do I make more out of requirements sessions?
When I was early in my career as a business analyst, I would leave requirements gathering sessions and think, “How am I supposed to do this, when the users don’t even know what they want?”. This usually came from an approach that looked something like this:
Me: “So let’s talk about what “xyz” will look like and what it will do”
Them: “Well I won’t know what it can do until you build it”
There came a point when I realized, that it isn’t the customers job to know how to give me requirements. These requestors represent a segment of the company and were hired to be the best accountant, lawyer, analyst, etc. It is my job to know how to elicit requirements, and sometimes it will require some creativity and perfectly placed questions to make the most out of my requirements gathering session.
Requirement Elicitation
The best questions to use in a requirement gathering session are those that create dialogue and conversation. The more people are talking about a requested change, the more information can be gathered by the Business Analyst to bring back to the developers/testers for a solution. Even better than a rousing conversation, is a moment of silence. If you can ask a question to the customer that causes them to stop and pause and say something like ‘I hadn’t thought of that before”, you have asked a great question. These questions cause people to think through exactly what it is they are looking for and more importantly how it will look if it is successful, and how they will ultimately adopt said change.
Here is a sample of these types of questions that can be used to really drive at sound requirements, that will ultimately lead to technical solutions that users adopt.
- If this project/enhancement does not happen, what would be the impact?
- Is there anything in this process/system that you would not change?
- If this system/change looked exactly how you pictured it, what would the process look like? How would you interact with it?
- What would be your best measure of success?
- Why do you think we need ”xyz”? How did we get here?
- What have you tried in the past?
- What are the top problems/challenges that your business faces? Why?
Finding the right time to ask one of these questions takes practice, and there is no better time than now to start!