Let's consider requirements management for product managers and software development teams. Typically, a product manager owns the requirements management process. You are responsible for helping the team define product requirements and manage the changes throughout development. When you learn how to effectively manage requirements, you can better validate customer needs and build features that customers find lovable.
Jump ahead to any section:
What is a requirement?
At a basic level, a requirement is something that is needed or wanted. Software products can be comprised of hundreds — even thousands — of requirements. But even a single feature can have multiple requirements. In this case, you can think of the requirements as the components that need to be implemented in order to complete the feature.
No matter what you are building, requirements should be:
Necessary: Essential to achieving business and product goals.
Specific: Detailed with traceable roots to their origin and purpose.
Understandable: Clearly written and unambiguous.
Accurate: Adequately detailed with information about the end-user's challenge or need.
Feasible: Researched and proven to be both useful and attainable.
Testable: Able to be completed or approved through user acceptance testing or other criteria.
Top
Different types of requirements
Product teams may manage multiple types of requirements that are important to different stakeholders. It is key to have a shared understanding of the different types of requirements and designate the right people to collaborate on them. That way, you can align on the most business-critical requirements and gain consistency in how you define and prioritize them.
Most product managers define different types of requirements, so it can be helpful to group requirements by category: business requirements, user requirements, and systems requirements. Let's take a closer look at the three types:
Business requirements
Business requirements describe objectives from stakeholders — such as leadership, internal business analysts, and initiative owners — that are necessary for the company and its business units to succeed. They bring context to the company's top-level goals and initiatives.
You can think of these as things that the business needs to do to satisfy both internal and external customers, not something that the product necessarily needs to do. Although, it is worth noting that there may be overlaps.
Business goal: Expand into global markets this year
Example requirements:
Identify international markets to target
Develop multicultural buyer personas
Create a website localization strategy
Translate the application into multiple languages
The company-level goals and their business requirements will impact the goals and initiatives that you set at the product level. Of course, product goals will be specific to the product and its users, but should also align with one or more business goal.
User requirements
Moving down to the product level is where you find user requirements. These requirements define what a user needs or how they will interact with a given product or feature. User requirements often describe a customer pain point or challenge as well as an action they want to accomplish and how the product should serve them.
Recall the example above, with the business requirement of translating the application into multiple languages. When defining user requirements, you need to dig into the details of the user experience. How will users select their preferred language? Can account admins set default languages for different user logins? Will the application provide users with a way to translate text from colleagues who use a different language? These are the types of considerations you may need to make.
User requirements can be defined at the product level as well as the feature level. In the example below, you can see a single feature with its associated requirements.
You can think of user requirements as the "why" and "what" of features from a user's perspective. Then, you can share these details with the engineering team so they can focus on the "how" of building each feature.
Systems requirements
Systems requirements support the product from a technical perspective. These requirements outline what the technology can do (functional requirements) and how well it performs those functions (non-functional requirements). Non-functional requirements often focus on security, performance, and reliability issues.
The engineering team typically owns systems requirements. For instance, if translating an application into multiple languages, engineers may have to select third-party software that the app will rely on to power the translations. And they will have to determine how frequently to push updates or how the system should handle translation errors.
The visual below summarizes the three types of requirements:
Top
Who is responsible for requirements management?
Depending on the type of requirement, your organization may have various owners and stakeholders. Typically, a product manager is responsible for the requirements management process as it relates to the product and its features.
A big part of your role is collecting ideas and feedback from customers, internal teams, and other stakeholders. You have to evaluate whether new ideas align with the overall business and product strategy and then translate the ideas into features and requirements.
You will work with cross-functional teams to refine requirements. It may seem obvious that engineering has a big role in requirements management. Other teams do too — for example, you will likely work with the finance team or business operations team to ensure you can measure and report on business requirements.
To prevent one set of requirements from overriding another, constant communication among stakeholders is critical. As the product manager, you are at the center — overseeing requirements that impact the business, your customers, the product, and the product team.
Top
Overview of the requirements management process
Developing a process for managing requirements creates consistency and transparency between product, engineering, and other stakeholders. Changes to requirements should be broadly shared throughout the lifecycle of the product.
Requirements management does not end with a product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the product planning phases for the next generation or release. Thus the process begins again.
The requirements management process typically involves the following phases:
Collection: Gathering feedback and needs from customers and internal teams.
Analysis: Determining whether proposed features and requirements align with the company or product vision.
Definition: Documenting requirements from the user perspective and detailing functional or technical requirements.
Prioritization: Planning upcoming releases or sprints and the features and requirements that will be included.
Validation and maintenance: Creating a definition of "complete" and planning ongoing enhancements.
A company's product development methodology can determine how and when requirements move through the requirements management process. For example, if you follow a waterfall model, your requirements management process may be linear — one phase closes out before the next begins. In an agile environment, you may have many requirements in flight at varying stages as you prioritize upcoming work as part of sprint planning.
No matter the methodology, an effective requirements management process requires clear communication and documentation. This will help you ensure that what you build brings value — to your customers and your business.
