Mapping Tools to Purpose


If there is an overriding message in this book, it is this: Understand the requirements before building the product. This point also applies when you are buying a requirementsproduct. Before you, or your manager, succumb to the elaborate claims of the tool salesman, consider what you want your tool to doyour requirements for a requirements tool. If your requirement is to manage the requirements deliverables, then consider those deliverables when making a purchase decision.

Figure 15.1 is a class model of the key requirements deliverables, described in the template, along with the inter-deliverable associations needed to manage the requirements.

Figure 15.1.

The requirements knowledge model. This class diagram shows the components of the requirements specification (rectangles) and the necessary associations between them (lines). The boldfaced numbers correspond to the section numbers of the Volere Requirements Specification Template that describe the components. The asterisks and numbers on the associations indicate how many components can participate in the association.


Let's look at this model. Each component of the requirements specification is represented by a class. The classes are tagged with the corresponding section numbers from the Volere Requirements Specification Template. The associations between the classes indicate a need to understand the links between those classes. For example, the classes Work Context and Business Event have an association, which indicates a need to keep track of the links between the two. The 1 and the asterisk (*) indicate that each Work Context has potentially many Business Events associated with it. Thus, if we have a work context, then we need to know how many business events affect it, and we need to link those business events back to the work context.

Now we have a requirement for a requirements tool: We would like the tool to keep track of this association and alert us to any problems. We would also like the tool to recordthe details of the Work Context and each Business Event as well as the associated business use case defined in section 8 of the template. For example, the template tells us that, [a-z]+ define a Work Context, we need to record things like the adjacent systems and the details of the interfaces between those adjacent systems and the work we are investigating. This information is usually recorded as a context diagram, but it could be documented in other ways. Similarly, we need to record the details of the associated business event andbusiness use case. Normally we create several scenariosthe normal case and the exceptions and alternativesto account for the details of a business use case.

To make requirements easier to think about, we categorize them into the subtypes of Constraints, Functional, Nonfunctional, and Technological requirements. We need to record and retrieve each of these subcategories. We also need to know which Technological requirements were added to which Product Use Case.

When we look at the association between a Requirement and a Product Use Case in Figure 15.1, we see that a Product Use Case has many Requirements attached to it. This is normal, as you would need to assemble all of the product use case's requirements for a functional review. But the model also shows a Requirement having associations with many (indicated by the asterisk) Product Use Cases. In other words, sometimes the same requirement is included in several different product use cases. Rather than describe the entire model, look at how the components are linked and consider what you want from yourown requirements specification. The idea behind the model is that you can use it as an overview of your requirements for a tool. Map the tool to the requirements using the following as a guide:

  • Use the requirements classes and associations in Figure 15.1 and the supporting details in the template and requirements shell as a checklist.

  • What can the tool help you to record?

  • Can the tool record the details for each component of the specification?

  • Can the tool record the details of each association?

  • Can the tool identify problems and inconsistencies?

  • Does the tool report on discrepancies and inconsistencies between classes of knowledge? (Refer to Chapter 11, The Quality Gateway,and Chapter 14, Reviewing the Specification.)

  • Does the tool alert you to possible missing associations?

  • Can the tool help you monitor completeness?

  • Does the tool alert you to missing definitions of terms?

  • Does the tool analyze percentage complete of each class of knowledge in Figure 15.1?

When you map your needs against the capabilities of a tool, you will almost certainly discover needs that are not completely met. This does not mean there is anything inherently wrong with the tool. Rather, it reflects the fact that requirements engineering is a relatively new field and the tools are being developed by many different people with different perspectives. Similarly, organizations are developing their own requirements processes because no standard way of gathering requirements has emerged. Because of these issues, don't expect any tool to do everything that you want.

To meet all of your needs, you must design your own requirements environment. Define how all parts, automated and manual, interface with each other. In other words, you need your tools to support, as seamlessly as possible, all the activities that you carry out within your requirements process.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net