Why Defining Requirements and Specifications is Important
When it comes to requirements and specifications, I have been asked what the difference is, 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 writing good requirements is rooted in eliminating 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. Clarifying a few common terms can provide answers to the original question, as well as answer 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. If you’re not 100% sure where to start, our Product Management services are designed to help organizations prioritize the most important features to optimize value in software solutions.
Document and Specification - It's All in the Name
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.
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.
When 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).
When 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. What IS important however, is to know what to use for a particular project and move on.
And if you’re looking for insights and examples of how to best communicate requirements visually, we have pioneered Requirements Modeling Language specifically for this purpose!
What is the Difference Between a Requirement and a Specification?
NOTE: The term used below is “Specification,” but you can substitute “Document” if that is your terminology.
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 is the Difference Between Requirement Specification and 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 is the Difference Between a Requirement and 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 of 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, amount 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 our requirements training courses to help your teams improve their requirements processes, don’t hesitate to reach out! Our training classes allow businesses to leverage the same requirements training organizations like NASA, JPL, CalTech, and UCLA use to strengthen their teams!
