I'm looking for a tool which helps me keep the product backlog and the specification consistent.

Consider that I have specification from client. Based on the specification I create the user stories (the case can be in opposite way too). Right now it looks like everything works great. But it is important to have some a tool which shows that all cases are covered by user stories.

Next thing is that specification is not fixed and is changing over time. In that case we need to synchronize all changes in the documentation with the product backlog.

Do you know some tools on the market for such synchronization (mapping)? To make it simpler we can say that specification and product backlog are created in the MS Word and MS Excel.

  • Tool requests are out of scope; if you begin a question with "I'm looking for a tool...." then it is very likely that your question will be closed. Please consult How to Ask. You may wish to either submit the question on the software requirements stack exchange or revise the question to ask about methods rather than tools. (I'm aware this question is 5 years old; I'm responding based on broken window theory).
    – MCW
    Nov 23 '16 at 14:26

I remember looking into a product called Telelogic DOORS for this type of tracking. It seemed perfect, but I wasn't in a position to recommended it at the time.

The product is now a part of IBM's Rational suite of tools, and I would assume has a hefty price tag.

IBM Rational Doors

  • +1 Doors is certainly a way to go. I've used it on a medium-sized project to collate specifications and link them to user stories (which were handed in the Rally Tool). Doors, however, is a very "old school" way of doing things... though I haven't seen anything else that tackles it (though I'll take a poke at Al Biglan's suggestions).
    – Peter K.
    Jun 12 '11 at 21:19
  • Thanks for the suggestion. This seems to be what I'm looking for.
    – hsd
    Jun 13 '11 at 21:14

Unfortunately, this is a well understood problem and a colossal headache any way you approach it. If you need "full, traceable and auditable mapping" you should look at pulling the specification and the User Stories into the same tool.

These tools allow you to make an initial mapping from specification to requirements/user stories then help show you changes, discrepancies, gaps, etc. They usually require a significant investment up front to pull in an initial specification then build the User Stories. They also tend to not help -at-all- when you build a part of the spec once, call it complete, then the customer changes that part of the specification.

Your best bet is to work with the customer to deliver portions of the spec and get them "done and not able to change" as quickly as possible. Work in versioned releases (e.g. the build in Jan will be 0.6, the one in Feb will be 0.6, etc.) and build to 1.0 with your customer. Don't be afraid to push things out of the current scope/project and into "1.1"

Some tools I've used that helped

  • Caliber RM from Borland - Used this 2003-2005. We had 1200 requirements and a "loose specification" I liked the mapping tools and the import/export functions. It did a nice job of tracking the requirements, and decent enough at the specifciation.
  • Roll your own SGML document format - Used this in the late '90s Basically, we "compiled" our documents and the compiler would complain if there wasn't a mapping requirements tag. It required a -huge- dedication to define the structure and maintain the links. (It was a safety-involved product, so it kinda made some sense)

Really, this is a huge headache. If I were faced with this again, I would take the following approach:

  • For less than 750 requirements or less than a 80 page specification, I would keep a Spreadsheet mapping and maintain it myself
  • For more than 750 reeqts or more than 80 page spec, I'd work with the customer to split them until they were small enough to work with in a Spreadshhet
  • Barring that, I would map out my needs for this, spend 3-4 weeks selecting the right tool, and structure my entire project development process around that tool.

and sorry the response is so long :-(

  • The divide and rule is always good practice but in huge project the is not easy to suggest this strategy. Problem is especially with salesman which are always fight to have a big project (a big results = a big money).
    – hsd
    Jun 10 '11 at 21:42
  • 1
    I was an engineering manager of an $81MM project that used this "divide and conquer" approach to good effect and a Project Manager for a $32MM project that did the same. Also part of a project (not as a manager) that was probably in the $200MM range (nuclear reactor) that had at least 22 intermediate builds to develop and add functionality. The arguments aren't always easy, but they can certainly apply to big and small projects alike.
    – Al Biglan
    Jun 11 '11 at 3:00
  • +1: It's a pain regardless of tool support or not. Excel anyone? Keeping everything in alignment is a specialized job. I'd call that job "systems engineering" but that name can have different (incorrect, in my view) connotations in software.
    – Peter K.
    Jun 12 '11 at 21:18
  • Thanks for example of the big project from the real life. I'm agree with you completely. The examples from you required the "divide and conquer" approach. Right now I can balance my comment that I had the feeling about middle project which looks like can be completed in one step but the best will be to apply the disused rules.
    – hsd
    Jun 13 '11 at 21:19

DOORS (Dynamic Object-Oriented Requirements System) is a requirements database tool specifically designed to manage requirement specifications. It is sold by IBM (by Telelogic before they were bought by IBM) and is heavily used in the US defense industry (and often even contractually mandated).

A little background on how DOORS works is instructive in understanding how it might be used to link to user stories:

  • The requirements from a given specification reside in a single module, with each requirement and it's associated meta-data stored in a separate object.
  • A group of modules thus form the set of specifications for a complicated system such as a satellite--starting at the top-level Prime Item Development Specification (PIDS) and flowing down through the lower-level specifications all the way to Software Requirement Specs (SRS) and the hardware equivalents.
  • The inter-relationship between requirements at these various levels is documented and managed with links. Links are connections between requirements (i.e. objects) that (typically) reside in different specifications (i.e. modeules).

Links are how you're going to map your mercurial specification to your backlog.

Links show parent-child requirement relationships. In your case, it appears as if you've received a spec from your customer and want to be able to trace the user stories to their requirements. Assuming that your user stories actually have a fairly straightforward mapping to parent requirements this should be easy to do. Each user story can be an object in a story module that links to a requirement.

These links are then used during the design and development process to understand how requirement changes at one level of the hierarchy flow through the entire system.

For example, if a high-level performance requirement is changed, a simple report run on a properly linked set of specifications will enable the systems engineers to determine the comprehensive set of child requirements that now have to be assessed for impact. Or in your case, a requirements change can be instantly traced to the user story(ies) the change will impact.

DOORS will then enable you to run audits to see if there are any requirements not mapped to a user story, any user stories not linked to a requirement, and any other combination you can think of (e.g. requirements satisfied by several user stories, although this probably indicates the requirement is insufficiently decomposed).

Once the code is complete and released, the meta-data for the user story and spec can be updated to show the requirement has been satisfied and reports generated to show overall progress and outstanding features.

I'm sure there are other tools (probably less expensive ones) that have similar functionality, but DOORS is by far the most ubiquitous--at least in the aerospace and defense industry.


I'm not sure about "mapping to a specification", but being able to map individual user stories back to the "big picture" is definitely something I struggle with as well. I have not found any software that has been great at this, though I also haven't looked very hard. I wouldn't be surprised if some of the larger ALM suites had this. Personally, right now I am managing a "Story Map" which allows us to see how individual user stories fit into the big picture. However managing that is a manual process, so nothing automated. If you're interested in story maps you can check out some of Jeff Patton's material on them (http://www.agileproductdesign.com/blog/the_new_backlog.html).

  • Thanks to share your experience. I would like to add something about specification. For me mapping for the specification is very important because this is one of the stable place to talk about expectations and changes from the customer point of view. In my organization is not easy to talk with customers by a user stories. The main reason is that customers are not prepare to talk in this way. The standard documentations can boring and too long but customers us this as official documents for a contract. In that case we cannot use only the big picture to manage a project.
    – hsd
    Jun 10 '11 at 21:31

There is a really good Jira User Story Mapping Plugin that you can use


Not the answer you're looking for? Browse other questions tagged or ask your own question.