10 Steps to Successful Requirements Gathering

1. Establish Goals & Objectives Early: This step can feel redundant: of course we know why we’re doing this project…don’t we? Even if you think you know, write it down, and get your client to sign off on it. Without clearly stated goals and objectives, you are lacking a framework to guide future decision-making. How do you know if a newly introduced requirement actually fits in your project? Simple: does it help accomplish a goal, or does it satisfy an objective? If so, it’s probably a good fit. If not, it’s a good candidate for a future release.
2. Write It Down: When you’re in the midst of stakeholder interviews and document review, you can often feel like you have a great grasp on things. But then a week goes by, and some details start to get a little fuzzy, and you realise you don’t quite have a full grasp of X, Y, or Z. It sounds obvious, but making sure that you are taking detailed notes during your stakeholder interviews is a powerful step in successful requirements gathering. And it’s not enough to just write everything down, as you’ll see in #3…
3. Be Transparent: Sure, you understand the requirements. And your client understands the requirements. But does your client understand your understanding of the requirements? After every meeting, go through your notes and clean them up – then share them with the project team, including the client. 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 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 People: A project can often have “hidden” stakeholders. Ask probing questions in your kick-off and initial meetings with your client 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. Get Detailed: Don’t assume that you understand everything, even if it seems obvious. A seemingly simple requirement such as “we want a blog” can mask all sorts of underlying assumptions, requirements, etc. What are the fields for a blog post? How are authors managed? What about tagging? Categories? How are the posts displayed? Are they aggregated into an archive? Is there an RSS feed? Who are the authors and what is their level of technical proficiency? Etc. etc. etc. 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 client 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, wire-frames, and really any kind of requirements artefact that you are creating. Radio silence is not an indicator of success – get actual confirmation from your client that you are representing the requirements correctly in whatever format you’re using, and then move on.
7. Be An Active Listener: Making someone feel heard is one of the greatest things you can do for them. But it goes beyond just listening to what they say – you also need to listen to what they don’t say, and how they say things, and read their body language, etc. This is called “active listening” and it’s a key component both of successful requirements gathering and improvised comedy, among other things. 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 Requirements, Not Tools: Be careful when you are gathering requirements that you are really focusing on and listening to what your client needs, not what your tool-of-choice happens to do best. Even if you know you are going to be using a certain product, you need to adapt the product to the user, not the other way around. Listen and gather first, then determine where the gaps are between your client’s needs and any existing product you may have in mind. Remember: requirements are about the WHAT, not the HOW.
9. Prioritise: In an agile methodology; we work towards a Minimum Viable Product (MVP), which encapsulates the least amount of functionality that would count as a successful product at launch. Even when following a non-agile methodology, prioritising is your friend when you are gathering requirements. It’s easy for requirements gathering sessions to turn into wish list gathering sessions, where stakeholders tell Santa (i.e. you) everything they want. The point isn’t to ignore that information (in fact it often reveals goals and assumptions if you’re using Active Listening) but rather to clearly and transparently prioritise what you’re hearing and delineating what is in scope for your initial launch and what is not. You definitely want to track wish-list items, “nice-to-haves,” etc. but prioritising helps you focus your efforts and helps you make decisions if time gets short and something has to go.
10. Remember That You Didn’t Get Everything: Even the best requirements gatherer is going to miss things. Why? Because you and your clients are human beings, and human beings make mistakes. You will think of things later that you forgot to ask. Your client will think of things that they forgot to mention. Things will change. Priorities will shift. The good news is that if you plan ahead for this, you can build in time during your project life-cycle for on-going requirements management. This time is essential because requirements (being human-driven and human-created) are simply not static. Giving yourself time to actively manage requirements throughout the entire project can help you stop scope creep before it starts, and make sure that your team is always focusing on the right set of priorities that match actual requirements.