Golf Management System

Golf Club Membership System Software Engineering David O' Connor t00130990

Golf Club Membership System

Software Engineering: Catherine Woods

Submitted By: David O’ Connor (KCOMP_G_Y6)

Submitted on: 19th December 2014

of 42


Table of Contents

1. Introduction........................................................................................................................................4

2. Functional Requirements....................................................................................................................5

3. User Requirements.............................................................................................................................6

3.1. The system performs rate management....................................................................................6

3.2. The system performs member administration...........................................................................6

3.3. The system performs finance management...............................................................................6

3.4. The system will perform Golf Club administration....................................................................6

4. System Requirements.........................................................................................................................7

4.1. System Level Use Case................................................................................................................7

4.2. Rates Management.....................................................................................................................7

4.2.1. Create Member Type...........................................................................................................8

4.2.2. Change Member Type........................................................................................................10

4.3. Member Management..............................................................................................................12

4.3.1. Register Member................................................................................................................12

4.3.2. Amend Member.................................................................................................................15

4.3.3. De-Register Member..........................................................................................................17

4.3.4. List Members.....................................................................................................................19

4.4. Finance Management...............................................................................................................21

4.4.1. Issue Member Invoice........................................................................................................21

4.4.2. Issue Renewal Notice.........................................................................................................23

4.4.3. Record Payment.................................................................................................................25

4.5. Admin........................................................................................................................................27

4.5.1. Income Analysis................................................................................................................27

4.5.2. Member Analysis...............................................................................................................29

4.5.3. List Late Fees.....................................................................................................................31

5. System Model...................................................................................................................................33

5.1. Data Flow Diagrams – Elements...............................................................................................33

5.2. Level-0 DFD...............................................................................................................................34

5.3. Level-1 DFD...............................................................................................................................35

5.4. Level-2 DFD – Process P1..........................................................................................................36



of 42



6. Data Model.......................................................................................................................................40

7. Database Schema..............................................................................................................................41

8. Program Specifications.....................................................................................................................42

9. Conclusion.........................................................................................................................................43

10. References:....................................................................................................................................44

of 42


1. Introduction

This system will allow a golf course to manage their day to day activities with regard to the management of their business with respect to membership management and day to day activities of running a successful golf course. This system will allow the user to register new members within the golf course and manage their memberships in an effective manner. The system shall store all information related to each member of the golf course their membership type, their next renewal date, etc. The user will be able to access all information about golf course members

of 42


2. Functional Requirements

of 42

Golf Club Membership

System

Rates

Create Member Type

Change Member Type

Members

Register Member

Amend Member

De-Register Member

List Members

Finance

Issue Member Invoice

Issue Renewal Notice

Record Payment

Admin

Income Analysis

Member Analysis

List Late Fees


3. User RequirementsThe following user requirements have been identified for the system (Golf365):

3.1. The system performs rate management3.1.1. Golf365 will allow to create membership type3.1.2. Golf365 will allow to change membership type

3.2. The system performs member administration3.2.1. Golf365 will allow the details of each new member to be recorded 3.2.2. Golf365 will allow a member’s details to be amended3.2.3. Golf365 will allow the de-registration of a member 3.2.4. Golf365 will generate a member listing

3.3. The system performs finance management3.3.1. Golf365 will issue invoices to members 3.3.2. Golf365 will allow to issue renewal notices to members3.3.3. Golf365 will record membership payment transaction

3.4. The system will perform Golf Club administration3.4.1. Golf365 will perform income analysis3.4.2. Golf365 will perform member analysis3.4.3. Golf365 will list late membership fees

of 42


4. System Requirements

4.1. System Level Use Case

4.2. Rates ManagementThe system has two essential requirements in relation to the management of rates data. The creation of member types and the changing of member types.

of 42

Process Rates

Administrator

Manage Members

Manage Finance

Process Admin

MemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMember

AdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministrator


4.2.1. Create Member Type

Details of all membership types are held in the system.

Use Case Name Create Member TypeUse Case Id 1Priority 1Source ManagementPrimary Business Actor Administrator Other Participating ActorsDescription This function creates a new member type.PreconditionsTrigger Administrator wishes to create a new member type.Typical Scenario Actor Action System Response

Step 1: The Administrator invokes the create member type function.

Step 3: The Staff member enters the required data:

Title of member type Description Fee

Step 4: The Staff member confirms the member type is to be created

Step 2: The system displays the UI.

Step 5: The system validates the input data:

All field are required Fee must be greater than

zero

Step 6: The system stores the new member type in the Member file.

Step 7: The system displays a confirmation message.

Step 8: The system resets the UI.

of 42

Create Member Type

Administrator Validate Member Type

<<includes>>



Alternate Scenarios Actor Action System ResponseA required field is not entered

Step 5: A required field is not entered

Step 6: The system displays an appropriate error message

Conclusions New member type is createdPost conditionsBusiness RulesImplementation Constraints

of 42


4.2.2. Change Member Type

Member types can be changed at any time (new age category, etc). Existing members can

Use Case Name Change Member TypeUse Case Id 2Priority 2Source ManagementPrimary Business Actor Administrator Other Participating ActorsDescription The staff member wishes to change member type.PreconditionsTrigger Administrator wishes to change a member type.Typical Scenario Actor Action System Response

Step 1: The staff member invokes the change member type function.

Step 3: The staff member selects the required member type to be changed.

Step 5: The staff member makes the required amendments.

Step 2: The system retrieves membership type details from the Rates and displays on the UI.

Step 4: The system displays the details for the selected member type on the UI.


All field are required Fee must be greater than

zero

Step 7: The system saves the amended member type details in the Member file.

of 42

Change Member Type

Administrator

Validate Member Type

<<includes>>




Step 9: The system resets the UI.Alternate Scenarios Actor Action System ResponseA required field is not entered

Step 6: A required field is not entered.

Step 7: The system displays an appropriate error message.

Conclusions Member type is changedPost conditionsBusiness RulesImplementation Constraints

of 42


4.3. Member ManagementThe system has five essential requirements in relation to the management of member data. The registering of members, amending members, de-registering members, the listing of members and also the issuing of member invoice.

4.3.1. Register Member

Details of all golf course members must be held within the system. Each new member is assigned a unique member identification number (Mem_ID) which is assigned by the system.

Use Case Name Register New MemberUse Case Id 3Priority 1Source ManagementPrimary Business Actor AdministratorOther Participating ActorsDescription This function registers a new member of the golf club on the system.Preconditions First fee payment must have been received from the member.Trigger Member requests to gain membership to Golf course.Typical Scenario Actor Action System Response

Step 1: The staff member invokes the register member function.

Step 5: The staff member enters the required member details:

Step 2: The system determines the next Mem_Id.

Step 3: The system retrieves membership type details from the Rates file.


of 42

Register Member

AdministratorValidate

Member Type

<<includes>>




Surname Forename Address Email Phone DOB Membership Type

Step 6: The staff member confirms that the registration is to proceed Step 7: The system validates the

input data: All fields are required DOB must not be in the

future DOB must be compatible

with membership type

Step 8: Registration date is assigned the system date

Step 9: Member status is assigned the default status ‘active’

Step 10: Next renewal date is set to system date plus one year.

Step 11: The system stores the member details in the Member file

Step 12: The system determines the next Pay_Id and stores payment details in the Payments file:

Pay_Id Payment Date Amount Mem_Id

Step 13: The system displays a confirmation message




Conclusions The new member is registered

of 42


Post conditions Member must have valid Identification to become a new member.Business Rules Junior member must be under 18.Implementation Constraints

of 42


4.3.2. Amend Member

Use Case Name Amend MemberUse Case Id 4Priority 1Source MembersPrimary Business Actor AdministratorOther Participating Actors MemberDescription Member of Staff wishes to amend details of member.Preconditions Member must be an active member.Trigger Administrator requests to amend member’s details.Typical Scenario Actor Action System Response

Step 1: The staff member enters the Mem_Id.

Step 4: The staff member enters the details to be amended:

Surname Forename Address Email Phone DOB Membership Type

Step 6: The staff member confirms that the registration is to proceed

Step 2: The system retrieves Mem_Id from the Members file



All fields are required DOB must not be in the

future DOB must be compatible

with membership type

Step 7: The system stores the amended member details in the Member file

Step 8: The system displays a confirmation message

of 42

Amend Member


Member Type

<<includes>>







Conclusions The amended details are updatedPost conditions Member must have valid Identification to amend their details on the

system.Business RulesImplementation Constraints

of 42


4.3.3. De-Register Member

Use Case Name De-Register MemberUse Case Id 5Priority 2Source MembersPrimary Business Actor AdministratorOther Participating Actors MemberDescription Member wishes to de-register as a member of golf course.Preconditions Must hold full membership in order to de-register from golf course

membership.Trigger Member requests to de-register membership with Golf course.Typical Scenario Actor Action System Response

Step 1: The staff member invokes the de-register member function.

Step 3: The staff member enters the Mem_Id.

Step 6: Staff member enters ‘yes’.

Step 2: The system requests Mem_Id.

Step 4: The system retrieves the information associated with the Mem_Id.

Step 5: The system asks user ‘Are You Sure You Want To De-Register Member’.

Step 7: Member status is assigned the default status ‘de-active’


Alternate Scenarios Actor Action System Response

of 42

De-Register Member

Administrator MemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministrator


Conclusions The member is de-registeredPost conditions Member is no longer a member of the golf club.Business Rules Only an active member can be de-registered.Implementation Constraints

of 42


4.3.4. List Members

Use Case Name List MembersUse Case Id 6Priority 1Source AdminPrimary Business Actor AdministratorOther Participating ActorsDescription This function requires the system to produce a list of all club member

which can be presented in order of name, membership details or membership type.

Preconditions Members must be registered on the golf membership system before they can be listed

Trigger Administrator requires a list of all current members.Typical Scenario Actor Action System Response

Step 1: The administrator requests a list of all current golf course members.

Step 3: The administrator specifies a sort order for the listing

Surname Forename Membership Type

Step 6: The administrator enter “Yes” or “No”.

Step 2: The system retrieves details of all current members and displays them in order of name.

Step 4: The system retrieves the details of all current members and displays them in the order specified.

Step 5: The system issues a message “Do you wish to print data?”


of 42

List Members


Member Type

<<includes>>



No Member details found Step 3: The system alerts the administrator to the fact that there is no data available for the listing (A message is displayed on the User Interface)

Conclusions A listing of all current members within the golf course is generated.Post conditionsBusiness Rules Members’ details may only be viewed, not changed or deleted, when

displayed in this way.The list should only include current members.

Implementation Constraints

of 42


4.4. Finance ManagementThe system has two essential requirements in relation to the management of finance data. The issuing of renewal notices to members and also the recording of payment received from members.

4.4.1. Issue Member Invoice

Use Case Name Issue Member InvoiceUse Case Id 7Priority 1Source FinancePrimary Business Actor AdministratorOther Participating ActorsDescription This function issues member invoices.Preconditions Members must be registered on the golf membership system before an

invoice can be issued.Trigger Administrator requests invoice to issue to member.Typical Scenario Actor Action System Response

Step 1: The administrator requests issue member invoice.

Step 3: The administrator enters required Mem_Id.

Step 5: The user confirms that the invoice is to be issued to the member.


Step 4: The system retrieves details of the member from the Member file and displays on the UI.

Step 6: The system generates the invoice and issues it to member via email or post (if email isn’t on file).


of 42

Issue Member Invoice

AdministratorMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMember



Conclusions An invoice is issued to member.Post conditions Can only be issued to existing members.Business Rules Implementation Constraints

of 42


4.4.2. Issue Renewal Notice

Use Case Name Issue Renewal NoticeUse Case Id 8Priority 1Source FinancePrimary Business Actor AdministratorOther Participating ActorsDescription Admin wishes to issue renewal notice to memberPreconditions Members membership must be due to expiry within a month to be issued

a renewal notice.Trigger Administrator requires a renewal notice to be issued to member.Typical Scenario Actor Action System Response

Step 1: The administrator requests issue renewal notice.

Step 2: The administrator enters members whose renewal date is within a month.

Step 4: The user confirms that the invoice is to be issued to the member.

Step 3: The system retrieves details of all members from member file whose renewal date is within a month and displays on the UI.

Step 5: The system generates the invoice and issues it to member via email or post (if email isn’t on file).


Conclusions A renewal notice is issued to member.Post conditions Can only be issued to existing members.Business Rules

of 42

Issue Renewal Notice

AdministratorMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMember



Implementation Constraints

of 42


4.4.3. Record Payment

Use Case Name Record PaymentUse Case Id 9Priority 1Source FinancePrimary Business Actor AdministratorOther Participating ActorsDescription Admin wishes to record payment from memberPreconditions Must of received payment from memberTrigger Member pays membership fee.Typical Scenario Actor Action System Response

Step 1: The administrator invokes the record payment function.

Step 3: The administrator enters required Mem_Id.

Step 5: The administrator enters the amount received from member.

Step 7: Next renewal date is set by user.

Step 2: The system requests Mem_Id.

Step 4: The system retrieves details from member file and displayed on UI for User to enter payment details (amount).

Step 6: System checks that input data is valid and that the amount matches the fee due for the membership type.

Step 8: System stores details in the Payment file and next renewal date is updated in the member file.

Step 9: Receipt emailed to member Confirmation message displayed


of 42

Record Payment

Administrator MemberAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministrator MemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMemberMember


Conclusions A payment is recorded as received from memberPost conditions Member must have paid membership fee to record payment.Business Rules Implementation Constraints

of 42


4.5. AdminThe system has three essential requirements in relation to the management of admin data. The income analysis, member analysis and also the listing of any late fees outstanding.

4.5.1. Income Analysis

Use Case Name Income AnalysisUse Case Id 10Priority 1Source AdminPrimary Business Actor AdministratorOther Participating ActorsDescription Admin wishes to perform an income analysis.PreconditionsTrigger Admin requires an income analysis. Typical Scenario Actor Action System Response

Step 1: The administrator invokes the income analysis function.

Step 3: The administrator specifies a sort order for the listing (payment details, monthly income, etc.)

Step 6: The administrator enter ‘yes’ or ‘no’.

Step 2: The system retrieves details of income analysis from finance and displays the data in default order.

Step 4: The system retrieves the data of income analysis and displays them in the order specified.



of 42

Income Analysis

AdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministrator


Conclusions An income analysis is performed.Post conditionsBusiness RulesImplementation Constraints

of 42


4.5.2. Member Analysis

Use Case Name Member AnalysisUse Case Id 11Priority 1Source AdminPrimary Business Actor AdministratorOther Participating ActorsDescription Admin wishes to perform an income analysis.PreconditionsTrigger Admin requires a member analysis.Typical Scenario Actor Action System Response

Step 1: The administrator invokes the member analysis function.

Step 3: The administrator specifies a sort order for the listing (membership Id, membership details, surname, forename, etc.)


Step 2: The system retrieves details of member analysis from members file and displays the data in default order.

Step 4: The system retrieves the data of member analysis and displays them in the order specified.



Conclusions A member analysis is performed.

of 42

Member Analysis

AdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministratorAdministrator


Post conditionsBusiness RulesImplementation Constraints

of 42


4.5.3. List Late Fees

Use Case Name List Late FeesUse Case Id 12Priority 1Source AdminPrimary Business Actor AdministratorOther Participating ActorsDescription Admin wishes compile a list of members with late fees outstanding.Preconditions Members must be registered on the golf membership system and have

late fees outstanding.Trigger Admin requests a list of all late fees.Typical Scenario Actor Action System Response

Step 1: The administrator invokes the list late fees function.

Step 3: The administrator specifies a sort order for the listing; (membership type, membership details, surname, forename)


Step 2: The system retrieves details of late fees outstanding and displays them in default order.

Step 4: The system retrieves the details of all late fees and displays them in the order specified.


Alternate Scenarios Actor Action System ResponseNo Member details found Step 3: The system alerts the

administrator to the fact that there is no data available for the listing (A message is displayed on the User Interface)

of 42

List Late Fees

Administrator

Validate Member Type

<<includes>>



Conclusions A listing of all late fees of members within the golf course is generated.Post conditionsBusiness Rules The list should only include member with late fees outstanding. Implementation Constraints

of 42


5. System Model

5.1. Data Flow Diagrams – ElementsExternal Entities:

Member

Data Stores:

D1 Members FileD2 Rates FileD3 Payments File

Processes:

P1 Process Rates

P1.1 Create Member TypeP1.2 Change Member Type

P2 Manage Members

P2.1 Register MemberP2.2 Amend MemberP2.3 De-Register MemberP2.4 List Members

P3 Manage Finance

P3.1 Issue Member NoticeP3.2 Issue Renewal NoticeP3.3 Record Payment

P4 Process Admin

P4.1 Income AnalysisP4.2 Member AnalysisP4.3 List Late Fees

of 42


5.2. Level-0 DFD

of 42

Member

Golf 365

Member details

Membership Card

Payments

Notice

MemberDetails

MembershipType

PaymentDetails

Member TypeDetails

Rate Details

MemberDetails

MemberDetails

MemberDetails


5.3. Level-1 DFD

of 42

Member

ProcessRates

P1

Members FileD1

ManageMembers

P2

ManageFinance

P3

ProcessAdmin

P4

Rates FileD2

Payments FileD3

MembershipDetails

MembershipDetails


5.4. Level-2 DFD – Process P1

of 42

CreateMember

Type

P1.1

ChangeMember

Type

P1.2

Rates FileD2

Member TypeDetails

MemberDetails

MemberDetails

MemberDetails

MemberDetails

PaymentDetails



of 42

RegisterMember

P2.1

De-RegisterMember

P2.3

ListMember

P2.4

AmendMember

P2.2Members FileD1

Rates FileD2

Payments FileD3

Member

Member

Member

MemberDetails

MemberDetails

MemberDetails

PaymentDetails



of 42

IssueMemberInvoice

P3.1

IssueRenewalNotice

P3.2

RecordPayment

P3.3

Members FileD1

Payments FileD3

Member

MemberDetails

MemberDetails

PaymentDetails



of 42

IncomeAnalysis

P4.1

MemberAnalysis

P4.2

List Late Fee

P4.3

Members FileD1

Payments FileD3

Payments FileD3

1 …*

1

1 …*

1 …*

1

1


6. Data Model

of 42

RatesCreate Member Type {pk}Change Member Type

FinanceIssue Member InvoiceIssue Renewal NoticeRecord Payment {pk}

MembersRegister Member {pk}Amend MemberDe-Register MemberList Members

AdminIncome AnalysisMember Analysis {pk}List Late Fees


7. Database Schema

Schema: Golf365

Relation: RateAttributes:

Create Member Type char (10) NOT NULL,Change Member Type char (10) NOT NULL,PRIMARY KEY: Create Member TypeFOREIGN KEY:

Relation: Members Attributes:

Register Member char (10) NOT NULL,Amend Member char (10) NOT NULL,De-Register Member int (5),List Members char (10)PRIMARY KEY: Register Member

Relation: Finance Attributes:

Issue Member Invoice int (5),Issue Renewal Notice int (5),Record Payment int (5),PRIMARY KEY: Record PaymentFOREIGN KEY:

Relation: AdminAttributes:

Income AnalysisMember AnalysisList Late FeesPRIMARY KEY: Member AnalysisFOREIGN KEY:

of 42


8. Conclusion

of 42

Golf Management System

Software

Transcript of Golf Management System