Business requirements management tools

Every requirement needs a unique identifier and a meaningful name. The requirement needs a brief description that is understandable to the business. I've seen some implementations where descriptions can be some kind of a graphic that you attach a screen shot or something that you might put on the web with your requirements.

The version number of the requirement e. Requirement types and change history are a little more subtle in that typically, if you're managing your requirements in a text document, it is the document that is versioned and not the individual requirement. That is probably not too bad in a simple project, but when you have different stakeholders interested in different sets of requirements, you may actually want to publish a particular version of requirements to subgroups of people.

Requirements status is an important input to your project metrics. An example of this is when a draft requirement waiting approval has been approved, has been deferred, and has been removed. An analysis of status metrics can help you understand why things in a project might be taking longer than expected. What is the issue? What is the problem? Why have I got 50 requirements that have been removed, suspended, or deferred?

What is the cause of that? Why is that not going to go ahead? Requirements priority is particularly important for stakeholders. Questions that may be asked are: What are my mandatory requirements? Which ones are not mandatory, but are desirable so that if I have time constraints, I canlook at deferring implementation of those requirements?

The requirements owner needs to be identified, so that if a requirement is not understood, more information can be obtained. If the developer comes back and says that something is a good idea, but it will cause grief in terms of implementation, you can also go back and ask the owner if there is something else that can be done with thatrequirement. You may also have a stakeholder that is going on leave and his script of requirements may go to someone else who can manage those requirements temporarily and then update the stakeholder on changes when they return.

Just a word of caution, do not put in too many attributes the requirements management plan to start with. There is a real temptation to put in lots of attributes, but then you end up being a slave to your requirements management plan. Start with the simple ones and expand out as you have some different projects and different company needs. One of the most important components of requirements management is traceability.

Tracing allows us to understand why the requirement exists, the impact of change, if the set of requirements is complete, and helps prioritize requirements.

The complexity of tracing could be very simple or it could be quite extensive. It really depends upon the maturity of the organization and the groups that you are working with. You can see that the volume of requirements at a high level is quite small, but as you go down, you go down into a lower level of granularity where the volume is going to grow. Yet, it is critically important to understand how they relate back up to the top.

Putting it all together is how an expert BA will differentiate him or herself. Once all the requirements artifacts are traced tightly together, we start to achieve clarity and control of the scope. Finally, trace information gives you the ability to look at a particular requirement and trace whether it is a genuine solution requirement.

Does that solution requirement have any associated nonfunctional requirements? At the next level, publish a baseline set of requirements to the development team. The development team then tags the code components back to those original requirements and the test team actually takes their test cases back to those requirements as an extension of that traceability.

When we talk about traceability, it is not just between solution and nonfunctional requirements; it is the whole gambit back to strategy.

When we trace consistently, it becomes second nature and its value becomes apparent. Every time you are looking at changing a requirement, you must think of the impact it will have and what else it will affect. You have to go back and look at what other requirements this is traced to and make sure that you have not upset anything else. Typically, this happens more frequently in the early analysis.

Then as you go through to development, you are still always trying to ensure that you trace between requirements and maintain integrity between the solution and the strategy. Requirements versioning is the process of documenting and maintaining a history of all changes to a specific requirement. The primary purpose of versioning an individual requirement is to help ensure that the project team is working from the exact same requirement.

Versioning is important to increment changes to a requirement. Unless you are using a requirements management tool, this is probably something that you are not going to continually do. Important requirements may change a number of times, 20, 50 times, and this may occur through the whole lifecycle of the project.

It is important to track what version of that requirement and what the specifics of the changes to that requirement are. This allows you to link it to the owner, who is the one who performed the change. Each project should define a baseline strategy that includes defining the baseline in terms of creation, frequency, content, and publishing.

A baseline is the vehicle for communicating changes in the detail of requirements to interested parties. Baselining is a mechanism to package a set of requirements at a particular point in time and pass that off to the next group in the project team. However, it is actually just a robust Wiki architecture which is still better than MS Word in many ways.

In all honesty, if you don't have a specific tool, then you just have to get creative with what you do have to make it work. Google docs also has a variety of diagramming addons that might make it a viable option as well. Most tools that are more specific to BA work will likely be very expensive. This is because they are usually intended for entire enterprises and when you are trying to trace requirements enterprise-wide, excel might not be the easiest to manage.

For you however, I think Excel is likely one of your best options because its easy to manipulate to be exactly what you need. MS Visio is the power tool, but the same can be accomplished with draw. Hello, great post and video. One question, can you create a tutorial to creating the Sharepoint Traceability module you created? I love the idea and will come back and check this post regularly. Thanks or email me stevej gmail. At the time, we went with Blueprint because of how it was structured because we were looking for more of a repository type of situation with re-usable components and essentially a functional reference library.

Your email address will not be published. Skip to content. February 17, Angelo the BA 13 Comments. Pricing: Perforce offers a day free trial of Helix RM through their online sign-up form.

Contact Perform for pricing. Jira helps teams identify and map business requirements, collaborate with stakeholders, ensure all tasks connect directly back to any capture requirements, and provide stakeholders with high-quality deliverables.

Jira makes it easy to see how business requirements and existing issues are linked, trace project tasks back to business requirements, and determine how requirements differ from a baseline. Jira also allows stakeholders to create and view a requirements hierarchy structure. Pricing: JIRA has cloud or self-managed pricing options. Both tiers come with a 7-day free trial. The self-managed pricing tiers come with a day free trial. Integrations: JIRA has an extensive list of integrations, including project management, administrative tools, utilities, blueprints, charts and diagramming, CRM, dashboards, coding, email, document management, support desk, security, testing and more.

It is a useful tool to reduce manual testing efforts. It is one of the best requirements gathering tools which allows organizations to deliver quality software at less price.

It also has many ALM Management capabilities. It can associate with source code, tasks, bugs, tests, releases and all other artifacts. It is one of the best requirements traceability tools that offers gapless traceability across the entire lifecycle.

ReqView is a simple but powerful requirements management software. It allows capturing requirements in structured documents. It collaborates offline with the team by storing project data on a shared network drive. Top team analysis is a useful require management tool. It converts textual requirements into easy-to-understand diagrams.

It is one of the best requirement analysis tools that helps to understand requirements without reading too many documents. CASE spec is a modern requirements management tool.

It helps users to manage any project artifact with complete traceability. It is one of the best free requirements management tools which allows tracing requirements through design, testing, impact analysis, and gap analysis. This requirement management tool simplifies product planning with easy backlog management. This tool provides stakeholders with a centralized view of the backlog.

It has a drag-and-drop interface. Dimensions RM is a useful require management tool. It is one of the best requirement tracking tools that helps to increase visibility and collaboration across business and delivery teams. It offers powerful reporting, tracking and provide end-to-end tractability.

JIRA Core is a requirement management and business analyst tool. It helps every business person to plan, track, and create a report of their work. Silkroad is an ALM system for high-reliability software. It has interlinking routes for the various legacy management system.

It is a multi-purpose software which can act as requirement and test management tool. Reqchecker is a requirement coverage tool.