Organizing Project Requirements

We all know (or at least hope!) that our project requirements are not meant be a jumble of information. Best practices and common sense tell us that our project’s requirements should be structured and organized into a set of information that is complete, comprehensive, consistent, and understandable to our stakeholders. I already talked about structuring requirements in a previous post, so now let’s have a closer look at the ways we might choose to organize our project requirements within that requirements structure we have built.

The BABOK® Guide defines how you go about organizing your project requirements into a requirements structure that you use to keep everything where and as it should be in the Requirements Analysis knowledge area.  As you think about the many possible ways to organize your requirements, remember that you are trying to describe the solution scope fully and from all stakeholder perspectives. I always think of the solution scope as the frame for the more detailed picture that you are painting with your well-organized and understandable project requirements.

Whenever I don’t know what to choose or where to start, I take a look at the processes to see what needs to happen and “who does what when”. Process models are very common-sense, defining a series of repeatable activities performed by a particular user role in an organization. Remember that processes typically involve both people and systems. Processes describe who does something and when that something must be done.

There are several techniques that you may choose to apply when deciding how to organize your project requirements. Here is a quick list of the techniques with a brief description for each item.

• Functional decomposition breaks down or decomposes the solution scope into its component parts. You can then create a model of what needs to be done to deliver all or part of the solution.
• Organization modeling describes the organizational units, the stakeholders and the relationships between them and allows you  to organize your project requirements based upon the needs of each stakeholder group.
• Data flow diagrams allow you to organize your requirements based upon how information or data flows through the system.
• Data models organize requirements by describing the concepts and relationships between the concepts that are relevant to the defined solution scope.
• Process models organize your project requirements using a hierarchy of processes and sub-processes and addressing those processes from start to finish.
• Scenarios and use cases organize your project requirements using events and how the solution will respond to the associated triggers.
• Scope models organize project requirements based on the solution components that they are related to.  Solution components are parts of a solution spanning the enterprise architecture of the organization, including business processes, software applications or hardware.
• User stories organize requirements by the stakeholder objectives that the solution will support.

Once you have selected and applied one or more of these techniques as part of your requirements organization efforts, you are well on your way to building a well-structured set of project requirements.  Check out Learning Tree’s introductory business analysis course if you are looking for a great way to get started or fine tune your skills organizing and structuring the requirements on your projects.  This course allows you to practice and fine tune your skills in writing and modeling the requirements for your projects and their proposed solutions.

Happy requirements organizing!

Susan Weese