Use and Abuse Cases

6 downloads 0 Views 193KB Size Report
description after their inclusion in UML [6]. There are ... of Westminster; outlining the two case studies used as ... requirements elicitation as well as analysis and UML modeling using ... “Dummies' guide to writing use cases” – and hence.
Use and Abuse Cases Ljerka Beus-Dukic, Colin Myers Cavendish School of Computer Science, University of Westminster [email protected], [email protected] Abstract Use Case Modeling (UCM) has become an essential ingredient of computing courses, as it is widely used in object-oriented analysis and design. Although a simple concept, UCM is not straightforward to teach. We report on our experience gained in teaching students as a part of requirements engineering education at both undergraduate and postgraduate level. Two case studies reveal a number of problems students have, and we suggest consequent improvements to make in the teaching and assessing our students. We believe these tactics can be equally beneficial to the wider community.

1. Introduction Teaching requirements engineering (RE) to computing students involves a wide range of topics and skills. Requirements elicitation and analysis skills are fundamental for requirements engineers but amongst the hardest to teach and attain. Use cases are used for the capture of functional requirements and also in analysis, design, and to generate test cases. Although known for 17 years [15], use cases only became a widely accepted technique for requirements description after their inclusion in UML [6]. There are many reports [12, 16] on the success of use cases in commercial projects. Consequently, UCM deserves its place in computer science and software engineering curricula. However, current literature is inadequate for teaching UCM to students. The majority of the available texts focused on giving advice on how to write use cases (e.g. [11, 19, 21] target industry practitioners but not RE teachers. The lack of a precise and universally accepted definition of a use case [12], combined with a variety of use case templates and

guidelines further hinders RE teachers. In addition, RE teachers seem to be reluctant to share their experience; reports on the subject of RE teaching and training are in short supply [9,26,31]. In this paper, we describe our experience in teaching UCM to undergraduate and postgraduate software engineering students. The paper is structured as follows: the next section explains how RE module, and more specifically UCM, is taught at the University of Westminster; outlining the two case studies used as student assignment, Section 3 presents qualitative reflection on issues arising from student attempts at UCM; Section 4 makes recommendations from them; followed by a conclusion that student use case abuse often stems from a lack of problem ownership coupled with textbooks that fail to provide students with enough experience of how things can go wrong. An Appendix gives details of the scenarios used in the case studies..

2. Teaching use case modeling In this section we report on our experience of UCM teaching as a part of RE, in particular as a tool for requirements elicitation and clarification. The RE module is currently taught at the University of Westminster, in the third year of Bachelor of Science Software Engineering and Computing courses over a 13-week semester (1/8 of the final year). The content of the module is based on our knowledge of industry practice, RE research [24], current RE teaching practice [8, 18, 9, 26], and professional organization (IEEE, ACM) guidelines [7, 14]. Lectures cover the following topics: • RE fundamentals and process • Requirements elicitation • Requirements analysis

• • • • • •

Non-functional requirements Requirements for safety-critical systems Requirements specification and documentation Requirements validation Requirements management Requirements for COTS-based systems

In weekly two-hour tutorials, students practice requirements elicitation as well as analysis and UML modeling using Rational Rose [25]. Most of the tutorial tasks are conducted in teams of two to four members. Students are encouraged to use their communication skills and interact with each other and the teacher. Interaction within the teams involves adopting various roles, including those of manager and customer (the latter role mirrored by the lecturer). In each tutorial, a time, usually half an hour, is set aside for discussion of current problems. Other contact is maintained by the teams outside of the tutorials via email and informal meetings. Feedback on the students’ solutions and a suggested ‘model answer’ is provided by the lecturer. Our undergraduates have already been taught UML in their second year of study as a program design tool. Thus, there is no need for them to spend time becoming familiar with the available tool (Rational Rose) and we are able to spend more time doing exercises in problem understanding and requirements articulation. Similar material is taught as part of a Software Engineering Context module to postgraduates who do not have a specialist computing background and consequently have not been exposed to UML.

2.1 Requirements elicitation and analysis Requirements elicitation and analysis are essential topics in any RE syllabus [7, 14]. Modelling – the construction of abstract descriptions that are amenable to interpretation [24] – goes hand in hand with analysis. Learning about modeling methods and their associated analysis techniques helps problem solving and at the same time drives the requirements elicitation process. We start by identifying system boundaries and stakeholders [1]. It is important for students to learn that every system will eventually be a part of an operational environment and that identification of stakeholders (and hence user goals, scenarios and use cases) depends on how the boundaries are chosen [24].

Using various techniques given in lectures, students (divided in groups) practice interviewing and group elicitation in tutorials. During these tutorials, they take

roles of different stakeholders for the same case study (e.g., a ticket machine system on an unmanned train station). Ideally, this approach seamlessly leads to the modelling of stakeholders’ goals and scenarios that illustrate how goals can be achieved [20, 23]. Focusing on the problem domain and the needs of stakeholders should steer students away from pre-empting solutions. This might work in theory but is almost impossible to achieve in practice, as software engineering students were already predisposed to look for solutions to clearly defined problems. This may be exacerbated by the fact that the undergraduates have already used UCM for program design and hence find themselves unable to make the distinction between using UCM as an analysis tool rather than a design tool. However, the problem is also manifest with postgraduates so perhaps it is more fundamental.

2.2 Scenarios and use cases UCM superficially appears easy to teach and learn: there are many books on the subject [11, 19, 21] and a plethora of web-based sources. However, there is little help available for beginners – something like a “Dummies’ guide to writing use cases” – and hence simple examples are scarce in the public domain [10]. Similarly, there are few guides to what makes a good use case compared to a bad use case. In the lectures, students are introduced to the concept of scenarios followed by examples of use cases based on the template given in Table 1. This template is given in one-column table format and has evolved from a RUP template [21]. Note that triggers, special requirements and extension points are excluded while alternative flows do not cover branching actions on error conditions. Table 1. Use case description template [4] Name indicates what is achieved by its interaction with the actor(s); verbnoun combination Description reflects its role and purpose; it is an informal overview of the functionality; a single paragraph is sufficient Actors primary and secondary actors Pre-conditions a system state prior to a use case entry Flow of events textual description of the operations by the actor and the system’s various responses Basic flow “happy day” scenario

Alternative flow

alternative behaviour, optional ways of handling certain conditions Exceptions error conditions Post-conditions a system state on use case exit In tutorials, we begin with an exercise in identifying actors and deciding on the system boundary (this exercise makes use of [1]). This is followed by the first UCM tutorial, which starts with the task of defining different scenarios for a given case study (e.g, a Conference System [5]). After producing a number of scenarios, students are asked to write use cases (an exemplar is given in the Appendix, Table 2), which are then analyzed and discussed. Several tutorials are dedicated to use case writing practice. Students are given writing guidelines, asked to work in groups and discuss with a teacher any issues they encounter. Tutorials are supplemented by a seminar given by an experienced RE practitioner. .

2.3 Assessment Criteria The UCM coursework is worth 20% of the overall module mark (for both modules). Students are asked to write: • A use case diagram (produced using Rational Rose and marked for syntactic correctness, semantic accuracy, comprehensive coverage, readability and consistency) • Detailed use case descriptions for all identified use cases using the use case description template. The coursework can be done either individually or in self-selected groups of no more than three people. Group and individual submissions are marked in the same way. All group members receive the same mark. The use case diagram is assessed for: • • • • • • • • •

Syntax (correctness, use of the tool) Semantics (appropriate abstraction level, understanding) Coverage (scope, appropriate actors and use cases) Readability (appropriate names, consistent naming) Consistency of abstraction level The use case description is assessed for: Syntax (use of template) Appropriate level of abstraction (preferably usergoal [11]), no design creep Consistency of chosen level of abstraction Semantics (actors explicitly identified and used, appropriate flow of events and input/output data)

• •

Readability (flow of events, use of actors) Function space coverage (appropriate detail given)

These assessment criteria are given in advance to the students.

2.4 Assessment Issues “What makes a good use case? That the goal of satisfying the use case is evident; that the use case is written with steps at the same level, making it easy to follow, that the trigger and preconditions are clearly evident; that it is relatively brief (l-2 pages); that the set of use cases clearly cover the function space “[12]. Stated in this way, it seems that a use case description should be easy to assess but in practice it I a complex task. This is because evaluation is not only on the students’ technical understanding but more fundamentally on their domain knowledge and interpretation; some of this reasonable and some less than reasonable. Hence, there will be no single correct solution and also many potentially incorrect solutions!

2.5 Case Study 1 – Video Shop The UCM coursework for both groups of students (60 undergraduates and 40 postgraduates) has a Video Shop System (Appendix, Figure 1) as the case study (CS1) to analyze and model. This was adopted from Maciaszek [22] and, at the time, we assumed that the subject of the case study would be familiar to all students. The students needed to make 1) a use case diagram using Rational Rose (available in the lab and on their home PCs) and 2) use case descriptions using the template of their choice. However, the RUP template [21] was recommended. Students were given written and oral feedback. Written feedback included detailed remarks on their submitted coursework together with a student feedback form containing a structured summary of remarks. Oral feedback consisted of a summary of generic remarks given to a whole class of students (this was only logistically possible for the postgraduate students) and individual oral feedback for students who requested it.

2.6 Case Study 2 – Theatre Ticket Booking The case study (CS2) given to both groups of students (30 undergraduates and 30 postgraduates) was a Theatre Ticket Booking System (Appendix, Fig 2) adapted from Vigden [28,29].

The task set was slightly simplified in that the students were given a fixed template (Table 1) for the use case description. Additionally, they were asked to list any assumptions they made in the analysis process. The feedback process was the same as with CS1.

3. Technical Issues The following offers a qualitative reflection on the major technical issues that have arisen from teaching and assessing UCM using the above case studies. It should be clear that most of these problems are compounded by domain misinterpretation.

3.1 Include and Extend Use case structuring was used intensively in CS2. The students were usually able to correctly distinguish sequences worthy of inclusion or extension but did not use the appropriate notation, in particular inclusion was often mixed up with extension.

3.2 Use Case Description Issues Name The Use case name should indicate what is going to be achieved by the use case (e.g., Rent a Video in CS1 or Process Ticket Return in CS2). Students were instructed to use verb-noun combination of words having a meaning in the problem domain they are describing. However, there were many bad names, some of these perhaps a consequence of poor English, even to the extent of not understanding what is meant by a “verb-noun combination”. Examples from CS1 include - Movie Reservations, Rent, Search Engine and Reservation - and from CS2 - Booking, Theatre Club Membership. Description Descriptions in both case studies were rarely given with an appropriate information balance: they were either too long or too short. Instead of stating the goal of a primary actor in employing the use case, some students provided a whole basic flow of events, a list of assumptions and often pre- and post-conditions too. Actors Actors were often omitted or specified incorrectly. Students were not sure how many actors they needed to list and in which order. Using different names for

the same actor within the same use case or in different use cases was a frequent occurrence (e.g.. Customer and User were used interchangeably in both case studies). Specialization of the roles also caused confusion (e.g., Shop Assistant interacting with the system on behalf of a Customer in CS1, and Customer purchasing tickets on the Internet but Operator selling tickets over the phone). Pre-conditions This section was a stumbling section for many students. The students often confused pre-conditions either with assumptions they had made or the events that were more appropriate for the start of the basic flow. In CS2 students used pre-conditions to show the linkage between use cases. Basic flow of events In general, students found it difficult to describe action steps in the basic flow using sentences written in the present tense with an active verb and in the active voice [11]. It seems that students either genuinely lacked this skill or chose to ignore the advice given. Although they were consistently told that events should be written from the point of view of the actor, they still wrote in a passive voice and often omitted either the actors or the system. A typical example from CS1: “The condition of the disk is recorded on the customer’s account”. Even when the interactions between the actor and the system were clear the system responses were missing. Sometimes, the actors used in the flow were not the ones mentioned in the Actors’ section; common reasons included use of different terms for the same actor (e.g., User, Customer, Client) or indecision about the actors’ roles. Although most of the students used numbered steps only the minority did not miss any steps. For many basic flows it was not clear how they started and terminated. This oversight became more apparent in CS2 where students used includes and extensions. A considerable number of students had a problem with the level of detail to be given in any action step. While some described every interface detail, others did not mention any. This was despite that fact that during tutorials students were told to consider examples of the relevant data passed to and from the system in their action steps. Alternative flow of events In CS1, many students used the recommended RUP template and consequently treated optional flows together with error conditions. In CS2 students were

given the template where there was a clear division between infrequently used paths and the ones taken when errors were made. Rather disappointing, there was not much difference between the outputs produced from both case studies; the students still mixed optional flows with those to be followed under error conditions. The only difference in CS2 was that they tried to present alternative flows in a more structured fashion using numbered steps. This led to some students having unnecessary step repetition rather than cross-referencing the basic flow. A solution provided by one student in CS2 was to ignore the basic flow and repeat the steps from the basic flow inside the alternative flow. The students did not know what to do if they encountered an error condition in the alternative step. Similarly, if each alternative path had several steps then students could not resolve this problem. Exceptions While they struggled to find alternative paths, students usually did not have any problems finding error conditions worthy of consideration. Some were so eager to produce exceptional sequences of events that their lists of actions dealing with error conditions were much longer than the ones for the basic flow. This happened mainly for two reasons: 1) the students were in fact describing alternative flows; 2) the level of abstraction used for exceptional flow was lower than the one used for basic and alternative flows. Post-conditions The majority of students wrote about the state of the system after the use case terminated or when the happy day scenario was successfully completed. However, often pre- and post-conditions did not match since they belonged to entirely different use cases.

3.3 Technical Writing During feedback sessions with students it was evident that students needed clear instructions to help them write use case descriptions. Many students had a poor writing style, which often made their intended meaning difficult to detect. This consequently led to poor assessment grades, perhaps with the associated negative feeling about UCM that one might expect. With the help of existing guidelines [11, 13], it initially appears that creating appropriate guidelines for students should be possible, but putting it into practice is a much harder thing to do.

4. Recommendations This section offers recommendations to deal with some of the problems outlined above. On the whole, we believe that the problems are mainly a consequence of poor domain analysis.

4.1 Issues arising from Domain Analysis 4.1.1. Domain boundaries – scope. Inevitably the case studies provided for the students are incomplete. However, some students will ignore some (or even most) of the intended problem statement and provide their own interpretation based perhaps on minimal keyword recognition. In both case studies the majority of students had different ideas about what constitutes a problem. Although an informal problem statement was given with an aim to constrain the problem, most students had a tendency to expand it. They found it hard “to elicit the critical aspects of the environment and required system while neglecting the unimportant” [17]. The students’ knowledge of, and interest in exploring, the world outside of computing plays a crucial role here. In CS2 (Theatre Ticket Booking System) postgraduate students were considerably better in identifying problem boundaries. For example, they noticed that there is no mention of ticket collection in the case study description and most of them used their knowledge to make their own realistic assumptions. On the other hand, only a handful of undergraduate students elaborated ticket collection at all. Recommendations: a)

Give domains with which the students are familiar.

b) Encourage students to ask about domain boundaries. This is necessary, in that during tutorial sessions, only a small proportion of questions were about the case study boundaries – perhaps because they are too busy coming to terms with the technical aspects of UCM rather than what they are trying to represent. c) Show poor use cases that ignore the case study and ask students to say why these do not reflect the case study.

4.1.2. Silent Assumptions. Even if the information content of the case study is accurately represented, some students are prone to silently add their own inappropriate assumptions.

functions [24]. However, we agree with Cockburn [11] that finding the right goal level is the single hardest thing about use cases. Recommendation:

Recommendations: a)

Penalize students for unstated assumptions whether correct or not. b) Provide students with examples of case studies which are incomplete or ambiguous. Even good case studies can be unintentionally lacking, ambiguous or contradictory. So provide students with such examples and show the consequences for use cases. Here, if a student cannot identify an appropriate actor or action then they may learn that this is because the case study information is intentionally inaccurate. c) Require assumptions to be documented The CS2 results showed that it was useful for the students to have a documented list of assumptions that they made in the process of analyzing the problem statement and identifying problem domain boundaries. This is particularly important for assessment purposes, especially if a student extended or altered the boundaries in any way. 4.1.3. Inappropriate Assumptions. Students often made inappropriate assumptions when they tried to fill the gaps in the problem statement without doing more analysis to understand the key stakeholder needs. Recommendations: a)

Always ask students to give a justification for their assumption; for example, if it is filling a gap, resolving a contradiction or moving the boundary. b) Give bad examples and show consequences. 4.1.4. Non-assumptions. Some students ‘assume’ facts that are already given in the case study. Whilst this is not actually misleading, it shows a deeper misunderstanding of what an assumption is. As students they are wasting time, and as practitioners they are likely to irritate clients. . Recommendation:

Students need to be taught how to distinguish between different levels of abstraction. Although we believe that user goals (sea-level [11]) are of the greatest interest for requirements analysis, it is necessary to teach students the difference between other goal levels (e.g. summary, sub-functions). Our students like Cockburn’s graphical representation of goal levels as five different altitudes [11]. If they can learn how to recognize different goal levels, they will have much better chance of finding user goals, treat the system as a black box, and consequently write better use case descriptions.. 4.1.6. Jumping to solutions. Writing assumptions proved to be a useful way of finding out what students knew or had discovered about the case study, and how detailed was their analysis. However, students often made assumptions that could be considered as part of the solution space rather than the problem space. For example, in the CS2 many students made the assumption that a customer had to register with the theatre ticket booking system before even selecting a performance. At undergraduate level this problem is exacerbated by the fact that students have been previously taught UCM and UML notation as a design tool. Consequently, their description of what the system does in response to interaction with the actors included how the behaviour is implemented. Recommendation: Show examples of the same use case description for analysis and also for design 4.1.7. Jargon Confusion. In reality, many domains have their own jargon. Many students either ignore the bits they do not understand or make false assumptions. Recommendations: a)

Show use cases with assumptions and actual derived facts given in the case study and ask students to identify which are which. 4.1.5. Domain boundaries – depth. RE is concerned with the real-world goals for software systems

Include case studies that have some jargon

b) Encourage the students to maintain a glossary Use case steps should be written in a structured narrative employing the vocabulary of the problem domain. Students should be encouraged to create their own glossary of the terms. This should not

only help reduce mistakes in their use case diagrams and descriptions, but also establish the practice of maintaining a consistent terminology across all aspects of a requirements analysis. c)

Include video footage of a problem statement presentation given by one of the key stakeholders.

4.1.8. Actor recognition. It is difficult for students to grasp the concept of a role, either when one actor represents a whole category of individuals or when one individual can play different roles. Typical examples are: 1) in CS1 a role overlap between a manager and a shop assistant (manager is a special kind of shop assistant but a lot of students drew it the other way round); 2) in CS2 there was confusion between the role of a customer versus that of a phone operator. Additionally, the scanning machine was not identified as a supporting actor in CS1 The fact that the system under consideration is itself an actor, albeit a special one, for some students remains a mystery as they denote the whole system under discussion as a stick figure. Students often erroneously included actors who were stakeholders not found in the case study problem statement. As a consequence, more use cases were shown than were needed, even taking into account the students’ stated assumptions. Recommendations: a) Give exercises only involving identifying actors b) Show use cases with bad actors

4.2. Templates The fact that there are many different templates (and respective writing guidelines) available for students to choose from, adds to their perplexity when faced with the task of writing use case descriptions. Recommendation: Students need an agreed formal structure (i.e. a template), which they will not be free to abuse. This is perhaps the single most important technical lesson we learned from the case studies.

5. Conclusions Students will make technical modeling errors in using UCM: these are relatively easy to rectify. It can be much more difficult to help students to analyze the

underlying domain, especially since case studies rarely allow the student to become the owner of a problem domain (the closest they get is to be a user-stakeholder or to role-play the owner-stakeholder). This is not helped by the fact that most textbooks tend to present miracles. The analysis always works and the analyst is never wrong. In practice, things are much messier and students can often learn more from a bad example than a good example. Former student assessments and project work can provide a rich source of material.

6. References [1] Alexander I., “Stakeholders – Who is Your System For?”, Computing and Control Engineering, IEE, Vol.14, Issue 1, Apr 2003, pp 22-26. [2] Alexander I., and S. Robertson, “Stakeholders Without Tears: An Exploration of Project Sociology, RESG Tutorial, London, Jul 2003. [3] Alexander I. F., and R. Stevens, Writing Better Requirements, Addison-Wesley, 2002. [4] Beus-Dukic L., 3SFE616 Requirements Engineering, Lecture Notes, University of Westminster, 2003. [5] Kelly P., Systems Analysis and Design, Exercises, Northumbria University, 2000. [6] Booch G., J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. [7] Bourque P., R. Dupuis, A. Abran, J. W. Moore, and L. Tripp, “The Guide to the Software Engineering Body of Knowledge”, IEEE Software, Vol 16, No. 6, Nov/Dec 1999. [8] Bray I. K., An Introduction to Requirements Engineering, Addison-Wesley, 2002. [9] Bray I., Requirements Engineering Training, RESG RE Training Event, London, Dec 2003. [10] Britton C., and J. Doake, Object-Oriented Systems Development: a gentle introduction, Mc-Graw Hill, 2000. [11] Cockburn, A., Writing Effective Use Cases, AddisonWesley, 2001. [12] Cockburn, A., and M. Fowler, “Question Time! About Use Cases”, ACM SIGPLAN Notices, Vol. 33, Issue 10, Oct 1998. [13] Cox K., K Phalp, and M. Shepperd, Comparing Use Case Writing Guidelines”, Proc. of the 7th Int Workshop on Requirements Engineering: Foundation for Software Quality, Interlaken, Switzerland, Jun 2001, pp. 101-112. [14]Computing Curricula, Volume on Software Engineering, SEEK – the body of Software Engineering Education Knowledge, http://www.acm.org/education/curricula.html [15] Jacobson I., “Object-oriented development in an industrial environment”, ACM SIGPLAN Notices, Vol. 22, Issue 12, Dec 1987. [16] Jacobson I., “Use Cases – Yesterday, Today, and Tomorrow”, The Rational Edge, Mar 2003. [17] Kramer J., Abstraction – is it teachable? “the devil is in the detail”, Proc. of the 16th Conference on Software Engineering Education and Training, IEEE, Vol I, Mar 2003, pp. 32-32.

[18] Kotonya, G., and I. Sommerville, Requirements Engineering: Processes and Techniques, Wiley, 1998. [19] Kulak, D., and E. Guiney, Use Cases: Requirements in Context, ACM Press, 2000. [20] Lee J. H, J.Kim, and S. Y. Park, “A Scenario-based Goal-oriented Approach for Use Case Modeling”, Journal of KISS: Software and Applications, Vol. 29, No. 3-4, Apr 2002, pp. 211-224. [21] Leffingwell D., and D. Widrig, Managing Software Requirements: A Unified Approach, Addison-Wesley, 2000. [22] Maciaszek L. A., Requirements Analysis and System Design: Developing Information Systems with UML, Addison-Wesley, 2001. [23] Maiden N., “CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements”, Automated Software Engineering, Vol. 5, No. 4, 1998, pp. 419-446. [24] Nuseibeh, B., and S. Easterbrook., “Requirements Engineering: A Roadmap”, In: The Future of Software Engineering, 22nd International Conference on Software Engineering, ACM, Limerick, Ireland, 2000. [25] Rational Suite Development Studio, http://www.rational.com. [26] Sawyer P., Underpinning RE Training, RESG RE Training Event, London, Dec 2003. [27] Sindre G., and A. L. Opdahl, “Templates for Misuse Case Description”, Proc. of the 7th Int Workshop on Requirements Engineering: Foundation for Software Quality, Interlaken, Switzerland, Jun 2001. [28] Vigden R., “Requirements Analysis and UML: Use Cases and Class Diagrams”, Computing and Control Engineering, Vol . 14(1), Apr 2003. [29] Vigden, R., D. Avison, B. Wood, and T. Wood-Harper, Developing Web Information Systems, ButterworthHeinemmann, 2002. [30] Weidenhaupt K., K. Pohl, M. Jarke, and P. Haumer, “Scenarios in System Development: Current Practice”, IEEE Software, Vol. 15(2), Mar/Apr 1998, pp. 34-45. [31] Zowghi D., and S. Paryani, “Teaching Requirements Engineering through Role Playing: Lessons Learnt”, Proc. of the 11th IEEE International Requirements Engineering Conference, 2003.

Appendix A new video shop intends to offer rentals of videotapes and disks to the public. The shop management is determined to launch its operations with the support of a computer system. The video shop will initially keep a stock of about a thousand videotapes and five hundred video disks. The inventory has already been ordered from one supplier, but more suppliers will be approached for future orders. All videotapes and disks will be bar coded so that a scanning machine integrated with the system can support the rentals and returns. The customer membership cards will also be bar coded. Each title has a particular rental period (expressed in days), with

a rental charge for that period. The rental charge differs depending on the video medium: tape or disk. Existing customers will be able to place reservations on videos to be collected at a specific date. The system must have a flexible search engine to answer customer inquiries, including inquiries about titles that the video store does not stock but may order on request. The video shop must be able to answer immediately any inquiries about a title’s stock availability and how many tapes and/or disks are available for rental. The current condition of each tape and disk must be known and recorded. Figure 1. Case study description for the Video Shop System The Monkbar Playhouse wants to start up an Internet ticketing facility in conjunction with the software house, Nexus Information Systems. The plan is to make the theatre booking system an Internet application available to the two other theatres in York, both of which rely currently on in-person and telephone ticket bookings. Once the system is operational it should be a relatively small step to make the service available to theatres in any part of the country. The theatre stages a number of plays during the season. Each play can have performances on different days of the week and may have more than one performance on any given day. The new ticket booking system will enable customers to purchase the tickets over the Internet, but they will still be able to purchase the tickets by phone. In both cases, only credit or debit card payments will be accepted. Customers can join the Theatre Club and as members (who pay an annual membership fee) they will benefit from discounted ticket prices. The ticket prices vary according to the part of theatre where the seat is, and the performance schedule (day of the week/time of the day). Customers can return their tickets and get an appropriate refund. Figure 2. Case study description for the Theatre Ticket Booking System Table 2. An example of a use case from a tutorial Name Book a Conference Place Description Delegate submits details of booking, indicating if he/she is a presenter. System checks stored presenter details and availability of a place. Accommodation and conference dinner are booked if requested. Payment is settled Actor Delegate PreThe system is operational.

conditions Basic flow of events

1.

2. 3. 4.

5. 6.

7. 8. 9. 10. Alternative flow

A1 A2

Exceptions

E1

E2

E3

Delegate submits personal details (e.g., name, address, tel. no., organisation, email, fax) and whether he/she is an academic presenter, student presenter, an academic non-presenter or a student non-presenter. If the delegate is a presenter, the system checks that the personal details match stored author details. The system confirms a place for the delegate. The delegate may choose to book accommodation or may submit a reservation and menu choice for the conference dinner. The delegate submits any special requirements and the system records these. Based on the type of participant and on the date of booking, the system calculates the overall conference charge and displays it for delegate. Delegate enters payment details. (Use case: Process Payment). Delegate confirms overall booking. System stores all the booking details and increments total number of delegates booked. The use case terminates when all details are recorded. In Step 4 the delegate chooses to book accommodation. (Use case: Book Accommodation) In Step 4 the delegate submits a reservation and menu choice for the conference dinner; if successful, this is recorded. In Step 2 if no match was found system informs delegate of failure to match details. Delegate corrects personal details and re-submits. Use case continues. In Step 3 if no places left for nonpresenters system informs potential delegates of unavailability. Use case terminates. In Step A2 if the delegate submits a reservation for a conference dinner and there are no places for dinner, system informs delegate that there are no places left for the conference

Postconditions

The system stores all the booking details provided.