Requirements elicitation techniques focus on what the project is going to deliver; in other words, what is needed.
Table of Contents
Clear requirements form a crucial part of project scope and you’ll want to get clarity on project requirements as early as you can. Often project teams come together without knowing exactly what the requirements are. They might have a goal or vision or business case to work to, but one of the first tasks for the team is to turn that high-level view into a detailed statement of requirements.
This work happens at the beginning of the project. At this point, you aren’t spending time working out how you are going to get there. Requirements elicitation shouldn’t be constrained by “I don’t think we can make that work” conversations. Work out what is needed first, and then later in the requirements process you can prioritize functionality and establish how you can deliver the requirements in a way that meets the overall project objectives.
Ideally, requirements elicitation on projects will be done under the leadership and support of a business analyst. However, many project teams aren’t able to draw on specialist business analysis skills – and the project manager and team end up having to elicit and document requirements themselves.
In this article, we’ll look at 5 techniques to use to elicit requirements.
Probably the first thing project managers think of when considering how to work out the requirements for a project is to get the relevant stakeholders together in a workshop.
Workshops are interactive meetings with facilitated discussions. A good workshop facilitator can help a group uncover core requirements and help them with brainstorming.
The more attendees in the workshop, the harder it is to facilitate and make sure everyone has a chance to contribute. If you have a lot of stakeholders, consider putting attendees into groups and running several sessions.
One to one sessions work better if you have a diverse group of stakeholders, or you think you might not get everyone sharing their views in the open forum of a workshop. You can also hold interviews if you can’t arrange a time when all the stakeholders can get together – which happens quite often!
Plan the interview time so you both get the most out of it. Create a set of questions to use as prompts. You might not stick to the question structure strictly, but at least having them will mean you don’t forget to ask anything important.
Capture everything that comes out of the meeting, ideally in a format that can be played back to the individual after the meeting. Stakeholders won’t always remember exactly what they told you, and they may come up with different (often better, richer) information after the interview, having had the opportunity to reflect on what it is you were asking.
It’s worth scheduling a follow-up conversation after your main interview to check if they have anything else to add, or any thoughts on the notes you shared after your discussion.
Another way to work out what the project really needs to deliver is through observation. If you are working on a process improvement project, for example, spend time watching people do the current process. You’ll be able to spot areas of waste or repetition that perhaps they don’t realize are happening. When you are very close to the detail – like when you do the process every day – you might not be able to see how it could be better.
Ask colleagues to observe each other, take notes of how processes or systems work, and then use this as input to the project requirements discussions.
Requirements for how to improve a process often drop out of an in-depth discussion about the existing process, as we saw above with observations.
Process analysis is a technique where you look at the current process and then map what the ideal process would be. A good way of doing this is to ask people to design the process in a perfect world. In my experience, you then have to go back to the ‘perfect’ process and run the exercise again, looking at how you can actually make it work given the constraints of the operating environment you are working in. If the perfect process is too costly to implement, for example, you might have to make some compromises.
The future state process is compared to the current process to help the team uncover where the gaps are. The project tasks then fall out of this analysis: your work is to help close the gaps, moving the business from using the old process to the new process by making the required changes.
User stories have long been used on Agile projects as a way of documenting rich information about how a solution will be used in particular scenarios. A user story divides the work into functional chunks (increments) that can then be delivered by the team.
A user story focuses on behavior: the behavior of the system. It includes how that behavior is measured and they are a good way of holding discussions about functionality.
Ideally, as a project manager, you would work with a business analyst on coming up with user stories.
Note that you can use user stories on any type of project, not just those being managed in an Agile environment.
If you can work with a business analyst on your project, make use of their expertise. They’ll have a detailed understanding of the techniques above, at a much greater level than it is possible to go into in this article.
However, if you aren’t able to access skilled BA resources, test out the techniques discussed here. It’s worth using several on the project to really make sure you’ve uncovered all the requirements – or at least as much as you can at this point.
Requirements change as the project evolves and that is to be expected. The work you do now is a good starting point, but be open to the idea that the goalposts might move as the project progresses. This is where your change control process comes into play… but that’s another article!