How to Get Project Requirements from Stakeholders
Gathering requirements from project stakeholders often feels like pulling teeth. And if you don't put in the legwork to flesh out all of the requirements prior to beginning development in a project, you'll wind up with a very long list of issues during testing that should have been captured as requirements. There are a variety of ways to drive the conversation to ensure you capture all of the requirements as part of a project, such as collecting user stories, setting up brainstorming sessions, diagramming process flows, and more. Whether you're a project manager or a business analyst, this article walks you through some of the more standard approaches to gathering project requirements to make sure your project gets started on the right foot.
Whether you're building something completely new or updating an existing application, the first round of requirements should always be captured through user stories. Whether these stories come from end users or stakeholders doesn't matter, and you can gather them from anyone. The goal is capture their expectations for what is going to be built. and details around how they want it to operate. There are different formats for capturing user stories, but they all generally capture the role associated with the requester, what that person wants, and why they want it. These stories will need to be fleshed out further in the project process.
Brainstorming sessions typically involved all of the identified stakeholders and some of the prospective end users getting together in a room, and throwing out their ideas around what the requirements for a project should be. The goal is to keep the discussion going and to keep people talking. If there are discrepancies between requirements that have already been talked out or your interpretation of the requirements, put it out there for the group to kick around. Because these sessions often move incredibly quickly, it's best to record the conversation or have a dedicated scribe so that you can focus on being an active participant rather than get tied up trying to capture everything. If you do go down this road, it's not uncommon to have more than one of these sessions to ensure that everything gets discussed.
Continue putting the requirements in front of the project stakeholders to review, and don't underestimate the amount of time it can take a group to reach agreement around all of the requirements of a project. It's not uncommon that discussing for a small project can take a couple of weeks. One approach is to wait until everyone gives a verbal sign-off on the requirements, and then wait a few days before circling back up with everyone to get their signature on a formal document where you can ask them to take a quick look again -- just to be on the safe side. Another approach is to have someone else in the business with knowledge around what you're doing review the requirements to make sure that everything appears as air-tight as it can be.
Process diagramming is where you pull the entire team together and walk through the flow for each of the identified processes that will be part of the project. This forces the stakeholders to think about each and every step through the requested application, and often exposes new requirements that no one had taken into consideration previously. The output of these sessions also serves as a fantastic input for wireframing.
Business Analysis Using User Stories
Keep Asking Why
Asking why is a powerful driver during requirements conversations, and specific, clear requirements will not be reliably fleshed out until it no longer makes sense to ask that question. It forces the stakeholders to think through the granular components of their initial requirements, which can be painful and time consuming. Additionally, sometimes continually asking can ultimately expose something that was initially thought to be a requirement that doesn't need to be a requirement after all.
© 2017 Max Dalton