RSA Case Study

1. RSA Case Study

2. 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 year-olds, & 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. RSA Problems

3. 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. RSA Problems

4. 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. RSA Problems

5. 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. Suggested Solutions

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

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

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

9. Expanded Use Case FormatUse Case: Record Player Information 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 FormatUse Case: Record Player Information Typical course of actions: 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 FormatUse 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 FormatUse Case: Register Player in league Typical course of actions:

13. Expanded Use Case FormatUse Case: Register Player in league Typical course of actions: (cont.) 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. 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 Conceptual Model

16. 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 [Att. = DoBstatus] • Payment Concepts Attributes RS / Multiplicity Conceptual Model

17. Session Volunteer Equipment Umpire Year Season Start Date End Date Name Role Phone Name Description Name Salary ManagedBy * 1..* 1 1..* 1..* Register 1 Player Monitor Include ^ * UsedIn 1..* ID Name DoB DoB Status Insurance: Boolean Address Phone Email 1 * Game Schedule Registration UI League parent Registers in ID Date Time Name Fee Name Fee 1 1 1..* 1 1 Play Include 1..* Make EnrollIn 1..* 1 Payment Team Coach 2 Date Amount Name Uniform Name Salary 1 TrainedBy Conceptual Model 1 1