There are quite a few requirements management (RM) tools out in the market. Did you ever wonder what qualifies them as an RM tool? This question is of specific interest, when you are in the process of selecting a requirements management tool for your organization.
A good starting point for the evaluation of tools is to get insights about your driving needs.
- What should the tool do for you?
Sometimes, I simply hear “support the RM process”. In other situations I get statements like:
- ease the documentation burden
- provide access to requirements for all stakeholder
- speed-up requirements discussions
The latter situation is better, because it is always helpful working towards your own goals. What is it that you want to accomplish? If you know this, then you get a clear guidance what are the most important features of any given tool for you.
The statement “support the RM process” is more tricky and interesting to explore.
What is Requirements Management?
At first glance one might think, that’s not a big deal because RM is defined. We only need to look at the published definition, check the associated activities and voilà we have something we can compare tool features against. But when you dig into the details about RM you might get puzzled. Definitions about RM aren’t so clear and consistent. When Andreas Birk and I did a recent research about RM definitions we found out, that definitions substantially differ. Below are some prominent examples for Requirements Management:
Karl Wiegers, In search for excellent requirements, 2004:
Manage versions of requirements documents
Adopt and enforce a change control process
Store requirement attributes
Track the status of each requirement
Trace requirements into designs, code, and tests
BABoK Guide, Version 2.0
The activities, that control requirements development,
including requirements change control,
requirements attributes definition, and
IREB CPRE Foundation Level, May 2009
Adding Attributes to Requirements
Creating Views of Requirements
Dealing with Change Requests
Already from these three examples we can see that there is a floating boundary between support of requirements development and requirements management. So, where do we go from here? A good approach is to distill commonalities from the definitions and construct a criteria list:
Requirements management should support all activities to
- define and structure requirements
- discuss requirements
- prioritize requirements
- maintain status on requirements
- track changes of requirements
- version requirements
- trace relationships between requirements and other development artefacts
- communicate about requirements
That provides a great start. We now have some objective criteria to check whether a tool can call itself a requirements management tool. Comment: Will Microsoft Word qualify as RM tool?
But, we aren’t done – these are just the basics.
Beyond Basic Requirements Management
When we look at the feature lists of prominent “RM Tools” we will notice, that vendors typically provide a much richer set of features. There are several reasons for that. On one side rich feature sets are business differentiators. If product A provides “killer features” that other products don’t have, it will have some competitive advantage for the company who sells A.
On the other side a rich feature set for RM may also be rooted in the nature of the requirements management process. Being a central part of product development, requirements management has many interfaces to adjacent processes and tools.
Tool vendors have the option to either provide interfaces to the adjacent processes or incorporate support for these adjacent processes directly in the tool.
Especially products, that are out in the market for quite some time, often show the latter approach. In recent years the term “Application Lifecycle Management” (ALM) became prominent. It is used in situations where a tool provides support for several (or all) phases in the application lifecycle.
While this may suit some companies it imposes challenges too. Often companies have already deployed tools in adjacent areas and are then forced to evaluate what tool solution should be used going forward.
Therefore, ALM in a single tool may only be beneficial for some companies.
New Trend: Visualization and Collaboration
Another trend I observe, is that tools provide more support for the early phases of requirements engineering. In these phases requirements aren’t that clear, but are under constant development. That’s why Carnegie Mellons Software Engineering Institute (SEI) summarizes these activities as “Requirements Development”. There is constant morphing between wishes, ideas, requirements and solution prototyping. To support these activities tools should provide support for
- joint understanding
When requirements aren’t that clear often visualizations help to move forward. In recent years more and more tools offer visualization features for requirements representation. This may range from support for rich media formats like pictures and movies, to support for sketches, storyboards, mockups and finally to support for modeling activities with varying degree of formal notations.
An optimal complement to visualization concepts are collaboration features. Requirements engineering demands interaction between stakeholders. Fortunately the trend to social media software has also spread to the requirements tools market. Use of social media functionality improves requirements understanding and reduces the risk building the wrong product. This is a great advance in requirements engineering.
In summary, I believe that there is time for a new class of requirements tools. Those do not only support classical requirements management, but also requirements activities, that help to improve the collective understanding of requirements through illustration and collaboration and therefore ultimately serve to build better products.
Watch out for these type of tools when selecting a requirements tool.