How Product Requirements Define Your Project's Success

What are the requirements of a project?

Product requirements include different types of information about the project, including internal and external operations and features, as well as system behavior characteristics that make it useful.

Sometimes requirements change with time. Present requirements describe the current state of the system, while past requirements may include previous solutions that were later discarded. Near-future requirements include high-priority changes, long-term requirements are medium-priority, while hypothetical future requirements are low-priority.

Many types of information can be identified as requirements, and that makes my job harder. To make it the process of creating the SRS easier, I rely on several requirements informational models, including the one by Microsoft. It includes three levels of requirements that affect each other and help me organize project information in a system that fits the needs of business owners and software engineers.

Let me walk you through the three levels, explain their differences and different types of requirements they include. I hope that after my explanations, you won't fall for the first simple software requirements document template you find online and will be able to tell the difference between the low and high-quality SRS.

{{test-head="/custom-block-to-blog/three-page"}}

Level 1. Business Requirements

The first level of product requirements includes <medium>business requirements and business rules.<medium> The former include the goals you wish your company to achieve using the product under development. These may involve carving a market share, creating a new niche, reducing customer churn, or improving the customers' lifetime value.

{{quote-bl53-1="/custom-block-to-blog/one-page"}}

<medium>Business rules<medium> are not product requirements, per se. However, they define and constrain specific business processes. Business rules remain outside the system, but they dictate particular system features and capabilities. The rules may include corporate policies, industry standards, national or international legislation. For instance, since GDPR came into effect, all businesses providing services for EU citizens have to ensure their handling of customers' personal data complies with the new rules.

When I am done describing all business requirements and rules, I can create a scope and limitations file for later use to define the next level of requirements.

Level 2. User Requirements

Business requirements and rules define and influence user requirements. They answer the question, "What can a user do using the system?"

At this level, requirements include the goals different classes of users can achieve using the product, the tasks they can complete, or the problems the product can solve. User requirements are based on the value your project can bring to users. User stories, use cases, and scenarios are the best ways to document user requirements. They describe individual instances of interactions between users and the system that lead to the desired results.

A team of business analysts can create a list of user requirements. Still, the best way to come up with use cases is by interviewing stakeholders.

{{quote-bl53-2="/custom-block-to-blog/one-page"}}

While user requirements answer the WHAT,<medium>quality attributes<medium> describe HOW the system should perform. These are non-functional requirements that define system characteristics and performance. Quality attributes include parameters crucial for users, software developers, system administrators, and other stakeholders. They cover response time or speed, scalability, portability, reliability, security, usability, performance, and more.

User requirements document or specification (URD or URS) is usually the final product of my requirements research at this level.

Level 3. Functional Requirements

<medium>System requirements<medium> are the high-level product requirements that deal with multiple subsystems, including different software and hardware components. As a business analyst, I have to consider system requirements and formulate functional requirements for independent parts of the system and interfaces between them.

Functional requirements describe system responses to users' actions.

{{quote-bl53-3="/custom-block-to-blog/one-page"}}

This relationship between three requirements levels is vital to the project's success.

Functional requirements are short statements that the product development team will use to build the software. They should be clear and unambiguous. For instance, "Passengers should be able to choose the preferred seat on the flight when booking plane tickets."

System and functional requirements crystallize into <medium>features<medium>. Every feature meets the user's needs and fits business goals. Features can address multiple user and functional requirements. However, the desired list of features does not always align with the user's needs and requires extra work to ensure the bells and whistles do not replace vital features. Feature examples include browser bookmarks, automatic updates, or a spellchecker.

<medium>External interface requirements<medium> explain how the system should interface with users, hardware, or other software solutions. This set of requirements may include synchronization and third-party integration needs, as well as compatibility requirements. With the increasing number of products on the market, external interface requirements become more crucial to the project's success.

<medium>Constraints<medium> limit the developers' freedom during the design and development process. They may include preferred technologies or languages, legacy system limitations, architecture or documentation limitations, and more. Still, an unmanageable number of constraints can overcomplicate the development process, increase time and budget requirements, and make the whole project unviable.

After completing this level, business analysts like me can put together a system requirements specification that becomes the go-to document for project managers, software engineers, QA specialists, and other members of the development team as well as other stakeholders.

Alterntive take on how to write a product requirement

With all the types of requirements in mind, you can also consider the requirements model by IBM. It takes us through five steps:

‍

1. <medium>Needs<medium> describe the initial unmet stakeholder requirements.
2. <medium>Features<medium> include functional requirements to meet business needs.
3. <medium>Use cases<medium> explain possible uses of the product designed to meet the initial needs.
4. <medium>Scenarios<medium> include specific examples of product usage by end users.
5. <medium>Test cases<medium> allow the development team and business owners to verify that the initial needs were met.

While this model connects test cases to business needs, it does have drawbacks too. For example, following this approach, you would design features before considering possible use cases, which might lead to user dissatisfaction.

What makes PRD good?

I'd say a high-quality product requirement document (PRD) relies on a clear understanding of functional and non-functional requirements on all levels, starting from big-picture business goals to individual use cases that dictate the feature set.

You can find and download a product requirement document template. Still, it is not likely to encompass the complexity of your project. After all, business analysts spend days and weeks on research, analysis, and documentation to create a usable PRD that brings business owners and software engineers on the same page.

Additionally, we shouldn't forget about the differences between product and project requirements. The latter deal with resources and personnel training, documentation, and the transition between the current and future systems. Unlike a software product requirements document, project requirements specify development timeline, scope, and budget, as well as deploy requirements and post-launch support and maintenance.

Was this short foray into the world of product requirements useful for you? If so, stay tuned for the next installment in this series. We will discuss the business analyst's work process and explain how they turn business goals and problems into the system and feature requirements.