Part 1 of the Product Requirements in a Nutshell Series

Despite all of the hoopla around new Agile software development methodologies, the vast majority of high tech companies (web-based software, packaged software, hardware/software systems) still use the traditional development methods that have been around for decades. In this traditional development world, there are usually the Requirements docs and Specification (Spec) docs. Depending on your industry and company, these two terms may mean the same thing and are interchangeable, or they may refer to entirely different pieces of the process.

This article is the first in the “Product Requirements in a Nutshell” Series and discusses some of the common variations in the documents names and purposes. For additional reading, see Part 2 – 4 Common Requirements Issues.

Why are Requirements Needed?

There are two major purposes of the requirements process, regardless if you use traditional or iterative development methodologies. The first is as a Bridge between the market problem to be solved and the envisioned solution. The market problem is fixed and enduring but as new technology comes to be, new solutions emerge to solve the problem in a (hopefully) better way. This is the concept behind innovation.

For example, people have always had a need to organize and manage their finances. For many years, checkbooks and ledgers were used manually to accomplish this. Along comes Intuit with Quicken to help people use the computer to achieve the same result but with less effort. In the future, the problem may be solved by using our mobile phones as wallets to an online database that is always up to date. The basic problem remains the same but many solutions may exist and the Requirements bridge to one possible solution.

The second purpose of the requirements process is for Communication. There is a need to align several groups and many people about what you’re trying to accomplish, for whom, and in what envisioned manner. The requirements process provides the discussions and artifacts to enable the communication to the folks who need to provide pieces of the solution. It also introduces a common set of terminology and templates to facilitate the conversations and to make sure a necessary level of due diligence is happening before committing to a potentially major undertaking.

A Discussion of Document Types

In some environments, the Requirements are generally targeted at what is needed in the market and is being requested, while the Spec describes what will get built. The originator of the Requirements is usually the “business owner” or “customer” while the originator of the Specs is the technical team. There are different levels of Specs with varying degrees of abstraction and implementation details. The Specs can also contain Project information, such as which resources are required, major milestones and development schedule and cost. In other environments, the Product Spec is the sole document driven from the “business owner” to a deep level of detail and the development team signs off on it.

There is little standardization across the high tech industry as to what the actual methods are for documenting the Requirements and Specs. Some use document templates, some spreadsheets, others Wikis, and some software requirements tools. Despite this variety, there is some generally accepted framework, even if there is little agreement on the form or actual content of each. For the sake of illustration, let’s assume an organization is using three documents as they move through their requirements process and we’ll give them fictitious titles for now.

Assume the first doc is called the “MARKET & BUSINESS DRIVERS” and is developed by the product manager or product marketing manager. Its purpose is to provide the business-level view as to why this product or set of functionality is desired. It describes the need or opportunity in the market place, the target customers, attractiveness of the market, competitive landscape, scenarios and features that could make an effective solution and the key value proposition and differentiators. Additionally, it can be part of a bigger business plan suite that also describes the business model, the go-to-market strategy, the alignment to company and product strategy and financial projections.

Assume the next document is called “USING THE PRODUCT” and is developed by the product manager but with possible help from others such as a product designer, business analyst, or technical staff. Its purpose is to describe the product-level view of what a user could accomplish with it. It expands the features into more detail to define the entire solution. It identifies the users of the product, the activities they would want to perform, external systems connections, how well the product needs to perform, and what constraints are placed on it. It could also contain UI mockups, personas, use cases, process flows, data flows and any myriad level of technical detail to describe the desired results. The key perspective of this document is that is describes the product from the user’s point of view.

Assume the final doc is called “WHAT WE NEED TO BUILD” and is developed by a member(s) of the technical team - program manager, technical lead, business analyst, architect or others. Its purpose is to describe the specific functionality the product will provide in response to user and external system interactions. It tells the developers (and testers) what capabilities they need to build and deliver from the system’s perspective, and is in effect a translation of the user description into a technical description. It can contain further iteration on use cases, a list of Functional Requirements (responses to user/system actions) and Non-Functional Requirements (qualities and constraints) of the system. As a checkpoint, it also provides feedback on how the requested functionality was understood and defines a specific solution to be able to estimate the effort required to build it.

A Map of Different Document Methods

It’s possible to map our fictitious document names to commonly used names that are used in different situations. The table below gives some common mappings to our three separations. Your organization may look like one of these or any number of other permutations can occur.

 

	“MARKET & BUSINESS DRIVERS”	“USING THE PRODUCT”	“WHAT WE NEED TO BUILD”
Example 1	Market Requirements Doc (MRD)	Product Requirements Doc (PRD)	Functional Spec Doc (FSD)
Example 2	MRD or PRD (Single Combined Doc)		FSD
Example 3	- or MRD	MRD or PRD
Example 4	-	-	FSD
Example 5	Business Requirements Doc (BRD)	User or Functional Requirements Doc (UCD or FRD)	System Requirements Doc (SRD)
Example 6	- or BRD or Customer Requirements Doc (CRD)	System Requirements Spec (SRS)

Examples of Requirements documents

Note that in some implementations, a single doc is doing double duty or the discussion is missing entirely.

Example 1, which mirrors our illustration, is fairly common in commercial products. Here we arrive at some fairly common names: Market Requirements Document (MRD), Product Requirements Document (PRD) and Functional Spec Document (FSD).

Example 2 (a MRD or PRD) is also common, especially for new products into existing markets and major updates to existing products.

Example 3 provides the case where the MRD or PRD is the sole document without any FSD, and where a separate MRD describing the market opportunity may or may not exist.

Example 4 (FSD only) is common in small technology-driven organizations, and it may even be called a PRD but developed primarily by the technical staff.

Example 5 is an example of different sets of terminology that can exist in an IT-oriented or government environment where the actual “customer” may be an internal group. These include the Business Requirements Doc (BRD), Functional Requirements Doc (FRD) and System Requirements Doc (SRD).

Example 6 is similar but has a hybrid combined System Requirements Spec (SRS) that has roots in custom development projects and is a format promoted by IEEE for software requirements.

Summary

The main point to take away here is that it’s not that important what the actual document titles are, but that the intended purpose and information is conveyed in some manner so the technical team understands the intended solution to a market problem that is being solved with what objectives. Depending on the project, there may even be a different set of docs required within a company. Smaller project and updates may use a limited set, while a larger, riskier project may require more documentation.

For additional reading on this topic check out:

---

Related Articles: