What is the difference between requirements and specifications?

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

    Yes, thats why people should say "Business requirements" and "Design specification"/"Technical specification" or something. The words on their own are pretty vague.

    Think of it like this (crudely speaking): Requirements = requirements doc and specifications = use-case/design docs

    Why don't you ask the person(s) you are making these for? Only they can answer what is needed *in your specific case*.

    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.

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

    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.

    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.

    Take a look at 'Adam Wuerl' answer bellow, I think that is the most accurate statement to the posted question.

    @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

    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.

    I think Lance's explanation using set theory is helpful in a lot of situations.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM