Requirements Documentation and Management Tools


Requirements documentation and management tools provide a number of benefits to Business Analysts and the work they do.  Most of the multi-user solutions include:

  • Some form of central repository in which all requirements are stored.  This means there is only “one source of truth”.
  • Some form of access control and permissions functionality so that only people who should be making changes are.
  • Automatic versioning and change tracking.  So that you can see who made what changes and roll them back if necessary.
  • Support for different development processes (most will support various versions of waterfall, most now support at least one agile methodology).  Many will let you define your own process.
  • Support for different requirements types and/or the ability to define various requirements types to your own specifications (business rules, user requirements, functional requirements, non-functional requirements, etc)
  • Some tools now include functionality for creating diagrams, wireframes, mock-ups, or simulations as part of the tool.  Others may require you to use a different tool and attach the output as a file.
  • Many support alternate documentation formats (written requirement, diagram, wireframe, etc), although in some cases this is purely in the form of an attached document.
  • Many are now including some form of requirements review and sign-off functionality.


Desktop software:

Multi-user, Cloud, and Server software:



Some things to think about when considering different requirements management solutions include:

  • Ease of Use: This may be one of the biggest factors for choosing an RM tool.  How easy will it be for your users to learn, adopt, and leverage the tool?  If the tool is hard to learn, or makes the user’s job harder, you are not going to get a lot of adoption.  Or you may see significantly reduced productivity.  The goal of a RM tool should be to make a user’s job easier AND the results better.  A bad user experience will make your user’s resent being forced to use something that makes them work harder.
  • The Types and Experience of your Users:  Related to ease of use is the consideration of what the types and experience level of your users are.  Junior BA’s might like a tool that includes wizards or other mechanisms to help them do their jobs.  While Senior BA’s might want a tool that gets out of their way and lets them work quickly in a way they like.  Among those you will also have the tech power-users who love to learn how to leverage a tool to it’s maximum and who might want to (for example) use their keyboard as much as possible.  While the less tech-devoted want something that is very simple for them to use and understand with a simple interface.
  • Offline Access:  A growing number of requirements management tools are now offered as Software as a Service.  If your team needs access to requirements even when they don’t have network access, this may reduce your options.
  • Your Process: If you have a highly specific process that you don’t see changing, make sure your tool can support your process.  But as the “Pick your requirements tool” resource mentioned below discusses, this may be putting the cart before the horse.  The tool you choose may offer ways of improving your current process.  And then there is always the chance that you get a new CIO who decides to change the process you use.  So look for a package that will let you define a process.
  • Levels of Traceability: Do your requirements frequently include business rules, data dictionaries, wireframes, screen prototypes, BPMN and other diagrams?  If so one thing many people overlook is making sure that the tool you choose will let you trace from specific requirements to other specific requirements in a non-text form.  For example, many will let you trace from a functional requirement to a business rule (usually text to text), but if you want to trace that functional requirement to the specific design element on a wireframe that implements that function, you may be out of luck.  Many requirements tools (especially if they treat non-text requirements as an attachment of some sort) will only let you trace your requirement to a wireframe or BPMN diagram document, not to a specific element within those diagrams.  So when you ask if a tool supports diagramming, dive into more detail to understand any limitations.
  • Requirements Review and Sign-off: Some tools support requirements reviews of various sorts.  Some features to consider are:
    • Does the tool allow for requirements reviews within the tool, or will you have to export your requirements to another format outside the tool?
    • Does the tool allow you to break apart your overall requirements set and designate specific requirements to be approved by specific users or groups of users? (very handy if different SME’s or stakeholders are approving different aspects of your requirements)
    • Does the tool allow for comments on specific requirements so that reviewers can provide feedback?  A more advanced version of this allows for threaded discussions at the individual requirements level so that multiple parties can be involved in a coherent conversation.
    • Does the tool allow for “electronic signatures” of some sort so that requirements can be formally approved and this action can be captured in the audit log?
    • Does the tool keep track of the specific version of a requirement that was approved so that the BA and reviewers know when a previously reviewed requirement has been updated?
    • Does the tool allow for change-highlighting between updated versions of a requirement so that reviewers can easily see what has changed?
  • Feature Set: Do you want an all-in-one tool that your BA’s and other users can use for creating text requirements, diagrams, wireframes, screen mock-ups, or even interactive simulations and prototypes?  Those tools exist.  But you usually get at least a bit less functionality than you would get from a single tool that does one of those well (for example, iRise is great at simulations, but barely adequate or less when it comes to documenting requirements).  Explore the features you need now, and that you may need in the future, and pick a tool that does the best at meeting them.
  • The Provider:  Who is the company behind the tool?  Do they seem like they will still be in business in 5 years?  Do they have a product road-map they are willing to share with you that shows how they plan to enhance their product?  Do they have a large and stable client base?  Do they have the resources to provide regular bug-fixes and updates to the application?  These are key factors to think about for any software you use.
  • Integration with other Applications:  Does the tool integrate with other applications you use in your development cycle?  Do you use Quality Center for testing?  JIRA for bug tracking?  What about your development environment?  Can your developers trace code directly to the requirement they implement?  These are all things to think about as well.


One thought on “Requirements Documentation and Management Tools

  1. Richard Levine

    Nice list and nice website, as a resource of Business Analysts

    Suggestion for another Requirements Management Tool for your list – RequirementONE
    Useful and cost-effective cloud-based tool for small to medium-sized companies, at the very least.


Leave a Reply

Your email address will not be published. Required fields are marked *