Chapter Note

Chapter 30 Requirement Management (RM) Tools

© Karl E. Wiegers

1

30.1 What RM software tools usually do: – Store requirements in a database (statement +

attributes) – Automatically control versions – Allow to add traceability information – Make some use of traceability information • at least marking suspected links • maybe also reporting on requirements that

were not traced to anything else

2

30.2 RM tools - Benefits – Generate (or update) textual documents from the

database – Provide some possibilities for importing requirements

from text – Generate some other reports, e.g. about statuses of

requirements – Put database online so different team members can

access it easily, with no need of creating copies of data. – Provide means for discussion about requirements – Automatically send notifications – Enforce access control, e.g. changes are only by

designated people 3

 Additional psychological advantage: – Both customers and developers may stop to consider

requirements as “paper work”, and start to see them as the project asset.

 Limitations: – Those tools are for requirements management, not for

requirements development. They cannot help with elicitation, validations, negotiating requirements. Actually, it is not even recommended to capture requirements directly into the tool. Better only after they were base-lined.

– Do not expect tools to compensate for a lack of discipline, process or expertise.

– Expensive (several thousands of USD).

4

30.3 Types of RM tools

 Database-centric. Store all requirements, attributes and traceability information in a database. Requirements can be imported from various source documents, but then they reside in the database.

– Telelogic DOORS, Borland CaliberRM

 Document-centric. Treat a document created using a word processing program as the primary container for the requirements, while attributes and traceability information are stored in an additional database.

– Rational RequisitePro

5

DOORS (Telelogic)

 Is a major contender with many years of marketplace experience behind it. Treats individual requirements as objects, but presents them in a visual

 format that resembles a structured, hierarchical requirements document.

6

7

 CaliberRM (Borland)

8

 RequisitePro (IBM/Rational)

Document-centric.  The whole idea is rather strange: - SRS includes only statements, seems to be no way to include attributes also. - Requirements created in the DB view do not go

to the document.

 Implementation seems to be poor - Editing requirements in a Word document is a

“Don’t touch anything!” type of activity.

9

Requisite Pro -2

10

 Major Requirements Management Tools

11

12

13

30.4 Implementation of Tools

 Selection of tools Select a tool based on platform, pricing, access mode,

type . The possible steps of choosing a tool are given in the book

 Changing the culture Changing the company culture and process to accept

the tool is much harder. One approach to is to use the tools once the SRS is more or less clear and stabilized.

More approaches are given in the book 14

E N D

15