Characteristics of Tools for Requirements Management

When listing features of tools for requirements management, we assume that the tool is computerized, and that the tool is easy to use. Clearly, if a tool is not easy to use, it will not be used no matter what important features it offers.

1. Enable basic operations that are performed on requirements: Such tools should provide the option to define and list requirements in an incremental process during the course of gathering the requirements and, after that, during the entire process of software development. At any stage, when requirements are listed, such tools should support the performance of changes in the requirements that result from the customer s improved understanding of the needed software. As declared previously, customers cannot define a priori all the requirements. Thus, these tools should support the ability to change, update, and refine requirements.

   If the requirements are changed during the development process, such tools should support the tracing of the requirements development together with an explanation of why they are changed.

   Here are additional basic operations on requirements that such tools should offer:

   • Allocation to developers: Who is in charge of the development of each requirement?

   • Verification: What (automatic) test shows that a feature is completed?

   • Tracking the status of any requirement: Is a requirement in development? Is it tested ? Is it completed?

   • Means for notification when deadlines, changes, or status modifications happen: Was a specific deadline changed? Why? What effects does this change have on other deadlines?

2. Show interconnections between requirements: It is important that tools for requirements management show links between requirements (how they are connected to each other) so that changes are cross-notified and relevant changes do not slip through. To keep the customer s priorities intact, such links should include prioritization; that is, which requirement is more important. A graphical presentation of that hierarchy may help the developers identify which requirements are impacted by what changes.

3. Support teamwork and communication: The way in which requirements are managed and developed should be transparent to all the team members. It is clear that the better the communication between team members, the better they can communicate the requirements. This, in turn , leads to the development of a software tool that meets the customer s needs in a better way. When such a tool is accessed by all team members , it improves the development process, and can be used for improving communication between the development team and the customer and between different functions in the company. Thus, for example, senior management may gain a clearer picture of what is developed; customer service representatives get follow-up notification about which version includes their requirements; and communication between the development and the marketing departments is improved. Consequently, situations in which the marketing people promise the customers features that the development department is not aware of may be avoided. To gain this cross-organization access to the requirements management tools, such tools should be collaborative. Naturally, Web-based tools match this purpose.

4. Integration with other development tools: To improve the information flow and interactivity between all the development activities, a requirements management tool may be integrated with the configuration management tool that the team uses. This feature is important only if it does not increase the complexity of the configuration management tool and is easy to use. Similarly, if it does not add to the usage complexity, it may also be integrated with documents and spreadsheets related to the project.

Tasks  

1. The preceding list of characteristics of requirements management tools is a first step in the analysis of the requirements of a tool that manages requirements. These requirements may be changed during the actual development of the tool. Assume that you intend to develop such a tool using an object-oriented approach. What classes and methods will your system consist of?

2. Assume that in your organization, requirements are not managed properly. You decide to initiate the introduction of a requirements management tool. How would you start this process? By convincing the top management? By convincing the developers? What advantages does each approach have? What pitfalls does each approach have? What problems might you face in this process?

3. Discuss connections between requirements management and teamwork (see Chapter 3).

4. Discuss connections between requirements management and learning processes in software engineering (see Chapter 10).