Better Software - March 2008 - (Page 43)

100% 80% 60% 40% 20% 0% In the previous steps we identified the inventory of core features and crosscutting concerns. We also know that crosscutting concerns are scattered across the application and affect core features. Therefore, the purpose of this step is to analyze the composition of requirements and specify their structure in an RCT, as shown in table 1. This table will be used as a frame of reference to establish traceability in step 5 and to assess test coverage in step 6. Our HMS application consists of five modules, where each module includes a number of use cases. Depending on the module complexity, we can create a separate requirements composition table for each module. Table 1 shows an example created for the 01. Front Desk module. First, we populate columns in this table representing use cases, where each use case provides a context for analyzing functional features. Second, we compile a generic list of concerns composed of such requirements categories as core functionality, GUI features, and the identified crosscutting concerns. We then populate rows in the table with the list categories. As a result, we create a complete inventory of requirements that we will analyze to compose a structure of requirements. Composing the requirements structure means that for each use case context we indicate which concerns are a part of or have impact on this context. We take one use case at a time and, going through the list of concerns, we make a decision about which concerns from the generic list should be applicable to that use case context. When we make a decision that a given concern is applicable, we indicate it in the corresponding cell in the table by entering 1; otherwise, we enter 0. We begin the requirements composition analysis with the first item in the list—Core Functionality. By default, each use case has core functionality, so we enter 1 in all cells related to this category. Next in the list is the GUI Features category. Because each use case implements GUI, we enter 1 in all cells rep- Figure 3: Summary of assessment results resenting this category. We then continue this analysis for all crosscutting concerns in the list, making a decision about which of them affects a given use case context. Most of the time we make such decisions based on our common sense and prior experience. For example, we want to give the privilege to create a guest reservation only to some user roles. Hence, we make a decision that the User Roles concern affects the context of the UC.01.01 use case. Further, while creating a new reservation, the user should enter reservation data. Therefore, the system should implement field validation that can be invoked either when the user leaves a given data-entry field or when the user saves the entire reservation. This means that the Field Validation concern should be marked as affecting the UC.01.01 use case. Another example is analysis of the Connectivity concern. One important requirement for the HMS application is that when the front end is disconnected, the application should inform the user about the disconnected state and then provide the user with some limited functionality. In particular, the front-desk clerk should be able to process guest reservations. This means that the Connectivity concern also affects the context of the UC.01.01 use case. We continue analyzing the first use case for all other crosscutting concerns. Once we have completed this analysis for all use cases, the composition table has all cells popuwww.StickyMinds.com lated with either 1 or 0, thus representing a complete structure of functional requirements. With step 4 we completed the first module’s RCT that is now ready to be used for establishing traceability and measuring test coverage. Even though creating an RCT takes a few steps, in practice it doesn’t take much time. Commonly, just a one-hour session with either a business analyst or developer who knows well the functionality of a given module is sufficient to complete the RCT for that module. At this point in our analysis we already know the inventory and structure of functional requirements. We also know the inventory of the existing regression tests that we need to allocate to their related requirements. Once this step is completed, we will be able to measure test coverage and identify coverage gaps in step 6. Commonly, regression tests are stored either in a test management tool, for example Mercury Quality Center (MQC), or in Excel or Word documents. If you use a test management tool, you first need to create in the tool a requirements repository following the same requirements structure as we created in the RCT. Alternatively, if you manage your MARCH 2008 BETTER SOFTWARE 43 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.