Requirements Gathering
This process often involves a set of activities including:
- Requirements elicitation: getting business requirements from relevant stakeholders to understand user needs;
- Requirements documentation: codifying that information in the form of user stories and feature specifications so they are accessible to the project team;
- Requirements understanding: making sure everyone’s on the same page about what the heck you’re all trying to build.
1. Establish project goals and objectives early
Simple: does it help accomplish a goal, or does it satisfy an objective?
2. Document every requirements elicitation activity
When you’re in the midst of stakeholder interviews and documentation review, you can often feel like you have a great grasp on things.
But then a week goes by,you realize you don’t quite have a full grasp of your business requirements.
You’ll see in #3…
3. Be transparent with requirements documentation
Sure, you understand the requirements. And your stakeholders understand the requirements. But do your stakeholders understand your understanding of the requirements?
This transparency not only helps make sure everyone’s on the same page, it fosters a sense of project buy-in all the way through your project, beginning with the business requirements. And it circumvents the issue of someone saying “hey, you agreed to X but it’s not here!” 6 weeks into the project. If it’s not in the notes, it didn’t happen.
4. Talk to the right stakeholders and users
A project can often have “hidden” stakeholders. Ask probing questions in your kickoff and initial meetings to try and get to who the real users are. Often those people are not going to be the main decision-makers, but their buy-in is essential to a successful project.
Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project.
5. Don’t make assumptions about requirements
The devil truly is in the details, but you can catch him by the tail if you ask a lot of questions and don’t rely on assumptions.
6. Confirm, confirm, confirm
This ties into “be transparent” but is not entirely the same thing. Just sharing your notes with a stakeholder is great, but far more valuable is actually having a quick review with them and getting their official sign-off.
This is true for meeting notes, user stories, diagrams, wireframes, really any kind of requirements artifact that you are creating. Get actual confirmation from your stakeholders that you are representing the requirements correctly in whatever format you’re using, then move on.
7. Practice active listening
Don’t assume that you’re always getting the whole story – listen for little cues that reveal pain points, desires, unstated goals, and assumptions.
8. Focus on business requirements, not tools
Focusing on and listening to what your stakeholder needs, not what your tool-of-choice happens to do best.Remember: requirements are about the WHAT, not the HOW.
9. Prioritize your product features
In an agile methodology, we work towards a Minimum Viable Product (MVP), that would count as a successful product at launch.
10. Remember that you didn’t get everything
Even the best requirements gatherer is going to miss things. Why? Because you and your stakeholders are human beings, and human beings make mistakes. You will think of things later that you forgot to ask. Your stakeholder will think of things that they forgot to mention. Things will change. Priorities will shift.
Ref: