1 RSA Case Study 2 RSA Problems Consider

1 RSA Case Study

2 RSA Problems Consider the following Case: The case study focuses on the non-profit Riyadh Soccer Association (RSA) which has no paid employees and thus uses only volunteer labor. The RSA sponsors youth Soccer teams at four different levels or leagues: 8 -10 year-olds, 11 -13 year-olds, 13 -15 yearolds, & 15 -19 year-olds. For each league, the RSA charges players’ fees, designed to cover the cost of players’ uniforms, players’ insurance, umpire costs, periodic league provided equipment replacement, and other overhead costs of running the league. In addition, the players’ fees have a portion built-in to generate a reserve fund to meet unforeseen contingencies. Each year, before the season begins, RSA volunteers hold player registration sessions. During these sessions, parents of the players complete registration forms, pay the players’ fees, and provide a birth certificate as proof of the player’s age. All the registration data is collected in paper form. These sessions are held in early spring or late winter in order to allow the RSA to forecast the number of players in each league. These numbers and the resulting forecast are critical to determine the number of teams needed, order uniforms, assign or purchase equipment, recruit coaches, and developed league schedules.

3 RSA Problems This registration process has produced several difficulties in recent years. First, while the registration sessions are reasonably well advertised, each year a number of players fail to register at these sessions and thus register late. As a result, the forecasts of the number of players in each league tend to be inaccurate causing difficulties in arranging teams, coaches, uniforms, and schedules. Second, a number of parents do not pay the players’ fees at the time of registration, producing cash flow problems. Third, the record keeping required by these registration sessions is cumbersome. The record keeping includes tracking who registered and in which league, who has paid their players’ fees, and who has provided proof of age. Additional information collected at registration that is used by the RSA include a mailing address, phone number, email address, and whether or not the parent will volunteer to help the RSA (e. g. , keep score, work the concession stand). An attempt has been made to collect and store the registration data in a database for one of the leagues. However, all the data had to be entered manually during the registration sessions, which was rather slow and cumbersome. The RSA is considering how to best address these problems with an information system.

4 RSA Problems Well advertised, but late registration. Late payment: parents do not pay the players’ fees at the time of registration. Cumbersome records and difficult to find the required information. Manual registration.

5 Suggested Solutions We need an online information management system. The system should offer online newsletter subscriptions to improve the advertising about the registration period. The Parents record the player’s information online, and receive a pending registration confirmation. In order to confirm the registration and gets a player ID, the parent must complete the registration at the RSA office by showing the required documents (Birth certificate) and paying the fees. Registration closed when the registration “end date” is reached.

6 Assumptions Coaches and umpires are not volunteers. A Player registers in one session only. Fees payment in cash only.

7 UCD & the expanded description of the two most important use cases.

8 Use Case Diagram Record Player info Register Player in league <<includes>> Add to team RSA Volunteer Parent <<extends>> Become a volunteer Order uniform Order equipment Recruit coach Recruit umpire Organize schedule NEW Volunteer

9 Expanded Use Case Format Use Case: Record Player Information Actor: Parent Purpose: Completes the mandatory information about a player online. Overview (Success scenario): The parent requests a new player registration form. The parent fills in the mandatory information. On completion, the parent submits the form and receives a pending registration number. Type: Primary, Essential Cross References: None

10 Expanded Use Case Format Use Case: Record Player Information Typical course of actions: Actor Action 1. This use case begins when a parent requests new player registration form. System Response 2. The system shows a new player registration form. 3. The parent fills in the player name, DOB and other mandatory details. 4. The parent submits the player form. 5. The system checks the mandatory info, the player’s age and displays the registration number, registration status and the registration deadline. 6. The parent requests a confirmation letter. 7. The system shows a confirmation letter. 8. The parent completes the registration. Alternatives: Line 5. If mandatory fields are not completed, displays a message and don’t allow the registration. Line 5. If the player is above or below age, displays a message and don’t allow the registration.

11 Expanded Use Case Format Use Case: Register Player in league Use Case: Register Player in League Actor: Parent, RSA Volunteer Purpose: Confirms the registration and pays the fees on time. Overview (Success scenario): A parent arrives at the RSA office and shows the pending registration number and the required document to the RSA Volunteer. The RSA volunteer confirms the registration, receives fees payment from the parent and adds a player to a team in league. On completion, the player registration is confirmed. Type: Primary, Essential Cross References: UCs: Parent must have completed the Record Player Information use case.

12 Expanded Use Case Format Use Case: Register Player in league Typical course of actions: Actor Action System Response 1. This use case begins when a parent arrives at RSA office with the registration pending letter. 2. The volunteer enters the registration number. 3. Displays the player form. 4. The volunteer requests the player birth certificate. 5. The parent shows the birth certificate to the volunteer. 6. The volunteer confirms the DOB. 7. The system show fees. 8. The volunteer requests payment from the parent. 9. Parent pays the fees. 10. The volunteer records the payment amount. 11. Confirms the registration and shows the balance.

13 Expanded Use Case Format Use Case: Register Player in league Typical course of actions: (cont. ) Actor Action System Response 12. The volunteer deposits the cash received, extracts the balance & gives the balance to the parent. 13. See <<include>> Add to team. 14. If the parent wants to be a volunteer; see <<extends>> Become a volunteer. 15. The volunteer requests a receipt for the parent. 16. The system generates the receipt. 17. The parent leaves with the registration confirmation receipt. Alternatives: Line 5. If parent didn’t bring the birth certificate, don’t complete the registration. Line 6. If the date of birth is not accepted, cancel the registration. Line 10. If the amount paid is not enough, don’t complete the registration.

14 Conceptual Model

15 Conceptual Model What are the objects (concepts) the real things in my domain ? • • • Non paid employees (volunteers) Team League Player Fee Player uniform Player insurance Umpire Equipment Season Registration session Parent • • • Registration form Birth certificate Age # of players # of teams Coach League schedule Address Phone number Email

16 Conceptual Model What are the objects (concepts) the real things in my domain ? • • • Non paid employees (volunteers) Team League Player Fee Player uniform Player insurance Umpire Equipment Season Registration session Parent • • • Registration form Birth certificate [Att. = Do. Bstatus] Age # of players # of teams Coach League schedule Address Phone number Email Payment Concepts Attributes RS / Multiplicity

17 Conceptual Model Session Year Season Start Date End Date 1 Volunteer Managed. By * 1 1. . * Name Role Phone Include ^ Registers Name in 1 Fee 1 Make Payment Date Amount 1. . * Player ID Name Do. B Status Insurance: Boolean Address Phone 1 Email 1. . * Enroll. In 1 Monitor Used. In 1. . * 1 Game Schedule League ID Date Time Name Fee 1. . * 1 y Pla Include 1. . * Team 1 Name Salary 1. . * * Registration UI Umpire Name Description Register * parent Equipment Name Uniform Coach 2 Trained. By 1 1 Name Salary