Information Analysis:Requirements gathering and use case diagrams

8.4 Requirements gathering and use case diagrams

8.4.1 Requirements gathering

In an ideal world, requirements should be expressed in terms that are testable and verifiable, justifiable, unambiguous, consistent, modifiable, and traceable. For example, it is not a testable requirement of the theatre booking system to say that theatre yield must be increased. The requirement is testable if annual theatre yield is defined as the total available seats in a year divided by the number of seats sold with a target increase of 8.5% for the first year of operation of the booking system.

Traditionally, the system analyst would gather requirements through interviews with individuals, questionnaires, observation of work practices, and by studying business documents. All of these can be useful in understanding the current situation, although they tend to focus on the current situation and run the risk of reinforcing incremental change rather than creative thinking and radical change. A more participative approach to requirements analysis is joint application design (JAD), where key users, managers, and systems developers come together in a workshop setting to discuss system requirements. These sessions are typically intense, lasting from a few hours up to several days and are often run off-site to ensure the participants focus on the task free from the distractions of the office. JAD workshops combined with the development of prototypes – possibly a throw-away – to deliver an executable specification make a particularly powerful combination for understanding and agreeing requirements. Where the prototype develops iteratively into the final system then the requirements specification is in a process of continuous refinement and can be adapted to changes in the environment. In chapter 7 we took the notion of participation beyond JAD and considered how users can be empowered to participate fully and genuinely in the system development process.

Further sources of requirements include external research, such as an investigation of industry best practices. For example, in developing a theatre booking system it would be advisable to carry out a review of existing Internet theatre booking systems and also industry leaders from other industries (e.g.,Amazon.com) to see how things are done and to find out what constitutes best practice.

Requirements are often categorized as functional and non-functional. For a theatre booking system, we would expect to find a functional requirement such as 'take payment for online ticket booking'. The functional requirements of the theatre booking system will be captured in use case diagrams and use case descriptions. A non-functional requirement might be for booking enquiry pages to load quickly. The non-functional requirements also need to be recorded and specified in terms that can be tested and verified, e.g., 'maximum page load time of 8 seconds with an average load time of 3 seconds using a 56k dial-up modem'.

8.4.2 Use case notation

Use case diagrams are a formalized notation for modeling the system from the perspective of the user. The focus is on what the system does – its behaviour – rather than how it achieves it. A use case typically represents some functionality of the proposed system as perceived by a user. Use cases will add business value, such as 'process ticket returns', and have a business outcome, such as 'returned tickets reallocated'. In the early stages of a development project it is important that use cases focus on business goals rather than system goals.

The use case notation comprises actors, use cases, and associations (figure 8.2). An actor reflects a role that is played by a human (or non-human) with respect to a system. A role can be played by many people, e.g., doctor, and one person can play many roles, e.g., the theatre manager could play the role of box office clerk during busy periods and a box office clerk might also attend a performance as a member of the public. It is therefore important to think in terms of actors and roles rather than individuals and job titles. Actors execute use cases, such as a doctor prescribing treatment. The link between actors and use cases is shown by an association (figure 8.2), which indicates that there is communication between the actor and the use case, such as the sending and receiving of messages.

Figure 8.3 shows a use case diagram for the box office of a theatre, such as the Barchester Playhouse. Human actors (we are not talking here about the actors in a play!) include customers and telephone sales operators. The accounting system is a non-human actor. It is external to the box office domain but it has requirements of the box office and is therefore shown as an actor.

Customers are associated with two use cases: 'make Internet ticket purchase' and 'join the Internet Theatre Club'. These will be activities that the customers can perform for themselves online via the Internet. It might be argued that the inclusion of a technology, the Internet, is misplaced in a conceptual model of the box office. However, although we might remove the word 'Internet' or replace it with 'online', from a business perspective it may be appropriate to make it absolutely clear that these will be Internet services available to customers. When developing a use case diagram it is important that the use cases are described from the reference point of the actor – for example, operators sell tickets, but customers purchase tickets on the Internet (from the Playhouse's perspective they are both ticket sale mechanisms).

8.4.3 Extension, inclusion, and generalization

Extends

The extends relationship is used where there are similar use cases but one use case does more than the other. For example, a ticket sale where the performance is full (figure 8.3) requires that a variation on the ticket sale use case be carried out. For an extends relationship:

First capture the simple, normal case, e.g., operator ticket sale.

Then, for each step in the use case ask what could go wrong, e.g.,

Check seat availability (performance full)

Take payment (credit card not authorized)

These variations can then be modeled as extensions of the base use case. An extends relationship models the part of a use case that the user may see as optional behaviour, such as the situation in figure 8.3 where the requested performance is full.

Include

If multiple use cases require the same chunk of functionality then it can be made into a separate use case and referred to with an 'includes' relationship. For example, ticket sales and ticket returns both need to use the take payment use case, as does join Internet theatre club. This functionality can be separated out into a single use case rather than being duplicated in multiple use cases.

With 'extends' the actor will deal with the base case and the variations – the same operator will deal with ticket sales that can be fulfilled and ticket sales that cannot because no seats are available. With an 'includes' relationship a different actor might be responsible for making a refund for returned tickets (e.g., box office supervisor) from the actor involved in an operator ticket sale (e.g., box office operator).

Generalization

The Internet ticket purchase, where the customer interacts directly with the ticket booking system rather than using a telephone operator or box office clerk as an intermediary, can be modeled as a specialization of the more general case of ticket sale. This would allow the Internet ticket purchase to inherit some of the general characteristics of the operator ticket sale and to add refinements as needed. For example, the operator would be able to see the theatre layout with available seats in one colour and booked seats in another colour. The Internet customer might not be allowed to see exactly which seats are booked (an empty theatre might put them off booking) and be allocated seats automatically by the system.

8.4.4 Describing a use case

Each of the use cases in the diagram should be elaborated with a use case description. This is the starting point for a process of elaboration that will eventually lead to a software implementation.

The use case description in table 8.1 provides a high-level description of the Internet ticket purchase use case. Figure 8.3 addresses the operations of the box office with respect to ticket sales, but there is a range of administrative activities needed to support the ticket sales activities (figure 8.4).