by Ivy Hooks
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.
Answering the question about the difference between a requirement and a specification first requires that the person asking the question and the person answering the question share a common 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, which have all been restated from the original and seem similar, but are actually very different:
The first step to answering these questions is to define some terms and the way they are used in combination with each other.
First, let me introduce two “last names”: Document and Specification. The engineering world has used the term “Specification” for many decades combined with a set of first names related to the product life-cycle. 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:
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 at various times in the product life-cycle. First names, on the other hand, relate to a point in the life-cycle.
|First Names||Information which describes a product’s…|
|Requirement||Functions, performance, qualities, and constraints – the “what” to guide the design|
|Design or End-item||Architecture and the technical “how” to meet the requirements and to guide the builders or coders|
|As-Built||Final delivered configuration and technical information|
|Test or Verification||Proof that it meets the requirements|
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
If developing software product, you might have
The purpose of a PRS is the same as that of a PRD; of a PDS as a PDD, and of a PTS as a PTD. The purpose of the specification and the document is the same if their first name is identical. However, the content and organization will vary based on the type of product (i.e. system versus software and hardware versus software).
It is not a good use of your time to debate the correctness or incorrectness of an organization’s use of these “last names”. It is important to know what to use for a particular project and move on.
I can now restate 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.
1. What is the difference between a Requirement and a Requirement Specification?
A Requirement is a statement of one thing a product must do or a quality it must have. A Requirement Specification is a collection of the set 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.
2. What is the difference between a Requirement Specification and a 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.
Stakeholders communicate the requirements that the product must be designed to meet through the set of requirements in the Requirement Specification. This provides guidance to the design team.
The Requirement Specification should state what the various 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 (sometimes known as the End-Item Spec) 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 discipline 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.
3. What is the difference between a Requirement and an existing product’s 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 illustrations below describe personal decisions, but the same situation exists when you are buying COTS items for commercial reasons, including COTS components that you will use in a product that you are building.
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.
Do you have a “requirement” question you would like the Requirements Experts team to address? If so, please visit www.reqexperts.com and contact us.
The former CEO and a founder of Requirements Experts, Ivy Hooks is an internationally recognized expert on the subjects of requirements engineering and requirement management. Ivy has published papers in a number of journals and proceedings and has spoken to diverse audiences worldwide. She has also provided training and consulting to multiple government and commercial organizations for over 20 years.
Ivy’s NASA career took her from the Apollo program through the Space Shuttle Program. She was a member of the initial Shuttle design team and managed the development of the separation systems and the verification of the flight software.
You might also find interesting: