Guiding Use Case Driven Requirements Elicitation and ... - CiteSeerX

Guiding Use Case Driven Requirements Elicitation and Analysis Keith Phalp and Karl Cox Empirical Software Engineering Research Group Bournemouth University, UK Abstract Use cases are often perceived as an integral part of an objectoriented approach to software development, yet despite claims that objects fall naturally from the use case description [1], detailed guidance on moving towards design is rather limited. This paper outlines an approach which helps to tease out information necessary for design, that helps discover design classes which are often hidden, implicit or assumed.

1. Introduction: The Two Faces of Use Case Description Use cases have at least two different purposes dependent upon the phase of modelling in which they are employed. That is, they have both a client-facing role and a role in moving towards design. Hence, whilst one of our goals has been to improve the comprehensibility of the use case from the perspective of the client or end user, another has been to improve the utility of the use case in providing useful information for the designer. In addressing comprehensibility, we have examined ways of improving the initial description by using writing guidelines (both CREWS [2] and our own [3]), and of validating the description by using enactable models. However, we note that with some recent exceptions [4, 5, 6] there has been little guidance in moving from use cases towards design, our second goal. In agreement with [4], we utilise an approach which interrogates the use case with question sets in order to reveal design issues.

2. The Method We improve our understanding of a domain by asking (sets of) questions, which are required to build richer models. In our case, many of these questions are related to the consideration of pre and post conditions for the events of the use case description. This approach of questioning and model building to enhance understanding thus forms the basis of the series of steps (our outline method) described below.

1.

2.

3.

4.

5.

6.

7.

(a) Produce (or use existing) overview process models. We choose to model with Role Activity Diagrams (RADs) [7], a successful approach to business process modelling widely used in the UK. We find that existing process descriptions may often be in the form of Role Activity Diagrams. (b) An additional advantage of adopting RADs is that we may further validate the process by producing enactable versions of these models using Henderson’s RolEnact [8]. Use the roles and chief interactions from the RAD to produce a system use case model. Roles become actors and interactions become either events within use cases or whole use cases. Hence, steps 1 and 2 focus on the business perspective. Further steps begin to focus on the software architecture and place related use cases into UML packages, identified either from groups of activities within the RAD or from a typical (e.g., 3-tiered) architecture. Produce use case descriptions with the aid of writing guidelines (e.g., our own CP rules [3] or those from CREWS [2]). Initially, these descriptions are abstract or high-level but are later refined towards the system interaction. Sub-system use cases are primarily identified from actions performed by roles in the RAD and the software architecture. Interrogate events in the use case descriptions, focussing on dependencies between events such as pre and post conditions. Move towards design by considering possible system internal processing that needs occur to help identify potential control classes. Similarly, use question sets designed to uncover issues about actors and the interfaces of the system. Identify potential classes and their types, for instance, entity, interface, control, or database classes. We find that hidden classes are teased out and others already identified are validated (or otherwise) through rigorous application of step 4. Optionally, we may again formally validate the (class) model by enacting the description. Use identified classes to shape the architecture of the system design, typically separating the interface from the underlying business model. Enaction of the process (use case description) also enables us to validate classes both externally visible and internal to the system. We identify key class operations through examining the events of the use case. Finally, further validate the class models with interaction diagrams that employ the behaviours identified in the use case descriptions and in the dependencies between events in each description.

We have conducted empirical studies on two themes, writing use cases [3] and moving from use cases to design. Having found some merit in these approaches we are currently refining the method by applying it to an industrial context.

3. Industrial Case Study The case study involves a major re-engineering project for a company based in the financial sector, whose chief products are internet-based financial and brokerage systems. The company has decided to re-engineer its online customer application procedure to simplify mail-outs of documentation to new customers. We are

currently modelling this re-engineering project with the aim of providing a new design to enable implementation of the product. We now describe snippets from the work already undertaken, which are products of the method outlined in section 2. We take roles in the new (or existing) Role Activity Diagrams and generally consider them as actors in a use case diagram. High-level interactions in the RAD become use cases. Hence, an interaction between a Customer and Front Office (system under design), such as “Apply for Account” would become a use case. Similarly, interactions between software systems such as “Check Credit Status”, are also regarded as use cases, but instantiated by the system itself. If we expand upon the Check Credit use case, we reveal the following part of the description: 1. The Business Layer connects to the Credit Checker System. 2. The Business Layer sends the Customer’s bank details to the Credit Checker System. 3. The Credit Checker System returns Customer credit worthy. However, it is only by interrogating this use case (considering pre and post conditions) that we discover the hidden objects that drive this interaction. Consider the results of such an interrogation for event 2. Pre-Condition: Connection made with Credit Checker System. This should involve an interface connector class that might need some middleware. A CreditCheck class has retrieved the necessary information to send Customer bank details (from CustomerBankDetails ). Credit Checker System is in a state to receive them. Post-Condition: Customer bank details sent; received by Credit Checker. System: Business model locates Customer records – with CreditCheck> class - from memory (CustomerApplication class and BankDetails class) and has sent information to Credit Checker System. Actor: Credit Checker System Potential Class: CustomerApplication , CreditCheck , CreditLink , CustomerBankDetails . By asking ‘questions’, we discover that going from a GUI class such as Bank Details (entered by the Customer at the interface) to the Credit Checker System (actor) requires such hidden control classes as Credit Check to drive the process. The Credit Check needs to recall the Customer bank details and personal details (e.g., name and address) from working memory i.e., entity classes in the underlying business model, as opposed to the GUI. The control class (Credit Check) then connects to the Credit Checker System through an interface class that contains the necessary protocols. Without rigorous examination of each use case event, we may miss these classes. Certainly, the original design for the system in the case study had not been so careful, and our analysis brought such design issues to light.

4. Findings Our initial empirical studies suggested that the method described aided not only comprehension of the use case descriptions (and thus the problem domain) but also

the move towards design. For this industrial study we did not produce the (admittedly optional) enactable models of either processes (step 1) or use cases (step 2). However, we did use the core questioning approach to improve our comprehension of use cases and to tease out design issues. Although we have only given a brief glimpse of the study, we found the interrogation of use case behaviour, by examination of pre and post conditions of events, to be particularly successful, leading to the discovery of hidden classes and operations. Indeed, the success of the method is that it allows flexibility in application whilst retaining utility. However, further work will attempt to discover the extent to which subsets of the method are most useful within the industrial setting.

5. Conclusions and Further Work This paper has described a series of steps to guide software engineers through use case description towards design. This approach has previously been developed by applying the methods within an academic environment and is now being applied to an industrial case study, which we have briefly outlined. Although our earlier work found merit in using writing guidelines for use case descriptions [3], our industrial case study found the interrogation of use cases most productive. That is, by asking sets of questions about the description, in particular those that relate to the interdependencies of events, a much richer understanding was gained. For example, one clear advantage was the early discovery of classes required by the design, which were not explicitly described in the use case description. Further work will concentrate on evolving the method, both with further experimental work and by industrial application. References 1. Jacobson I, Christerson M, Jonsson P, Oevergaard G. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley, 1992. 2. Ben Achour C, Rolland C, Maiden N, Souveyet S. Guiding Use Case Authoring: Results from an Empirical Study. Fourth IEEE International Symposium on Requirements Engineering (RE’99), Limerick, Ireland, 7-11 June, 1999. http://sunsite.informatik.rwth-aachen.de/CREWS/reports.htm, Report 98-31 3. Cox K, Phalp KT, Shepperd M. Comparing Use Case Writing Guidelines. 7th Int. Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ’2001). Interlaken, Switzerland, June 4-5, 2001. 4. Armour F, Miller G. Advanced Use Case Modeling. Addison-Wesley, 2001. 5. Kosters G, Six H-W, Winter M. Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications. Requirements Engineering Journal 2001 6,1: 3-17. 6. Rosenberg D, Scott K. Use Case Driven Object Modeling with UML. AddisonWesley, 1999. 7. Ould M. Business Processes: Modelling and Analysis for Re-engineering and Improvement, John Wiley & Sons, 1995. 8. Phalp KT, Abeysinghe GK, Henderson P, Walters RJ. RolEnact: Enactable Models of Business Processes. Information and Software Technology 1998 40, 3.