Reference no: EM133522617

Information Systems Principles and Practice

Case study: Young Soccer Clubs Association (YSCA)

The Young Soccer Clubs Association (YSCA) is a loose group of children's soccer clubs that play interclub games regularly throughout the football season. It is run on an amateur basis, and each week a volunteer from each of the two clubs present at a match provides a referee and line referee for the game, alternating roles to ensure fairness.

The Managing Committee of the YSCA has been organising this informally for many years, and now wants to put the refereeing on a formal basis, which will be auditable by the International Association Football Amateur Referees Association (IAFARA). They have passed a set of by-laws, and to ensure that the process works properly, and is fair, they have decided to commission a computer system - AutoRef.

The Committee wants AutoRef to automate the process of assigning referees, so that volunteers can have advance notice of when they are refereeing a match, where the match will be held, and the role that they will play there (referee or line referee). This will combine calendaring and scheduling with a mechanism for advance notice of unavailability and messaging to find a substitute referee. The AutoRef system will have a central secure database and be accessible through the web and mobile devices by the committee members, IAFARA and the volunteers.

AutoRef needs to maintain information about the volunteers, including whether they have had training in refereeing, have a government clearance for working with children, and have a current first aid certificate. Obviously, it also needs to keep track of the various matches to be played throughout the season.

AutoRef should send out text messages a week before a match, and reminder messages the day before and the morning of the game. Ideally it should enable a call on a GPS system (such as Google Maps) to show where the match is being held and how to get there. If a scheduled referee is unavailable for a match, she or he will be able to send a notification to AutoRef, which will then call on remaining volunteers and assign a substitute referee.

Question 1. Describe the trigger of the AutoRef system and explain the benefit AutoRef would bring.

Question 2. List the stakeholders for the AutoRef system, and in each case explain what their interest in the system is.

Question 3. (a) List the functional requirements for the AutoRef system as identified in the description above.

(b) Using the FURPS+ categories, describe several non-functional requirements for AutoRef. Address all of the categories: if you consider that any of them are irrelevant, explain why.

Question 4. (a) Use the user goal technique to identify all the use cases that would be relevant to the AutoRef who would be a potential user of the watch. Present your list in a table giving the participating actor, use case name and an informative brief description.

(b) Use the Event Decomposition technique to identify any additional use cases for the AutoRef. Present your list in a table that includes the event, type of event, use case name, and brief use case description. You do not need to repeat the use cases you identified in (a) here.

Question 5. Domain modelling (this question doesn't refer to the case above)

Draw a UML domain model class diagram for the system as described here. Be as specific and accurate as possible, given the information provided. If any information you need is not given explicitly, make realistic assumptions and document them.

"The Quenda School of Motoring has a fleet of dual control vehicles and a number of trained driving instructors, and provides a range of driving lesson options for its customers.

The QSM now needs a new system to keep track of the driving lessons it offers. The systems analyst has commenced the requirements analysis and has provided a set of notes for you to draw a domain model class diagram, as follows:

• Each vehicle in the fleet has a registration number, make, model, and transmission type (automatic or manual).
• Each instructor's name, address, date of birth, contact phone number, and email are stored, along with their drivers' license details (license number, class and expiry date).
• Lessons are offered either as single lessons or as more economical lesson packages. Lesson packages are available in a range of number/prices: 2, 3, 5, or 10 lessons.
• Information held about customers is their name, address, date of birth, provisional
driver's license number, contact phone number and email.
• Each lesson is 45 minutes long, and is booked for one customer at a time, with a single instructor and vehicle.
• The customer may have a different instructor or vehicle on each occasion. Instructors can use any vehicle. The customer name, start time and date of the lesson are recorded when the lesson is booked. Information about the instructor and vehicle are recorded
later when the day's schedule is drawn up.
• After the lesson, the instructor records the start and end mileage in the lesson log, and makes any relevant notes about the customer's progress. These log notes are available to other instructors for the customer's subsequent lessons."