How to Rock Massive Requirements Gathering

Heavy Lifting

Most of time, the workload on business analyst is pretty reasonable; however, sometimes a massive amount of requirements must be gathered in a short amount of time. I've helped many companies out of an audit, and it's never fun: massive, immediate remediation is typically the prime directive. And as you know, nothing starts without requirements; so all eyes are initially on the business analysts. In these circumstances, you need a lot more than two ears listening and two hands typing, so the tendency is to throw more business analysts into the mix. As you can imagine, under these conditions, there are more ways to fail than succeed. To pull off an effort where multiple business analysts are writing the same requirements document, you need to follow the right strategy.

Get It Done Fast and Accurate

To understand the most effective way to write requirements as a group, let's examine how a requirements document is organized. Usually, there's an executive summary that explains the background, business case, and other contextual information like the leadership and stakeholders. Then you'll typically break down the functional requirements into a few modules, and follow them by a few non-functional requirements (performance, usability, etc.). This is the bulk of the document. Finally, you'll tie the document off with a glossary, version control, and other supporting sections.

To structure the group requirements gathering effort, you should first agree on one lead business analyst. The lead is ultimately accountable for the entire document, unifies the fragments into a cohesive whole, and keeps the process moving by making decisions when the group can't come to consensus. The next thing to do is assign one editor. The editor is responsible for making sure there are no spelling or grammar mistakes, and unifying the style and voice of the document. Finally, the heavy lifting of the content should be divided among the available business analysts by module.

The key to execution is in the ground rules: the most important of which is to focus on collecting content only, and let the editor worry about the polish. What typically bogs down an effort like this are endless reviews on details that frankly don't matter. The group instinctively feels like they need to collectively decide on every aspect of the document, and that's nowhere near true. The lead should own the content of everything that's not a functional or non-functional requirement (background, business case, glossary, etc.). Each business analyst should own the content of his or her assigned module(s)–only the content. And the editor is responsible for bringing everything together, under the guidance of the lead business analyst. Reviews are done purely for the purposes of sharing content. Do not fall into the trap of endless revisions because someone has a different idea on how something should be worded–that's the editor's job.

Conclusion

Writing requirements as a group in a short amount of time under an immense amount of pressure is nerve-racking, but with a good strategy you can get through it quickly, accurately, and somewhat painlessly. When thrown under these conditions, assign a lead, an editor, and a business analyst to one or more requirement modules. Then attack content–and content only–in a fast and furious way, leaving the fine-tuning for the editor. Heavy lifting is required from time to time, but there's no need to break your back in the process.