 |
I recently worked on a selection process for a requirements management tool. It was great to look into tools that support the job that I do. The market is roughly split into two categories: · Requirement definition tools that specialise in visualisations, prototyping, mock-ups, modelling and collaboration to help elicit and validate requirements. · Requirement management tools that specialise in capturing, tracking and managing requirements in a central repository So which one is right for you? Well it depends what your problem is · If you have a problem with the quality of your requirements you probably want to be looking at the requirement definition market. · If you have trouble maintaining requirements, struggling with change control or ensuring requirements are delivered then a requirement management tool will be more your thing. · If you are having trouble with storing requirements, test cases, change control, version control and defects and providing traceability between each of them then you probably should be looking in application lifecycle management (ALM). · If you have a poor or undefined requirements engineering process then it is probably best to re-work that before investing in a tool. If you just need a repository for requirements in the short-term, I would suggest you get a cheap SaaS requirements management solution on a monthly subscription, but make sure it has an export function! Although I won’t be discussing application lifecycle management tools here, I would highly recommend that this option is investigated with your delivery team if a requirement management solution is required. ALMs can have as strong requirement management capabilities as standalone tools so they shouldn’t be discounted from a selection process. If your delivery team is already using an ALM that does not meet your requirement engineering needs, consider whether a tool has an interface to the ALM. To highlight the differences further I have broken down what I think the activities of requirements engineering in the following Business Activity Model. I have colour coded it to give an indication of a tools strength in a particular area. · Red – the domain of requirements definition · Blue – the domain of requirements engineering · Yellow – neither solution is particularly strong As with anything, there are never clear boundaries between requirements definition and requirements management applications as some tools operate across domains particularly for requirement definition platforms, so I have tried to introduce a spectrum of colour to indicate the amount of crossover. Please note that in my assessment I was focusing on SaaS requirement management tools with a focus on a unique set of requirements (some of which crossed into requirements definition) so this is my subjective view. Once you have decided on the type of tool you need to consider the tools of that type. I found just over a 100 requirement management tools so coming up with a shortlist based on some high-level criteria was useful. Then you can focus on choosing a product that meets your individual needs. I would strongly recommend you read Right tools, write requirements, right on! by Forrester’s Mary Gerush if you can get your hands on it. Here is a summary of my findings regarding requirement tool capabilities which may help guide you if you are if you looking into this topic. Analyse Stakeholders
There is very little functionality in analysing stakeholders apart from storing there names and most tools do not distinguish them from other users. Abilities to model influence, interest and system usage would be very beneficial. Requirements Elicitation
Requirement elicitation is defined as a separate function from modelling and prototyping but as this is the heartland of requirement definition I have coloured this more red than stricter rules would allow. Requirements management tools support elicitation through document management and one or two allow users to request requirements. However, I think that tools that support questionnaires and activity sampling could be really useful too. Modelling
Models are a powerful way of requirement definition. Process, Context, Class and Use Case diagrams describe requirements at the highest level. As stated above this is the domain of requirements definition but a few requirements management tools do support an element of this. Not sure if any tools support these, but CRUD and Completeness matrices would be great addition. Categorise Requirements
Things like requirement hierarchies, requirement types and sub-types, projects, statuses and by other categories such use cases or features is the domain of requirement management. Most of these tools enable requirement attributes to be configured to support bespoke categorisation (and any other attribute you think would be useful). Necessity and Feasibility
I would hope all requirements management tools support prioritisation, but there appears to be little functionality beyond that. Capabilities to qualify business, technological and financial feasibility are generally not present. Requirements hierarchies can support necessity validation by ensuring that all requirements map back to the overall business goal. Deliver Requirements
Some requirement management tools allow requirements to be grouped into sprints, iterations, and releases for projects. Some tools are process specific (particularly for Agile development) while others are process agnostic. Requirement traceability is also provided and requirement support can be facilitated via requirement collaboration, although I have categorised these features elsewhere. Requirements Management
Obviously this is the main stay of requirement management tools. This area covers a plethora of functionality such as storage, security, traceability, approval and change management, workflow, baselines, version history and reporting. I would be surprised if any requirement management tool did not support this list of functionality. Communicate and negotiate requirements
Collaboration in requirements management is critical to requirements management and requirement definition. These days, teams are distributed and requirement elicitation and validation is becoming more a shared responsibility between the business, business analysts, developers and testers. On-line comments, review and approval facilities help with clarification and validation. Negotiation can be facilitated through discussion forums. Of all the features discussed here I think this is one of the more powerful features of requirement management tools. Validate Requirements
The strength of requirement management tools here are workflow approval which pushes up the clarity and accuracy of requirements. The use of Glossaries is available in a few tools, but these are only really helpful if the application can highlight the terms used within the requirement. Generate Scenarios and Prototypes
This area is all about processes, simulations, prototypes and mock-ups, and this constitutes the core features of requirement definition tools. Use case descriptions are supported by a few requirements management tools for scenario modelling. Plan Analysis project
Note I have used the term analysis here, to separate it from delivering requirements. There is little in the way features for planning analysis projects. All I can think of is assigning high level requirements to releases (or sprints) so the order in which detail is elicited can be planned. The requirement management tools that best support this are focused on Agile development. I imagine ALMs would be strong in this area too. Track Progress
Requirements management tools generally offer both “out-the-box” and configurable reporting. I think the key feature here is to track the progress of a requirement through its lifecycle, but assessing overall project progress based on where requirements are in the development cycle (e.g. burndown charts) could also be useful for a wider audience. Measure Quality
I couldn’t really find features on measuring quality. Useful tools would be to ensure that patterns are followed, that requirements are atomic and that the appropriate terms are being used from the glossary. Manage Analysis Projects
I didn’t really look into this area, but the strength of requirements management to report on progress would enable the control function. Better support for quality measurement would greatly enhance these features. Please feel free to get in touch with me at peter.measures@emc.com if you want discuss this with me. |
