For the last 10 years or so, I have kept a list of the various Requirement Management tools and their vendors that I have heard of. Since vendors are happy to be listed, new tools often join the list as soon as they are released.
The list is continually changing: new hopefuls arrive every few weeks – an incredible rate – as shiny and bright as pop stars, while others softly and silently slip away. I periodically purge the list by trying all the links.
Despite this ceaseless turnover, the functions of an RM tool have basically changed little: you list your requirements, record their priority, rationale and acceptance criteria, and with any luck you trace them to stakeholders and their goals to show where they came from and why they are needed. Then you trace forward to the test cases that will prove you have got what you wanted – oh, and you write scenarios or use cases to show how the requirements fit together to deliver the goals. Oh, and ... so on.
Each of the RM tools has its own take on how you record all of these interlocking elements, but basically it has to be a database with records/objects containing fields/attributes, with links/traces to items of other kinds.
All of this begs two questions:
In my next article I will try to suggest some answers.
(c) Ian Alexander 2009
Ian's new book, Discovering Requirements, is being published by Wiley in March 2009.
Books you may like:
