Requirements Management

Requirements Management

The first part of this chapter, which deals with the gathering of information, can be considered part of the management of requirements. Indeed, no matter at what stage a requirement is introduced, it should be managed. In practice, the more the software world is developed, the more it is accepted that the way in which requirements are managed is a critical factor of software success. Efforts made in this direction come to improve software quality at least from the customer s perspective.

The management of requirements can be discussed from a technical point of view (that is, what tools can be used for this purpose and how to use them) and from the human perspective (that is, what needs this activity serves in the process of software development). Naturally, in what follows , the emphasis is placed on the human aspect and not on technical features of any particular tool.

  1. What are the targets of requirements management tools?

  2. What should characterize these tools?

  3. How might such tools influence the process of software development?

  4. Assume that you are going to establish a company that offers a tool for requirements management. Identify your customers. What would you offer them?

  5. In your opinion, can requirements be managed by traditional project management tools? If yes, how? If not, in what sense does a software project differ from other kinds of projects, and, consequently, requires different tools for managing its requirements?

In what follows we present a summary of basic features that computational tools for requirements management should have, emphasizing their importance from the human perspective. We do not claim that the list of features is complete. However, it contains main features that support this complex process. The list is composed based on the analysis of several tools for requirements management (listed at the end of this chapter).

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.

  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).