We had to decide how to manage our requirements. Was it okay to keep the Microsoft Word documents up-to-date and circulate them, or did we need a more formal system? Specifically, should we use a requirements management tool? Initially, we used Microsoft Word to maintain our requirements. This solution worked for our small project when we were getting started. Especially in the beginning of our small project, with just a single customer, we did not feel that the benefits of using a requirements management system outweighed the very slight overhead such a system would incur. As the complexity of your project grows, it is useful to capture your requirements in a database where you can assign attributes to each requirement and adjust the attributes as the requirements change. We recommend that project teams establish a way to manage their requirements so that it is easy to find the current status and expectations for any release. On our project, we eventually decided to switch to a requirements management tool for these reasons:
As you continue reading, keep in mind that the requirements management tool provided much more power for our project than we actually needed. On the other hand, the overhead was so minimal that the tool required us to perform a negligible amount of additional work. After we wrote the Vision and requirements documents, we imported them directly into Rational RequisitePro (an easy step), identified the specific requirements, and identified the attributes we cared about. RequisitePro is an easy-to-use tool that stores requirements in a database. You can either populate the database directly by entering specific requirements, or, more popularly, by capturing requirements from Microsoft Word documents. It also allows you to attach attributes to your requirements, such as priority, status, and so on. RUP provides guidance on how to manage requirements and determine which attributes are appropriate. Apply common sense to this exercise and make sure that each attribute serves a purpose. We actually imported our documents into RequisitePro after the Inception phase was over. We waited until the rate of change on the requirements stabilized. Figure 5.4 shows how our Vision document looked after we imported it into a RequisitePro project. The text of each feature is highlighted with a double underline. Notice that we have chosen to identify each feature requirement with the prefix "FEA." When we identified each requirement, we included the requirement's defining text as part of the requirement. This lets us quickly use the features of RequisitePro to identify when requirements change and what other requirements may be affected by such a change. Figure 5.4. Excerpt from our Vision document in RequisitePro
Using RequisitePro, you can create different views on your requirements. One of the views is the attribute matrix view. This view provides a concise way of seeing the attributes associated with the specific requirements, and the value assigned to each attribute. Figure 5.5 is a snapshot of the attribute matrix for our Vision document, taken after we first imported it into RequisitePro and identified the specific requirements.The attribute values shown in Figure 5.5 have the default settings that we assigned to each attribute. Later views show how we modified the values after we evaluated each requirement. Figure 5.5. Attribute matrix for the PSP Tools features
|