Hi.
I'm Max Dalton, and in this video I'm going to talk through 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.
User Stories
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
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.
Review Sessions
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
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.
And finally: 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.