• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Tool School! Insight on 2016 Requirements Management Tool Evaluation Part 1

Seilevel is working on a new version of our 2011 requirements management tool study, revised for 2016 with updated criteria and new tool vendors for consideration. There are a lot of great requirements tools on the market today, from lightweight tools that are easy to set up and use to large enterprise application lifecycle management solutions. Each organization is different, of course, and an RM tool that works great in one setting will be a poor match in another. Consequently, rather than setting out to anoint one tool “the best” RM tool out there, our stated goal was to find the tool that best fit our needs here at Seilevel, and document our journey along the way in the hope that others would find some value in it.

To start with, we asked ourselves, what do I need an RM tool to do? Perhaps unsurprisingly, we employed Seilevel’s scoping methodology to guide us. The first thing we did was create a Feature Tree that called out all the different activities we do as part of the requirements lifecycle (http://bit.ly/tsfeattree). And much like we would for any project, we wrote requirements! In this case, however, we were writing requirements in the form of user stories and acceptance criteria, describing behaviors and functions of an RM tool. For example, under the L1 feature Validate Requirements, one of the user stories was as follows: “As a business stakeholder, I want to be able to review and approve or reject requirements in the tool so that I know the requirements satisfy my objectives before they are sent to the development team.” The acceptance criteria were as follows:

  • Can review sets of requirements in the tool and indicate they’ve been reviewed
  • Can approve one or more requirements
  • Can reject one or more requirements as needing more work
  • Can add feedback commentary on requirements

When we review each tool in the study, we’ll score it against the acceptance criteria, not the user story. However, having the user story provides context to the acceptance criteria if there are questions, and makes clear why these criteria are important.

We ended up with approximately 280 criteria for an RM tool, with criteria covering everything from estimating the size of a full requirements effort to the ease of entering in individual requirements, from how the tools handled visualization and modeling to whether they can integrate with other tools and systems. After coming up with our list, we also weighted the criteria by importance to Seilevel. I want to stress again that while the criteria themselves are meant to be as objective as possible, the weighting of each criteria was a subjective process. What we deemed to be important for us at Seilevel might not be the same thing your organization cares about! However, we plan to make the results of the study available once they’re ready, giving you a chance to adjust the relative weight of each criteria and see what tools might best fit your organization’s needs.

No comments yet.

Leave a Reply

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