Defining your Requirements Structure

The first time I mentioned developing a requirements structure for one of my consulting clients, they looked at me in puzzlement. According to the BABOK® Guide, a requirements structure defines the organized structure for all of the project requirements and the documented relationships between these requirements. To be more specific, the requirements structure defines the scope of each specific model or set of requirements and provides a location where each specific requirement can be found.  Perhaps you typically use a set of three requirements documents on your projects – the high-level business requirements, the more detailed user requirements and a third document defining the more technical system-focused requirements.  What is in those documents and how they relate to one another is part of your requirements structure.

Be aware that your requirements structure is not the same thing as your requirements traceability.  Traceability is where you link related requirements and their derivations. In contrast, your requirements structure tells you where the specific requirements for the project can be found.  The two are related aspects of developing requirements but they are not the same thing.

Many years ago, I was structuring a set of requirements documents for an organization’s IT projects and building templates for each of those documents so that project teams would use them consistently across the organization. On first glance, this requirements-focused consulting assignment seemed very straightforward. Then I started asking questions about the projects and the current processes in place for developing requirements.

The organization had projects in all sizes. They had extra small maintenance and support efforts lasting a few weeks and medium size software development projects lasting about six months or so. They were doing agile development of their customer-facing web sites in six-week sprints. They had small projects that were non-critical and mission critical complex projects lasting for a year or more and costing millions of dollars. In this organization with such a breadth of project types and sizes, it became obvious very quickly that the project teams would have to tailor their requirements document sets for their project types and then scale the documents for the size of their efforts. That would be the resulting, flexible requirements structure that they would use during requirements development.

The end result of these efforts was a set of requirements documents that could be tailored and scaled to fit these myriad projects and a guidance document providing guidelines for scaling and tailoring the requirements documents based upon project type, complexity, cost, and associated risks. This generic document set and guidance document became part of the requirements development process, and part of the company’s Organizational Process Assets.  Thus, a requirements structure was born!

When building your requirements structure for your projects, remember that there are a number of stakeholders involved with defining your requirements structure.  Be sure to get everyone involved so your requirements structure meets the needs of the many versus the needs of the few.

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 as a business analyst 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 structuring!

Susan Weese