Author: Andrea Reese Hurst
At the request of an engineer who I wrote requirements for, I jotted down some tips for good requirements gathering in a software setting. Here they are, a bit tidied up:
Identify the end users, the project owners, and other stakeholders who influence the success or failure of this effort. Schedule time as soon as you can to talk with each of them – especially end users – about their role, their pain points, and their vision for the project. This focuses your efforts and helps get buy-in from all parties early. It dramatically reduces last-minute objections that come out of the blue to torpedo your schedule.
Have the end user walk you through their current process. Specifically, document:
1. where they get the information they need (such as systems, publications, and people)
2. what they do with that information in the course of their work (including what systems and tools they use)
3. what their outputs are, and
4. where or whom they send the outputs to.
Laying this out clearly may help you see a previously invisible solution – maybe they just need access to some useful reports instead of a whole new interface, or maybe there’s no real problem with the current method after all, or maybe the problem is much larger and requires interdepartmental cooperation to address. Regardless, it’s good information.
Document pain points without jumping to solutions. As your stakeholders review their process and pain points, they might propose specific solutions. Acknowledge and document all suggestions, but don’t commit to any one approach yet. As you build a more complete picture of the problem, your team can develop the best solution to address pain points systemically rather than patching together incompatible or costly feature requests.
Gather requirements iteratively. Start by roughing out objectives and requirements, and then get feedback and refine them until they’re ready for development. If you ask stakeholders up-front for permission to follow up, most will be happy to help. People generally love being asked their opinion. For complex projects, schedule a recurring meeting to run through follow-up questions regularly as you refine the project.
Don’t commit to schedules or features with the customer until the project manager and solution manager have nailed down the scope and prioritized the features. Actively manage customer expectations of what they’ll get, by following up on discussions of features by reminding them these are potential solutions that still need to be prioritized and discussed with developers for feasibility.
Talk over the prospective features with development leads to get a feel for feasibility and scope before you go very far down the road of writing up the requirements. They’re the ones who will be doing it, and they know better than anyone what their teams can do by when. Some people call this “T-shirt sizing” where features or user stories come in sizes XS, S, M, L, or XL.
Get the decision-makers’ priorities. Ask them what features are absolutely critical for operations to continue, and then go down the line to the nice-to-haves. One helpful set of categories for this is MoSCoW (Must, Should, Could, and Won’t). Make sure you know why they categorized each feature the way they did.
Author: Andrea Reese Hurst