Requirements Analysis Document
Indoor Cricket Online Database System
Group F
Professional Computing 307
Semester 2, 2004
UNIVERSITY OF WESTERN AUSTRALIA
Version 1.1
Revision History
Dates of TasksWednesday 4th August 2004, Created template for deliverable A.
Thursday 5th August 2004, Added Sections 1.0-3.1.
Friday 6th August 2004, RAD updated, version 1.0 submitted to client.
Monday 9th August 2004, RAD updated, version 1.1 submitted to client.
Tuesday 10th August 2004, RAD updated, version 1.2 submitted to client.
Tuesday 24th August 2004, RAD updated, version 1.3 submitted to client.
Preface:
This document delineates the requirements for the Indoor Cricket Online Database System. The intended audiences for this document are the developers, programmers, the project mentor and the client of the project.
Target Audience:
Client, Developers, Programmers and Project Mentor.
Group F Members:
Thomas Fitzpatrick (PM)
Tristan Quick
Jean Eu
Benjamin Kuek
William Choong
Sanandanan Somasekaran
Brinley Ang
Milestones:
19/07/04 Release of RAD Template (STARS PROJECT)
6/8/04 RAD revision by client
10/8/04 Final RAD revision by client before submission
11/08/04 Deliverable A Due
24/08/04 Deliverable B Due
08/10/04 Deliverable C Due
21/10/04 Deliverable D Due
Client Sign Off:
I, ______, have read the Online Indoor Cricket Database (OICD) RADand am in agreement with the requirements listed within.
Clients signature: ______Date: ______
Contents Page
1.0GENERAL GOALS
2.0CURRENT SYSTEM
3.0PROPOSED SYSTEM
3.0.1Meeting Schedule
3.0.2Schedule of Client and Mentor Meetings
3.1Overview
3.2Functional Requirements
3.2.1Store/Create Team Profiles (Priority 2)
3.2.2Delete Team Profiles (Priority 3)
3.2.3Edit Team Profiles (Priority 2)
3.2.4Store/Create Player Profiles (Priority 1)
3.2.5Delete Player Profiles (Priority 3)
3.2.6Edit Player Profiles (Priority 1)
3.2.7Store Indoor Cricket Scorecard Data per Game (Priority 1)
3.2.8Delete Scorecard Data (Priority 3)
3.2.9Edit Scorecard Data (Priority 1)
3.2.10Generate Player Statistics (Priority 1)
3.2.11Generate Team Statistics (Priority 1)
3.2.12Store and Display Player Payment Details including paying player of the week (Priority 1)
3.2.13Statistics should be dynamically displayed on request (Priority 2)
3.2.14Monitor and Display Game Points (Priority 3)
3.2.15Monitor and Display Game Awards (Priority 3)
3.2.16Logon facility will be provided for the administrator to control access (Priority 2)
3.2.17Administrator password will be changeable (Priority 3)
3.2.18User Accounts will be locked after three (3) logon attempts (Priority 4)
3.2.19Allow Administrator to change fields. (Priority 2)
3.2.20Search for specific scorecards according to user-specified criteria (Priority 1)
3.2.21Generate web pages to view all information available on the system (Priority 1)
3.3Non-Functional Requirements
3.3.1User Interface and Human Factors
3.3.2Documentation
3.3.3Hardware Consideration
3.3.4Performance Characteristics
3.3.5Error Handling and Extreme Conditions
3.3.6System Interfacing
3.3.7Quality Issues
3.3.8System Modifications
3.3.9Physical Environment
3.3.10Security Issues
3.3.11Resource Issues
3.4Constraints
3.5System Model
3.5.1Scenarios
3.5.2Use Case Models
3.5.3Object Models
3.5.4Dynamic Models
3.5.5User Interface – Navigational Paths and Screen mock-ups
4.0GLOSSARY
1.0GENERAL GOALS
The Online Indoor Cricket Database (OICD) will store information regarding indoor cricket matches for a given team. It will store records of individual games, individual players, and payment information. This information and statistics regarding this information will be available online. The ability to update and modify the online database will be confined to an administrator who will have to log on to the administrator’s view of the system.
The system will be responsible for designating the next payer according to an algorithm stipulated by the client and specified in section 3.2.12.
The system will calculate total runs for a given skin, and for the game as a whole to indicate the winner.
The system will calculate and store points for individual players over the season.
The system will be able to add new players and flag players as absent and hence exempt from paying.
Upon request, the system will calculate and show statistics regarding the comparative performance of teams and individual players across the season by querying the stored records.
2.0CURRENT SYSTEM
The current system uses manual recording and entry by the client in the form of a paper game score card. Once the scores have been written onto the score card, the data is taken from the scorecard and manually entered into a standard text file. The data from the text file is then extracted, collated and summarized into a basic format to be placed in a webpage. The client uses custom tags to generate the website for read-only viewing by the players. The current system is also not capable of performing many of the calculations to generate statistics that the client has a wish list for. The current system is also far from user friendly, in that only an advanced user may make use of it.
3.0PROPOSED SYSTEM
3.0.1Meeting Schedule
There are currently three scheduled Mentor meetings just prior to submission of the project Deliverables. These meetings are held on Fridays in a staggered fashion to assist with the deliverables before their respective due dates.
Client meetings will be held every Wednesday at 11am with Luigi Barone in Computer Science Laboratory 2.9. These meetings will be used to elicit requirements, review implementations and sign off deliverables.
Team meetings will be held on a first come first serve basis in the Computer Science labs. Team meetings may be called by any member at any time to assist the team member in problem solving as soon as possible.
3.0.2Schedule of Client and Mentor Meetings
The following table delineates the planned meeting schedule with the client and mentor. The meetings will assist the team in solving several issues.
Date / Time / Venue / People present / DurationWed Weekly / 11:00am / CS Labs / PC307f team & Luigi Barone / 1hr
Thurs Weekly / 9:00am / CS Labs / Jean, Tristan, William & Tom / 2hrs
Friday 30th July / 12:00pm / Motorola / PC307f team & Michelle Britto / 1hr
Friday 03rd September / 12:00pm / Motorola / PC307f team & Michelle Britto / 1hr
Friday 15th October / 12:00pm / Motorola / PC307f team & Michelle Britto / 1hr
3.1Overview
The aim of the OICD is to design a user-friendly web based database application to allow the client to store “ball by ball” data of weekly cricket games to generate statistics for viewing on the internet. The system must also handle other relevant information about indoor cricket, such as payments, team awards, points and player profiles. The web aspect will be dynamic and provide a powerful tool for the client to view, create, update, edit and delete data from the database. The database will be a cost effective and portable way of displaying read-only Indoor Cricket statistics in varying forms, such as graphs, pie-charts and tables. The new system will integrate much of the current system functionality, but will provide a modern approach with far greater capabilities.
The key objectives for this project include:
- To provide a secure way for the client to view, create, update, edit and delete data from the database in a web format.
- To generate several valid Indoor Cricket Statistics. This will be done by the system after the client enters the scorecard data into the database. Details of this are provided in sections 3.2.10-3.2.11.
- Provide user-friendly and attractive read-only web pages to convey the information generated by querying the database.
- Support changeability and expandability for future requirements.
3.2Functional Requirements
The system must be capable of meeting numerous requirements, as follows;
3.2.1Store/Create Team Profiles (Priority 2)
When an administrator is logged on he/she can create a team profile on the web page. The system will allow the administrator to create team profiles with several properties including information about the team captain, players, team name, and team photo.
3.2.2Delete Team Profiles (Priority 3)
The system will provide a facility for the administrator to delete team profiles when appropriate. This is optional, as an administrator may want the information to reside on the database for historical purposes. When logged on appropriately, an administrator may simply select a team and perform a delete command in the form of a button click.
3.2.3Edit Team Profiles (Priority 2)
The system will provide a facility for the administrator to edit team profiles when appropriate. When logged on, an administrator may simply select a team and edit team profiles in a similar manner to when a team was created. An administrator may edit statistics if they are erroneous.
3.2.4Store/Create Player Profiles (Priority 1)
The system will allow the administrator to create individual player profiles to be stored on the database for statistics and viewing purposes. The player profile will consist of data such as; Name, alias/call sign, Email address, Date of Birth, position, player photo, right/left handed, fielding position andbowling pace (medium fast, fast medium, medium slow, slow medium or off-spin).
3.2.5Delete Player Profiles (Priority 3)
The system will provide a facility for the administrator to delete player profiles as necessary. This is optional, as an administrator may want the information to reside on the database for historical purposes. When logged on, an administrator may simply select a player and perform a delete command in the form of a button click.
3.2.6Edit Player Profiles (Priority 1)
The system will provide a facility for the administrator to edit player profiles when necessary. When logged on, an administrator may simply select a player and edit individual player profiles in a similar manner to when a player was created. An administrator may then edit erroneous statistics. The edit facility is important as a player may no longer be “active”, that is actively playing with the team. The administrator may “flag” that the player is no longer active. This prevents unneeded player data being placed in team statistics.
3.2.7Store Indoor Cricket Scorecard Data per Game (Priority 1)
The system will provide a dynamic facility for the administrator to enter ball by ball data from the original game scorecard. This is the most important facility and it should mimic the original scorecard to increase usability. The score card will contain data including the date of game, time, team names, venue played, pitch played on, fairest and best awards (including the teams that the players belonged to, See 3.2.15), a break down of the game points (See 3.2.14), batters, bowlers, runs scored per ball, wickets per ball (including type: “C” = catch, “ST” = stumping, “RO” = runout, “B” = bowled, “W” = out, but the manner of the wicket is unspecified), and dot balls. Data such as the score per over, score per innings, partnership scores, running totals and final totals should be automatically accrued as each score element is placed onto the score sheet. The player who was facing should be inferred from the score card as there will be no number next to their name indicating a score. Data that should not be recorded includes wides and no balls as they will be shown intuitively in the form of 1’s and 2’s.
3.2.7.1Allow game anomalies to be handled by providing interactive page properties.
The system should be robust enough to handle certain rare game anomalies. These include; up to 10 balls may be played in the fourth over of a partnership, a partnership may be 3, 4 or 5 overs long by mistake, information may not be known so the database must handle “null” information (such as Date of Birth, position, runs scored on a particular ball etc) and different pay rates per game (price goes up/down).
The system should however verify that the game being entered is legitimate by insuring that a total of 16 overs have been entered.
3.2.8Delete Scorecard Data (Priority 3)
The system should support the deleting of scorecard data even after the data has been stored. This is provided so the administrator can correct mistakes or perform database cleaning. This is provided once the administrator has successfully logged in. A save function must be provided to save changes.
3.2.9Edit Scorecard Data (Priority 1)
Similar to 3.2.6 the system provides the administrator with a facility to correct mistakes, input data at a later date if the data was unknown at the time and to perform checks to ensure the data was correct in the first place. This is provided once the administrator has successfully logged in. A save function must be provided to save changes.
3.2.10Generate Player Statistics (Priority 1)
The system will generate a wide range of PLAYER statistics that are inferred from the scorecard data entered prior to this. The system will generate a range of GUI functions such as graphs, tables, pie-charts and incorporate player profile details. Through a series of database queries, statistics will be generated and displayed for read-only viewing on the internet in web format. These statistics are formed on a seasonal basis and include:
- Games
- Innings
- Batting Statistics (See 3.2.10.1)
- Bowling Statistics (See 3.2.10.2)
- Contribution = (Runs scored (batting) – runs conceded (bowling))
- Catches
- Votes
- Average Contribution Per Game
- Average Catches Per Game
- Average Votes Per Game
- Average Points Per Game = (+0.5 for batting skin, +0.25 for bowling skin)
- Highest Runs Scored *
- Best Bowling = lowest runs conceded *
- Most Catches in a game *
- Highest Contribution *
- Best Partnership (highest runs scored) *
- Most 6’s scored in a game *
3.2.10.1Batting
The following is a list of the required statistics that the system will store:
- Runs Scored
- Innings
- Wickets Lost
- Balls Faced
- Runs break down (See 3.2.7)
- Average = Runs Scored / Wickets Lost
- Strike Rate = (Runs Scored / Balls Faced) * 100
- Average Runs Scored / Innings
- Average Wickets Lost / Innings
3.2.10.2Bowling
The following is a list of the required statistics that the system will store:
- Runs Conceded
- Innings
- Balls Bowled
- Wickets Taken
- Runs Break Down (See 3.2.7)
- Average = Runs Conceded / Wickets Taken
- Strike Rate
- Average Runs Conceded / Innings
- Average Wickets Lost / Innings
3.2.10.3Player Records
These statistics show records or exceptional achievements of team members, such as:
- Highest Runs Scored *
- Best Bowling = Lowest Runs Conceded *
- Most Catches in a game *
- Highest Contribution *
- Best Partnership (Highest Runs Scored) *
- Most 6’s Scored in a Game *
* These entries require information about the statistic, such as runs scored, plus information about the date and the opponent.
3.2.11Generate Team Statistics (Priority 1)
The system will generate a wide range of TEAM statistics that are inferred from the scorecard data entered prior to this. The system will generate a range of GUI functions such as graphs, tables, pie-charts and incorporate team profile details. Through a series of database queries, statistics will be generated and displayed for read-only viewing on the internet in web format. The original scorecard data will also be provided upon request. These statistics are formed on a seasonal basis and include:
- Average Skins Won Per Game
- Games Played
- Games Won
- Games Lost
- Skins Won
- Total Points
- Highest Score *
- Lowest Score *
- Highest Runs Against a Team (Overall) *
- Lowest Runs Against a Team (Overall) *
- Highest Winning Margin *
- Lowest Winning Margin *
3.2.12Store and Display Player Payment Details including paying player of the week (Priority 1)
As an additional facility, the system will allow anadministrator to track who has paid for the correct number of games, who has actually played in certain games if they are liable to pay and who should be paying for the upcoming game. The last facility will be displayed in the form of a flag or identifier to delineate who will pay next. This may be calculated by;
Payer = Lowest(Total Amount paid / Total games played)
If this formula yields more than one possible payer the system will designate the one that has paid the least over the season, and if there is still more than one payer the system will designate the payer who has played least recently. Players can be flagged as absent and therefore exempt from payment for the duration of their absenteeism.
3.2.13Statistics should be dynamically displayed on request (Priority 2)
The system will provide a facility for the administrator to update the current web page information on request. This will follow a simple implementation of a button press.
3.2.14Monitor and Display Game Points (Priority 3)
This is another additional facility to calculate and display points accrued per game, provided by the system. The administrator does not need to enter the game points data as it should be inferred from the score card. Points are awarded as follows; a win awards 3 points, a team paying on the spot awards 3 points, a point for every skin (by comparing partnerships and awarding a point to the highest scoring partnership), a point for every 20 runs the team scores at the end of the match (inferred from team final scores). The system should also provide the flexibility to change these business rules.
3.2.15Monitor and Display Game Awards (Priority 3)
The system will store the fairest and best game awards for read-only viewing via web facilities. This cannot be inferred as it is up to the judgment of the teams on the day. An administrator will input the awards when entering the data in the initial scorecard. There will also be a summary web page to display all the game awards for a given team.
3.2.16Logon facility will be provided for the administrator to control access (Priority 2)
The system will provide a logon facility for the administrator to verify their identity to strengthen the integrity of the database. Currently, there are only 2 levels of access. One is the administrator account which gives him/her full access and control, and the other is a read-only access which is only accessible by viewing the information online. All other forms of access to the raw data will be restricted.
3.2.17Administrator password will be changeable (Priority 3)
The system will allow an administrator to change the logon password for security purposes. Upon proving identity by entering the old password, the administrator may stipulate the new password and the system will store it as required.
3.2.18User Accounts will be locked after three (3) logon attempts(Priority 4)
The system will provide a fail safe mode of logon attempts by disabling a user account for 30 minutes when a logon attempt fails 3 times.