Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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
3  
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: ece.cmu.edu/~koopman/des_s99/requirements_specs –  Julien-L Jul 30 '12 at 20:59

12 Answers 12

up vote 92 down vote accepted

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.

share|improve this answer
1  
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 2: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 (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
1  
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

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.

share|improve this answer
1  
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

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.

share|improve this answer

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.

share|improve this answer

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...)

share|improve this answer
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 1: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. –  YouShallNotPass 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 2: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 2: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 2:37

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.

share|improve this answer
2  
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

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.

share|improve this answer

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.

share|improve this answer
    
I think you are confusing requirements with resources (en.wikipedia.org/wiki/Resource_%28project_management%29). –  Jay Elston Nov 16 '12 at 1:11

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
is this only your opinion or you can back it up somehow? –  gnat Feb 18 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 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 at 21:24

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

Requirements were as described earlier: what the system must do. There 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 the system shall have behaviour x ..... at -10C. The actual specification of the system may be the system does x... at -5C and this would be in the sheet send to potential customers when they want to buy the system.
NB in this case the specification does not equal the requirement.

share|improve this answer

protected by Bart van Ingen Schenau Apr 29 at 14:48

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?