How can I help the business stakeholders organize their requirements?
I've got a sea of notes generated from gathering requirements, but now it's time to put this into some kind of order. How can I help the business stakeholders organize their requirements?
There's more than one way to organize the requirements, so before you settle on a process, allow time to weigh your options. You may find that the right choice saves time and makes the requirements easier for everyone to understand. As you think about the best way to manage the requirements, be sure to consider the project methodology, the business analysts, and the subject-matter experts who'll be available to help, as well as the business problem and solution before you. Eventually,
you'll want to organize the requirements by category and priority. The actual technique you choose is secondary; the important thing is to get the requirements organized so that the project can move forward efficiently, with minimal friction and strain.
Consider some of the following approaches to organizing requirements:
A traditional, waterfall approach will require that you gather abundant details about every area of the requirements before the project begins. So you may want to assign more people to elicit and document the requirements in the early project phases, and reduce their numbers as the work tapers off. With the waterfall approach, you'll want to categorize the requirements in a way that makes it easy to divide the work—assigning one set (or category) of requirements to Analyst A, while Analyst B works on a different set simultaneously. Be careful not to overwhelm your subject matter experts. If they find themselves stretched too thin by working on multiple categories, they'll essentially be competing for time with the business—a definite no-no that will almost certainly slow the project's forward momentum.
An iterative approach might require you to address various aspects of the problem or solution at different times. For an iterative requirements effort, you'll want to categorize the requirements in a way that helps you get at the right level of details, for the right aspect of the solution, at the right time.
A problem and its solution will very often impact different parts of the business and different stakeholders. When this happens, consider categorizing the requirements by their business functionality. For example, if one functional business area will work with the user interface, and another will work with data and reporting, consider categorizing the requirements by business function.
Requirements are often organized by asking whether they are functional or nonfunctional. It's a reasonable approach, because it helps ensure that you cover all the bases. But let's not be too simplistic—remember that the nonfunctional requirements are inextricably linked to their functional counterparts, so it's unlikely that you'll find any single person focused entirely on functional requirements, and someone working exclusively with nonfunctional requirements.
It's also very important to organize the requirements by priority. Despite our best intentions, few projects have the luxury of addressing every last requirement. For example, overruns in the early phases of a project will often cause time (or funds) to run out before the later requirements can be fully addressed. Therefore, make sure the business stakeholders prioritize the requirements. Then, if scope cuts must be made, it will go easier for the stakeholders if you've identified the requirements that have lower priority.