fbpx

Requirements vs. Specifications

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

I have been asked this question, or some variation of it, many times. This question is akin to asking, “What is the difference between a sentence and a book?” This does not seem to be a difficult question, but why would someone ask it? One should answer this question only after determining the questioner’s view of a book. Is a book referring to something like a textbook or a novel? Is it a set of records such as a ledger? Or is it used as a betting term “make book?” Most people would assume the first definition and answer the question accordingly. Assumptions cause problems and good requirement writers avoid assumptions.

Building a shared vocabulary

Answering the question about the difference between a requirement and a specification first requires a shared understanding of the terminology for different deliverables in the requirement development process. By clarifying some common terms, I believe I can provide answers to the original question as well as a number of related questions.

  • What is the difference between a Requirement and a Requirement Specification?
  • What is the difference between a Requirement Specification and a Design Specification?
  • What is the difference between a Requirement and an existing product’s Spec Sheet?

The first step to answering these questions is to define some terms and the way they are used in combination with each other.

First names and last names

First, let me introduce two terms: Document and Specification. The engineering world has used the term “Specification” for many decades. Among software organizations, the term has been replaced by “Document”. In the requirement world, these are virtually interchangeable and can often be found with identical first names. For example:

  • Requirement Document versus Requirement Specification
  • Design Document versus Design Specification

I recommend you don’t concern yourself with the last names. Either a “Document” or a “Specification” is a collection of information about a product. First names, on the other hand, relate to a point in the life-cycle.

Shared Vocabulary: Define requirements, design, as built diagram

Examples

The following examples are generalizations. There are organizations that always use the term “Document,” while others always use the term “Specification,” and others use both.

If developing an engineering product, you might have:

  • a Product Requirement Specification (PRS),
  • a Product Design Specification (PDS) or End-Item Spec (EIS), and
  • a Product Test Specification (PTS).

If developing software product, you might have:

  • a Product Requirement Document (PRD),
  • a Product Design Document (PDD), and
  • a Product Test Document (PTD).

It is not a good use of  our time to debate the correctness of an organization’s use of these names. It is important to know what to use for a particular project and move on.

Circling back...

I can now return to the original question, “What is the difference between a Requirement and a Specification?” using these terms. The term used below is “Specification,” but you can substitute “Document” if that is your terminology.

What's the difference between requirement & specification?

A requirement is a thing a product must do or a quality it must have. A requirement specification is a collection of all requirements that are to be imposed on the design and verification of the product. The specification also contains other related information necessary for the design, verification, and maintenance of the product. There are requirements for things other than products, such as services, but in this discussion we are restricting our answers to products.

What's the difference between requirement specification & design specification?

A requirement specification addresses the “what” and a design specification addresses the “how.” In a perfect world, the requirement specification precedes the design specification, and each is written by different people with different knowledge and viewpoints.

The requirement specification should state what the stakeholders of the product need in terms of features, functions, performance, constraints, and quality, written in terms of what the product must do or qualities it must have. These stakeholders, including customers, users, maintenance, tech support and others, have the knowledge to define these requirements. Sometimes these stakeholders state their requirements in terms of design, often unintentionally. There are requirement best practices for correcting this problem and for giving the designers the latitude to define the best solution.

The design specification reflects the design and provides directions to the builders and coders of the product. Through this document, designers communicate the design for the product to which the builders or coders must comply. The design specification should state how the design will meet the requirements. Design is not a one-to-one response to requirements. Design requires knowledge and integration of disciplines in most cases. Design will be concerned with trade-offs between different approaches to meet the requirements and concerning issues such as build or buy. The design specification will contain information about the product architecture and describe how each component will contribute to meeting the requirements.

What's the difference between a requirement & a spec sheet?

Commercial off-the-shelf (COTS) products have spec sheets that contain the major functions and features of each item in a product line. This enables a consumer, whether personal or business, to research the best fit for their requirements. You need requirements even if you are purchasing a COTS product. The number of requirements is generally much smaller for a COTS product than for a new product design. For a COTS product, you are restricted to what is commercially available for the particular type product that you have in mind.

The examples below describe personal decisions, but the same situation exists when you are buying COTS items for commercial reasons.

Example 1 – You need a new refrigerator

You will look at the specs for different refrigerators that can fit into your available space, have the features that are important to you, and are within your price range. These are your requirements, and you are looking to see who has built something that meets your requirements. Manufacturers know that there are certain refrigerator requirements of concern to any and all customers – from price, to dimensions, to electrical consumption, to exterior finish and interior configuration. They create a spec sheet for each of their products so that you can shop for the model that best meets your requirements. Everything you care about is probably on that spec sheet, with some exceptions, and there will be things there that are of no concern to you. There may be items on the spec sheet you had not considered, but upon seeing them listed, you realize you really do care (such as having a water dispenser in the door or not). The manufacturer’s spec sheet helps you think of those things you forgot to specify.

Example 2 – You are shopping for a new laptop

Prime requirements might be weight, size of memory and speed. Computer manufacturers create spec sheets to cover almost all customer concerns in order to make shopping for the right model easier. You have probably used on-line programs that let you compare items.

If you’re looking for help with project requirements or would like to explore training options to help your teams improve their requirements processes, talk to us! We’re here to help. 

More To Explore

Three BA Mistakes to Avoid

We’ve all heard the quote, “What we have here is a failure to communicate.” Failure to communicate is the bane of the Business Analyst (BA). The BA has the responsibility

Marketing Automation or CRM – Which do I need?

Here at Blue Fish, we design and implement commerce-based solutions across a variety of industries and company sizes. In nearly all those solutions, our clients also have varying needs to