Requirements Gathering: Part 1 of How To Commission a Software Project
This requirements gathering article is part of the “How to Commission a Software Project” series.
Why Document Requirements?
It is absolutely necessary that your project start with requirements gathering. For the sake of this discussion, “gathering” includes editing, revising, editing, and revising. And editing.
I have a philosophy: requirements gathering is an art. It’s a deeply pragmatic, nerdy, and logical art. There’s a balance between a requirement that is atomic, portable, and testable and one whose inane specificity makes it a useless addition to the canon of documentation. There’s a balance between specs (written words, flowcharts, and wireframes) that convey concepts with clarity and specs that confuse everyone with polarity and vagueness.
Depending on your human resource ecosystem, there are many by-title candidates for this art. It could be a CTO/architect type if you’re a nimble startup (I expect you are). It could be a savvy product owner or business analyst. I love it when a great developer has the ability to de-abstract the appropriate concerns into a solid piece of documentation. We have several developers like that on our team, but what we find is that an iterative team approach to documenting requirements is the winner. Some may be astounded at the level of effort required to execute this process – my argument is “this is where slow becomes fast.” You can shortcut this process to get started quicker or save cash in the short term, but if you’re building a sustainable business or product (I hope that’s your plan) every day without a map puts you n² days further from sustainability.
Front-loading atomic requirements has another benefit. That is, your test plan basically writes itself. There’s a whole other article on testing but your QA specialists will now have a super-clear way to do release testing. Well-written requirements -> well-written tests -> well-tested code. And well tested code is a sustainable model.
The trick? Find someone who *loves* to do requirements the right way. Feed them, train them, feed them some more, and keep them.
Here are some practical steps to executing a successful requirements gathering round:
- Create a list of questions. Make them thoughtful, and practical. Start with the outcomes you’re hoping to achieve across the breadth of the entire piece of software and get granular. Additionally, save these questions somewhere safe because they have enormous value.
- Answer the questions. Get as many of the stakeholders involved as possible. Be careful, though: don’t round the corners or create a chaotic circus by trying to solve problems outside of scope.
- Repeat steps 1 and 2. Step 2 is going to create another set of questions. There’s always something new. As you revise be both empathetic and assertive about the original plan. You may repeat this 2-10 times depending on the complexity of your system.
- Document. Now that you’ve gotten answers to your questions, formalize them into a document that will be your original source of truth for this iteration, version, or sprint. Your organization may dictate a slightly more or less strict adherence to that truth, but make it sustainable and reasonable.
Interested in getting help with requirements gathering?