141

I've been tasked with developing requirements and specifications for a project our group is starting.

I realized that I don't know the difference; a Google search just confused me more -- it seems some people say that specifications are requirements, but at a lower level.

  • I agree with the high vote answers but I also think that the term specification is sometimes used as a more generic term in the software industry referring to any document describing a system or piece of software. As proof - google "requirements specification". When it is used that way it means a document that specifies something - ie: specifies the requirements for a piece of software. I won't judge if that is a correct usage of the word or not I just wanted to point out that specification doesn't always mean the same thing to everyone. – Shane Wealti Nov 23 '11 at 17:11
  • 1
    Yes, thats why people should say "Business requirements" and "Design specification"/"Technical specification" or something. The words on their own are pretty vague. – user606723 Nov 23 '11 at 18:38
  • Think of it like this (crudely speaking): Requirements = requirements doc and specifications = use-case/design docs – PhD Nov 23 '11 at 20:29
  • 4
    Why don't you ask the person(s) you are making these for? Only they can answer what is needed *in your specific case*. – Jaap Nov 23 '11 at 20:46
  • This article offers a thorough answer: http://www.ece.cmu.edu/~koopman/des_s99/requirements_specs/ – Julien-L Jul 30 '12 at 20:59
  • You're leaving off an important modifier on each term that IS ESSENTIAL in software development. There are no "requirements" - there ARE "Business or Functional Requirements." In waterfall projects they may be collected in a "Business Requirements Document" (BRD). These are behaviors the application must exhibit in order to support a business need - the WHAT. Likewise there are no "Specifications." There ARE "Technical Specifications" which detail exactly how the business requirements are to be achieved given specific technical constraints - hence "Technical Specifications" or the HOW. – Bryan 'BJ' Hoffpauir Jr. Aug 24 '15 at 06:02

13 Answers13

145

The sound-bite answer is that requirements are what your program should do, the specifications are how you plan to do it.

Another way to look at it is that the requirements represent the application from the perspective of the user, or the business as a whole. The specification represents the application from the perspective of the technical team. Specifications and requirements roughly communicate the same information, but to two completely different audiences.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
  • 4
    The *what/how* sound-bite is right, sort of; but confusing, because you can also look at the specification for a program as describing *what* it should do, and the design being *how* it should do it. Another is declarative pl (like prolog and SQL), in which you state the *what* not the *how*. One resolution is that they are a hierarchical of abstractions, with a parent stating *what* and children stating *how* (outside vs inside). I much prefer your second view, which is closer to "what it's *for*" vs. "what it *is*" i.e. benefit vs. feature. – 13ren Nov 29 '11 at 02:10
  • I would generally agree with you, but it's just 'another' opinion and not the correct answer. For example, take a look at the Wiki page for Requirements (http://en.wikipedia.org/wiki/Requirement). There are non-functional requirements, which by definition is for the technical team. Or Architectural and Constraints requirements, again technical but yet they don't call them 'specifications'. I think there is no correct answer and it will always be 'blurry' from company to company and developer to developer. – Jeach Nov 29 '11 at 17:54
  • 2
    Take a look at 'Adam Wuerl' answer bellow, I think that is the most accurate statement to the posted question. – Jeach Nov 29 '11 at 18:06
  • 1
    @Jeach: "bellow" [sic] is relative. It may be below this post at this moment, but it could move above, making your comment harder to understand – Bryan Oakley Nov 29 '11 at 18:39
  • 1
    Another perspective.. Wikipedia defines specs as a "set of requirements". This means that a spec can be just 1 requirement, s := {r1}. It seems more that colloquial "requirements" are "high-level" requirements, while "technical specs" are low-level requirements, a LOD thing. – Lance Feb 16 '15 at 20:28
  • I think Lance's explanation using set theory is helpful in a lot of situations. – Bryan 'BJ' Hoffpauir Jr. Apr 27 '16 at 22:33
42

Requirements document what is needed - they shouldn't specify the how, but the what.

Specifications document how to achieve the requirements - they should specify the how.

In many places these documents are not separate and are used interchangeably.

Oded
  • 53,326
  • 19
  • 166
  • 181
  • 2
    In my company we normally use the terms "requirements specification" for the what (you specify, write down the details, of what you what), and "design specification" for the how (you specify, write down the details, of how you plan to implement it). – Giorgio Nov 24 '11 at 10:13
25

I am a systems engineer in the aerospace field, where both terms are used extensively. The distinction is clear and not as complex as the others are making it.

A specification is a document that specifies a system or product, e.g. a prime-item development specification for an F-14. There are lots of sections/content in a spec: requirements, definitions, reference documents, glossary, verification information, etc.

A requirement is a single statement of something the product or system must do. A spec may have hundreds of requirements in it. Old school methodology says the requirement statement must use the word "shall", to separate requirements from statements of facts, or definitions. (Not sure if the new-fangled agile kids keep to all this or not; the fastidiousness has it's use but is a little fussy at times.)

So a spec is a document full of requirements, plus some other supporting and ancillary information.

Adam Wuerl
  • 348
  • 2
  • 5
  • 6
    Like I said in another comment, it's very blurry for everyone and probably always will be. But based on my own VERY extensive research on this exact subject, I would say your answer is the most accurate to my own findings/conclusions. – Jeach Nov 29 '11 at 18:04
  • 3
    Always helpful to get a real engineer's input. Thanks! – LeWoody Jun 05 '15 at 16:28
  • Alternatively, a Spec may have 0 requirements in it. Your example is a really good one for a very specific aeronautical engineering discipline. I'm not so sure it's generally applicable to the software development / programming domain. When most software is driven by business demands, it makes sense to start with a detailed Business Requirements Document before evaluating technical constraints and designing a solution. The Technical Specification would follow the BRD, documents constraints, and provide a detailed and specific approach to satisfying the business requirements in the BRD. – Bryan 'BJ' Hoffpauir Jr. Aug 24 '15 at 06:16
  • 1
    @Bryan'BJ'Hoffpauir I’m sure there are cases where documents are labeled specifications and have no requirements in them, but I would contend those that is a misuse of the term. A specification is a requirements document  —  end of story. It’s a widely accepted term of art across more fields that aerospace and defense and is unassailable within systems engineering, which is the discipline responsible for requirements and verification. Even in the case you describe the term applies: the BRD is a spec, the tech spec sounds like one too, just with different types of requirements. – Adam Wuerl Aug 25 '15 at 02:35
13

Requirements:

Determine the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders.

Specifications:

They provide a precise idea of the problem to be solved so that they can efficiently design the system and estimate the cost of design alternatives. They provide guidance to testers for verification (qualification) of each technical requirement.

The quote is from "Systems Engineering Fundamentals*".

Requirements are based on stakeholders needs, specifications are more an inside detailed and technical document. They are different, but they talk about the same thing.

* Defense Acquisition University Press, 2001. PDF version of the text.

Community
  • 1
talabes
  • 566
  • 3
  • 11
  • I think that it is important that your definition says that spec's define the PROBLEM. In that way, a PROBLEM spec is a requirement. A SOLUTION or DESIGN spec is part of design. – LeWoody Jun 05 '15 at 16:28
6

Requirements are the users' description of what the finished product, in their eyes, should do.

Specification is the technical description of the solution in general, covering the requirements and much more - e.g. cost, technicalities, problems, etc.

Therefore, one of the main points is that the Requirements must come first before a Specification can be written.

(Notice the terminology - product and solution - the same thing but from different perspectives...)

Arj
  • 539
  • 4
  • 10
  • 1
    I would swap the terms "product" and "solution", because a solution is usually in terms of the customer's problem, whereas a product is usually in terms of the seller (i.e. the technical implementer). A similar contrast is benefit/feature, where benefit is in customer terms (what use is it to them), and feature is in implementation terms (what actually *is* it, so we can make it). – 13ren Nov 29 '11 at 01:56
  • 1
    I see your point, but I think either angle adequately describes the situation. I took the view that a customer would be purchasing a product - as you do when you go to a shop. A software vendor would then be offering their solution to the underlying problem. If I was to go out shopping for a solution to my problem, I would probably think, "I need a product that does xyz", not, "I need a solution to my problem of abc". It's just a matter of preference I think. – Arj Nov 29 '11 at 10:33
  • interesting. I can see customers "seeking a product", when there is an established product category. But they seek that product because they've already worked out that it will solve their problem - i.e. they seek that product, not for its own sake, but as a solution. It's also true that a vendor does market their product as a "solution" - but that's because they're trying to communicate to customers (who seek solutions to their problems), and build something that will be wanted. Actually building the product (that is, the thing itself and its features independent of *why* they are needed) – 13ren Nov 30 '11 at 02:23
  • I can see customers "seeking a product", when there is an established product category - but they seek it as a solution to a problem/need they have. Vendors do market their products as "solutions" - because they're communicating to customers (who have problems requiring solutions). When building the product (the thing itself and its features, not *why* they are building them). One argument is that a problem can have very different solutions - but a product is one specific thing. – 13ren Nov 30 '11 at 02:33
  • [explaining why two comments]: SO comments are such a pain - hitting "return" will submit the comment, even though it's a multi-line textarea. And if you take more than 5 minutes to finish it after that, it won't accept the edit. So you have to submit it as a second comment. I was editing only to make it fit in the length. *sigh*. Next time I'll just it over spread two comments in the first place... [anyway, I agree that the point of view - buyer/vendor - is the main distinction. I am troubled by your terminology, but I think it deepens my understanding to try to articulate why.] – 13ren Nov 30 '11 at 02:37
  • Requirements are NOT the final product. – LeWoody Jun 05 '15 at 16:29
4

Perhaps the confusion is that I have heard specifications refer to Business Requirement Specification documents or IEEE standard SRS (Software Requirement Specification) documents.

IEEE standard SRS Template Example

I have also heard the term specifications refer more informally to Technical Specifications which explain design decisions and an implementation plan.

EDIT: I just noticed the link is incorrect... I will post a correct link shortly.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
4

Requirement - what the system or subsystem should (must) do.

Specification - What the component, subsystem or system IS.

This is critical in the medical device manufacturing industry since you must conduct Verification against your requirements (Inputs) to demonstrate that you have valid specifications (Outputs). Typical pitfalls in this industry is that companies (1) forget to define requirements (because they don't understand the difference between requirement versus spec); (2) Conduct Verification against only specifications and (3) Do not assure that Requirements are being translated accurately in to subassembly and component specifications.

Once this is all done, you are then required to Validate the User requirements for the product have been met.

Paul Bacchus
  • 41
  • 1
4

A specification is a requirement that passed feasibility and is ready to be implemented. It is a requirement that has evolved to the design phase.

In other words:

  • A requirement is behavior (or non-behavior) "as planned" or "as wished"
  • A specification is behavior (or non-behavior) "to be built" or "as built"

Example:

  • requirement: 1. user presses OK button 2. system prints invoice
  • specification: 1. user presses OK button 2. system prints invoice

As you can see, the content of both can be the same. The difference is that requirement is an analysis artifact. The specification is a design artifact.

In a final as-built documentation, you will typically find the word "specification", instead of "requirement", since the requirements have been converted to specifications.

Remark: example above contains design elements, because of design constraint.

fox.bailey
  • 41
  • 1
0

Requirements are what the application DOES

Specifcations are HOW the application does what it does.

They must be orthogonal !

Product managers write the requirements, head engineers write the specs.

jayunit100
  • 379
  • 2
  • 7
  • 2
    I'm not sure they are completely orthogonal, in practice at least. There is a lot of gray unfortunately. – LeWoody Jun 05 '15 at 16:31
  • They're only gray if you leave off the modifiers - Business Requirements, Functional Requirements, Non-Functional Requirements refer to a capability of the system (the WHAT it does). Technical Specifications are orthogonal to Business Requirements (the HOW it does it). – Bryan 'BJ' Hoffpauir Jr. Aug 24 '15 at 06:08
0

One way, maybe not the right way, to look at it:

Requirements are things (capabilities, features, behaviours, etc) that yield value to the user. Not concerned with internals; only the box's inputs and outputs (and maybe size, shape, and colour) are important here.

Specifications are things (capabilities, features, behaviours, etc) that enable that value for the user. Here the box internals are important, because along with the external interfaces and characteristics mentioned above they define the entire system.

berad
  • 11
  • 1
  • is this only your opinion or you can back it up somehow? – gnat Feb 18 '14 at 10:40
  • 2
    @gnat, I thought that was addressed in the opening line? Sure, this is from experience and I'm not claiming anything else -- from what I gather this is a somewhat subjective question on a rather subjective forum, and [this post](http://blog.stackoverflow.com/2010/09/good-subjective-bad-subjective/) suggests that questions should be as objective as possible but makes little mention of answers. But I have a one by my name and you have a whole lot more so I'm open to being educated :-) – berad Feb 19 '14 at 21:24
0

In a previous company creating commercial products we had the following distinction:

Requirements are what the system must do. They can be lower level, detailed requirements, and they can be functional or non functional.

Specifications are those things the system as-built actually does. E.g. you could have a requirement that states the system shall have behaviour X at –10°C. The actual specification of the system may be that the system does X at –5°C; this would be in the sheet sent to potential customers when they want to buy the system.

NB in this case the specification does not equal the requirement.

ardila
  • 103
  • 5
RoyD
  • 1
  • 1
0

In my research, I have found Specifications to be used for patents and House Construction (as part of a contract).

The definition of a requirement from Webster's Unabridged Dictionary (3rd New Int'l Ed.) is:

a) something that is wanted or needed: Necessity b) something called for or demanded: a requisite or essential condition: a required quality, course, or kind of training

I think the above shows them to be clearly different. I guess you could call spec's lower level requirements, but I think it is a perversion of the term requirement imho.

LeWoody
  • 252
  • 2
  • 11
-1

Think, you are going to build a high rise building on a land.

Now you need to consider the Requirements before you start, such as:

  1. Architecture or Design Engineer
  2. Soil Test Engineer
  3. Wind Pressure Test Team
  4. Demolisher
  5. Digger
  6. Man Power
  7. Water Supply
  8. Workers living/rest area
  9. Enough Fund
  10. Project Management
  11. Quality Management
  12. Security and Safety Control

Etc.

Now the above contents are part of Requirements to build a high rise building. From the above team, you get the technical outcome, which they hold as part of profession.

This is exactly, what is happening in software industry, a group of professional people involved to provide knowledge to build the technical specification, such as someone works on UI design, OO design, database design, graphic design, test case design, coding, integration, deployment team etc.

The above para will be part of handbook, that you can call Technical Specification.

Mohammed Hoq
  • 7
  • 1
  • 1
    I think you are confusing requirements with resources (http://en.wikipedia.org/wiki/Resource_%28project_management%29). – Jay Elston Nov 16 '12 at 01:11