Knowing what you want to build is easy. Saying what you want to build is hard.
Gathering requirements is, by far, the most crucial part of any software project. A talented team can build an amazing product with the latest tech stack, an amazing user experience and a solid viral loop but if it isn’t what the client or stakeholder wanted to build, you’ve completely wasted your time. You’ve built a Lamborghini Aventador and the stakeholder really wanted a tractor.
(Interestingly enough, Lamborghini also builds tractors — so maybe there’s a lesson for another day buried in that little fact.)
These are Gemini Development’s best practices for requirements gathering. Your mileage may vary, but this process has served us well and has thrilled our clients.
There are three parts involved in gathering requirements: the gathering itself, organizing the mass of information you collect and then finally reviewing this structured information with your stakeholder.
When gathering requirements from my clients, like to block off a long afternoon meeting. Give yourself ample time. This isn’t something to rush. Let your stakeholder explain everything from a high level first and then start asking more detailed questions.
Take detailed notes of any repeating workflows or awkard processes you catch. Let them “get it all out” — the conversation will naturally run into snags as they attempt to explain how certain things should work. Mark these as problem areas to revisit if they dont’ have an answer.
Ask them to step through several scenarios, take time to go through user onboarding, the core loop of the product and then through some edge case or dead-end use cases. Dig into areas that seem fuzzy or seem like the stakholder hasn’t thought all the way through.
Once they’ve described their dream product, get out your pruning shears and start trimming this thing down. This is probably the hardest part of the conversation. You and the client need to work through what constitutes “dream” and what constitutes “reality”. Some features are going to hit the cutting room floor immediately.
Make sure you ask your stakeholder about their ideal users. Get them to describe other applications they use, their habits, their lifestyles. Use this information to drive the user experience and find patterns in other applications to copy. The more you learn about your future users, the better product you’ll be able to create.
Let the stakeholder know what’s realisitc and as they craft their ideal product, start to pare down things you see as superfluous. Sometimes interesting wrinkles and features can be found in lofty goals. Let them craft a full featured product in this conversation but continually ground them and set their expectations in reality while you determine what is going to be built first.
I’m convinced there are two ways to organize your stories, sketches and notes that you’ve now collected.
By architecture and by user type. Choose one, stick with it for the project.
When organizing by architecture, you can split your stories into the large segments of the software that you’re building. For a blog you’d split it up into admin functions, post functions, etc.
When organizing by user type, you split your stories by your end users. A section for admin users, a section for XYZ type of user, etc.
Take these notes, sketches, personas and bits of information you’ve gathered and compose your user stories. Break them into workflows, actionable steps and portions of your arhitecture. I do this in Trello, you can basically do this with any kanban application or even just in Evernote.
Once you have a the major chunks of the requirements broken out, start fleshing them out with checklists of smaller tasks necessary to build that entire feature. Checklists that can be made into stories and those are easy to review. Give as much detail as you can to each feature, down to user interaction, basic UX and list of potential interactions with other areas of the software.
Back track from time to time to make sure you don’t duplicate processes. I often find myself having to be careful not get too emotionally “into” the project and start adding features or ideas of my own. This can get dangerous quickly for people who get excited about products. Simply organize and catalog what you’ve collected. Don’t add to the structure of the application.
Now that you’ve got all the requirements nice and organized, meet with the stakeholder again.
Walk them through all you’ve collected, talk about the workflows you’ve created, specific features and how users will interact with these features.
Now is the time to show off sketches, wireframes and UX ideas. Make sure that what you’re describing is the product they want. Verify that features described work they way they’d imagined.
Step them through an entire process from the point of view of the
Get definite confirmations of features, engage the user and ask to drop features where you feel there are workflow excesses.
Even here, don’t stop the stakeholder from dreaming. If there are features they haven’t thought of or something they want to add? Let them. But make it clear they’re expanding the scope of the project.
Recap and TL;DR
In the end, gathering quality requirements is about creating an open conversation with your stakeholder and feeding off of their excitement about the project.
As you gather the requirements, let the stakeholder explain their end goal to you and then work with them to pare back on unnecessary features or cool ideas that might blow the project out of scope. Continually reinforce the concept of MVP — what is the minimum set of features that can accomplish their goal.
Once you’ve talked through all aspects of the project, organize your stories in a concise manner so that when the product is being developed you have a robust, easily searchable resource that contains every known aspect of the product.
Once you’ve organized everything you’ve collected, take time to review all that you’ve collected with the stakeholder and verify that what you’ve noted is the product they want to create. Continue to verify as you build, never letting more than a week or so go by without showing them your work.
Are you wanting to build something? I can help with that. I’m part of a dev shop that focuses on building awesome minimum viable products.
Gemini Development would love to talk about what you want to build.
You can also reach me on Twitter at @B_Puryear