You have been hired to design the Ticket Tout software system that will allow users to browse and purchase tickets for events via an online portal. Each event has a name, a venue and a genre (such as a rock concert or monster trucks rally, there may be more). It may have just one offering on a particular time and date, or it may have several offerings over a range of times and dates.

For each offering of an event there are a fixed quantity of tickets available. The tickets come in various classes (which might reflect the quality of the view/experience offered), and each class has its own price. Each ticket has a unique serial number and may have other information such as a seat number or section, depending upon the type of event and venue. Each ticket is purchased by a single customer. Customers may buy as many tickets per event as they wish within a single transaction, and the tickets can be of mixed class.

To successfully purchase tickets, customers will need to provide name, address, contact email, contact phone number and credit card information. A typical visit to the portal would see a customer browse the selection of events, get further information on an interesting event and then purchase tickets to go to that event. The administrator of the Ticket Tout system will need to be able to add new events to the system and remove old ones.

The organizations who run the events (such as bands) want to know how many tickets have been sold for an event so far (and for which offerings if applicable), as will venue managers. Administrators should be able to provide that information if requested. Sadly sometimes events have to be cancelled, and in these circumstances the administrator will need to make sure that the event is shown as cancelled in the portal, inform and refund existing customers and prevent new customers from purchasing tickets.

Based on the scenario above:

Here's a brief use case description for the use case 'Browse Events':

The user can choose to view all events, including upcoming and sold-out events, or just those with tickets currently available for sale. The system then provides the user with a list of events and the user selects an event to find out more about it. The user can optionally go on to purchase tickets for that event, or to browse other events.

Now consider this badly written main success scenario (happy path) description for the use case "Browse Events":

1. The user clicks on the menu button for Browse Events. 2. The system displays the list of events, getting its information from the database tables 'Events Available for Purchase' and 'Events Available Soon'. 3. The customer selects an event to see more detail about it and then exits the use case.

Select all statements that are true:

1. Step 2 should include a maximum time for the system to retrieve and display the list.

2. Step 1 contains concrete detail and needs to be rewritten.

3. There is missing functionality between steps 1 and 2.

4. Step 2 contains concrete detail and needs to be rewritten.

5. It is acceptable to describe clicking on a button in step 1 if we have already decided that the interface requires a mouse.

6. Step 3 over-summarizes and should be split into several steps describing discrete user and system actions.

7. Step 3 is acceptably written for the main success scenario because it does not need to consider alternative functionality.

8. Step 2 has missing functionality.