Are Specifications Different From Requirements?


You might hear the entire package of deliverables that a business analyst is expected to deliver to be called “requirements”. However, I believe there are two distinct types of information that the business analyst is primarily responsible for delivering: requirements and specifications. And yes, while related, these are very different things.

If requirements are “the what”, then specifications are “the how”.

(Let me pause for just a moment to call out that there is a very important step between requirements and specifications, and that is Solution Analysis. But assuming you’ve completed that step…)

Specifications (or Specs) are where you document the details of how each requirement is being fulfilled. This is where all the detail goes in order for:

  • Your client to confirm and approve what they want you to deliver
  • Your developer (if you’re building software) to know what exactly to build
  • Your tester to verify that everything is working as expected

Building on the example I mentioned when defining requirements, if the requirement is “the user must be able to communicate confirmation of a reservation with the customer”, then the specifications will now call out exactly how the confirmation will be delivered. If it is an email, what information goes in the subject and body; what email address will this be sent from; is the recipient able to reply to the email address. If it is a text message, what is the content of the text message; what happens if the user doesn’t have a cell phone number in their profile.

And specifications are not just for building or modifying software.

If you’re modifying a business process, your specifications will include details about who performs what tasks and when. If you’re defining reporting needs, your specs will include details about the data needed, how it’s displayed and who should receive it.

There will be plenty of posts discussing the kinds of information that you should consider including in your specs and how to organize it. But the key point is that this is where all the nitty gritty goes.

Do you distinguish requirements from specifications? Or do you consider them all requirements?

© 2010-2011 Real World BA, LLC. All rights reserved.
6 Responses to Are Specifications Different From Requirements?
  1. Tony Higgins
    November 2, 2010 | 1:29 pm

    Alot of my background is from military software projects where a ‘specification’ is really just the container (typically a document) that holds the set of requirements. I agree the requirements express the “what”, but for me the specification is just the place you go to find the requirements documented. Here is a link to a standard that describes this If you go look at the IIBA’s Body of Knowledge and search for ‘specification’, as you go through the instances of the word in the document I think you’ll find it’s consistent with this. With respect to the “what”, for me I usually attribute that word to the solution “Design”. I realize not everybody uses the terms this way – but I do 🙂

    • Real World BA
      November 2, 2010 | 2:25 pm

      Hi Tony! Thanks so much for your comments and getting the discussion going!

      I haven’t personally worked on military software projects, but I took a quick look at the standards you referenced above and I can definitely appreciate the formality and structure.

      For me I think it boils down to distinguishing requirements and specifications because they occur in two separate “steps” with a solution analysis step in between. And the document that captures each of these are the Business Requirement Document (BRD) and the Functional Specification Document (FSD), although I have also worked in places where this is referred to as the Requirements Specification Document (RSD) which to me still implies that it is the details for the requirements.

      I’ve also seen this go straight to “specifications” for projects where you already know the solution so you are working out the details as you learn the requirements.

      So in your experience, do you produce a single document with requirements and specifications layered in as you have the solution design? Or are there still two different documents?

      This is part of why business analysis is still such an “art” – as we adapt our thoughts and ideals, along with what the industry is formalizing, to be effective within our respective organizations.

      Anyone else do this differently? Do you have separate documents for requirements and specifications?

  2. Chris
    November 3, 2010 | 1:15 pm

    As an analyst embedded in Technology my requirements always contain specifications. While I work as a business analyst, with the business customer to define their requirements, its always with an eye on how we (Technology) can provide a solution. My documentation of business requirements combined with solutions (documented as part of the requirements) are delivered to the developers for design.

    • Real World BA
      November 3, 2010 | 11:06 pm

      Hi Chris! Welcome to the discussion!

      I used to think that way, but learned a couple things about that process that, for me, led to distinctly separate these:

      1) I ended up too focused on thinking about the solution which sometimes caused me to lose focus on digging to the true underlying problem.

      2) I felt like the responsibility was all on me to think of the solution, instead of working with all the resources available to me to find multiple solutions.

      Have you encountered either of these two problems? I agree that I always sort of have in the back of my mind how I “think” we might solve the need, but I like to keep my stakeholders focused on their business first. How do you keep them focused on the business so that you and the IT team can focus on the solution?

      • Chris
        November 4, 2010 | 10:58 am

        You are correct, it is easy to loose sight of the objective to understand the need. I just came from a meeting with a stakeholder who requested an enhancement to an application that searches a db for the location of specific information on a library of CDs. It was very easy to imagine the solution. I almost failed to question why he couldn’t get the information from other systems….that question let me explore their business process further. If I had stopped, I would have been an “order taker” rather than an analyst. Each request, regardless of how small, may contain a nugget of opportunity to make our customer’s jobs easier.

        • Real World BA
          November 4, 2010 | 8:12 pm

          Great example, Chris! Looks like you’re keeping a great balance of staying focused on the requirements even though you’re thinking about the possible solution. 🙂

Leave a Reply

Wanting to leave an <em>phasis on your comment?

CommentLuv badge
Trackback URL