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.
- Microsoft Excel (commercial)
- Microsoft Word (commercial)
- OpenOME (goal / agent modelling focus, free)
- Scrivener (commercial tool focused on professional writers, but leveragable for requirements)
- Use Case Maker (free and open source, use cases only)
Multi-user, Cloud, and Server software:
- Axiom (commercial, but a limited feature community edition is available for free)
- BluePrint Requirements Center (commercial)
- Caliber (commercial)
- CaseComplete (commercial)
- Codebeamer (commercial, with a very-limited feature free edition)
- Cradle by 3SL (commercial)
- DevSpec (commercial)
- Enterprise Architect (commercial)
- Innovator for Business Analysts (commercial)
- InteGREAT (commercial)
- Jama Contour (commercial)
- Orbus iServer (commercial)
- Polarion (commercial)
- RequirementONE (commercial)
- Rommana (commercial)
- Seapine TestTrak (commercial)
- TopTeam Analyst (commercial)
- Top Team Visual Use Case (commercial, use cases only, integrates with Top Team Analyst)
- UNICASE (free and open-source)
- Visure Requirements Lifecycle Management (commercial)
- Wiki’s (commercial and free, possibly open-source, depending on software chosen)
- Yonix (commercial)
Some things to think about when considering different requirements management solutions include:
- Ease of Use: This may be one of the biggest factors for 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 BA’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 BA’s job easier AND the results better. A bad user experience will make your BA’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 requirements 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.
- Tools Listing – The University of Murcia’s “Survey on Requirements Engineering Tools“
- Tools Listing – Ian Alexander’s “Requirements Tools” list
- Tools Listing – “Global Software Development Tools” list by Alarcos Research Group and INDRA.
- Tools Listing – The “Requirements Management Tools Survey” from INCOSE.
- Tools Listing – The “Requirements Management Tools” list from Ludwig Consulting Services.
- Tools Listing – The “Requirements Tools” page at Volere.
- Paper – “How to Evaluate and Select a Requirements Management Tool”, by Seilevel. 2011. A link to the PDF. You can also use this link to download an Excel spreadsheet of the criteria Seilevel used in order re-prioritize the evaluation factors to fit your needs better.
- Paper – “How to Select a Requirements Management Tool: Initial Steps” by Gotel and Mader. A link to the PDF.
- Blog post – “Pick your Requirements Management Tool, then Design your Requirements Process”, by Seilevel. 2011. A link to the posting.
- Blog post – “6 Reasons Why Business Analysts Should Use a Requirements Management Tool”, by Seilevel. 2012. A link to the posting