The Miracle Of The Product Requirements Hierarchy
Product Requirements are a diverse collection of needs from a variety of sources both internal and external to an organization. They span from overarching strategies and goals to click-paths, font sizes, and color. Product Owners are responsible for managing these requirements through their lifecycle, collecting them from Users and Business Stakeholders, maintaining them through solution changes, prioritizing them, and tracing them to goals and strategies of the business. Understanding the Product Requirements Hierarchy allows Product Owners to easily fulfill these key tasks and communicate requirements effectively to various groups.
The miracle is how simple this can be. Product Requirements can easily get overwhelming when you begin to endlessly list them in a Product Requirements Document (PRD), or User Stories. It can become impossible to communicate specifications to Stakeholders for approvals, or to the Developers who are building the feature. But if you structure them well, following the guidance of the Product Requirements Hierarchy, you can create what some consider a miracle, an easy to read map that will guide Developers and Stakeholders to the promised land.
The Hierarchy, in all its simple glory
Business Requirements
These are the goals and strategies of the business. They are high level requirements representing the outcomes which the business is looking to achieve over a given timeframe. These requirements can over-arch multiple features or project initiatives.
Examples
- Increase user acquisition by 15% within 6 months of implementation.
- Reduce incorrectly processed Payments by 90% within 60 days of implementation.
User Requirements
These are the requirements which are determined by the needs of the User. In Agile Teams, User Requirements are written as User Stories. They detail what the User needs, in terms of functionality and features, to allow Business Requirements to be met. User Requirements are beneath Business Requirements in the Product Requirements Hierarchy and as such are intended to cumulatively drive towards the outcomes which the Business Requirements detail.
Examples
- Users are able to view Transaction history.
- Users can save multiple payment methods.
Solution Requirements
Also referred to as Acceptance Criteria in Agile Teams, these requirements illuminate specific details of a solution. They are intended to provide a sufficient level of detail to the Development Team to allow them to build the features or functionality described in the User Requirements. Solution Requirement are beneath User Requirements in the Product Requirements Hierarchy and fall into two general categories:
Functional
Requirements that describe how the solution is to operate. They can also detail the attributes of the elements that go into the solutions. They show the If-this-than-that logic of the process and how data or elements should appear and behave.
Examples
- The Customer Name will be a Hyperlink to the Customer Record.
- When a User clicks “Submit” the form is validated to ensure all Required fields are populated.
- The Accounts table is sorted by the created date, newest to oldest.
Nonfunctional
Requirements that describe qualities of the solution that are not seen in the functionality and are very often unknown to the Users. They are normally technical specifications that go along with the proper implementation of the technology being utilized.
Examples
- The feature must run identically in all popular web browsers.
- Addresses must be geocoded before being stored in the database.
- The Customer Name field has a character limit of 250 characters.
Transition Requirements
These requirements are conditions that must be met to transition the business, or the software, from the current state to the future state. These requirements are temporary and are no longer needed after a solution has been fully implemented.
Examples
- All existing data is migrated from the old database to the new database.
- The Payments Team is trained on the use of the new features.
This hierarchy sets a foundation for categorizing and communicating requirements. Users often do not need to see Nonfunctional Requirements and will be off-put when presented with them. Business Leaders often do not need to see the minutia of detail that Users require and may become disinterested when this is presented to them. Developers and the Product Team need to be aware of all requirements. Catering the communication of requirements to different audiences helps Product Owners to maximize the benefit they are delivering to each group and increase efficiencies. The Product Requirements Hierarchy makes this catering easy. The Product Owner just needs to filter their requirements on the tier which is most suited to their audience.
A good Product Owner will take this foundation and build upon it, customizing it to fit their organization and teams. They will use this system to organize their requirements, facilitate communication with different groups, and foster a deeper understanding of the solutions they are delivering. Doing so will allow them to be more impactful and to deliver more value to their Users.
Sources
A Guide to the Business Analysis Body of Knowledge
by International Institute of Business Analysis
