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, year-olds, year-olds, & 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, 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. Register Player in league
Use Case Diagram
Record Player info
Parent
Register Player in league
<<includes>>
<<extends>>
RSA Volunteer
Add to team
Become a volunteer
NEW Volunteer
Order uniform
Order equipment
Recruit coach
Recruit umpire
Organize schedule

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:
System Response
Actor Action
2. The system shows a new player registration form.
1. This use case begins when a parent requests new player registration form.
3. The parent fills in the player name, DOB and other mandatory details.
5. The system checks the mandatory info, the player’s age and displays the registration number, registration status and the registration deadline.
4. The parent submits the player form.
7. The system shows a confirmation letter.
6. The parent requests 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
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:
System Response
Actor Action
1. This use case begins when a parent arrives at RSA office with the registration pending letter.
3. Displays the player form.
2. The volunteer enters the registration number.
4. The volunteer requests the player birth certificate.
5. The parent shows the birth certificate to the volunteer.
7. The system show fees.
6. The volunteer confirms the DOB.
8. The volunteer requests payment from the parent.
9. Parent pays the fees.
11. Confirms the registration and shows the balance.
10. The volunteer records the payment amount.

13. Expanded Use Case Format Use Case: Register Player in league
Typical course of actions: (cont.)
System Response
Actor Action
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.
16. The system generates the receipt.
15. The volunteer requests a receipt for the parent.
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

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
Age
# of players
# of teams
Coach
League schedule
Address
Phone number
[Att. = DoBstatus]
Payment
Concepts
Attributes
RS / Multiplicity

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