Requirements Analysis Document



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 Tasks |

| |

|Wednesday 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) RAD and am in agreement with the requirements listed within.

Clients signature: __________________ Date: ______________

Contents Page

1.0 GENERAL GOALS 4

2.0 CURRENT SYSTEM 5

3.0 PROPOSED SYSTEM 6

3.0.1 Meeting Schedule 6

3.0.2 Schedule of Client and Mentor Meetings 6

3.1 Overview 7

3.2 Functional Requirements 7

3.2.1 Store/Create Team Profiles (Priority 2) 7

3.2.2 Delete Team Profiles (Priority 3) 7

3.2.3 Edit Team Profiles (Priority 2) 7

3.2.4 Store/Create Player Profiles (Priority 1) 8

3.2.5 Delete Player Profiles (Priority 3) 8

3.2.6 Edit Player Profiles (Priority 1) 8

3.2.7 Store Indoor Cricket Scorecard Data per Game (Priority 1) 8

3.2.8 Delete Scorecard Data (Priority 3) 9

3.2.9 Edit Scorecard Data (Priority 1) 9

3.2.10 Generate Player Statistics (Priority 1) 9

3.2.11 Generate Team Statistics (Priority 1) 11

3.2.12 Store and Display Player Payment Details including paying player of the week (Priority 1) 11

3.2.13 Statistics should be dynamically displayed on request (Priority 2) 11

3.2.14 Monitor and Display Game Points (Priority 3) 12

3.2.15 Monitor and Display Game Awards (Priority 3) 12

3.2.16 Logon facility will be provided for the administrator to control access (Priority 2) 12

3.2.17 Administrator password will be changeable (Priority 3) 12

3.2.18 User Accounts will be locked after three (3) logon attempts (Priority 4) 12

3.2.19 Allow Administrator to change fields. (Priority 2) 12

3.2.20 Search for specific scorecards according to user-specified criteria (Priority 1) 13

3.2.21 Generate web pages to view all information available on the system (Priority 1) 13

3.3 Non-Functional Requirements 14

3.3.1 User Interface and Human Factors 14

3.3.2 Documentation 14

3.3.3 Hardware Consideration 14

3.3.4 Performance Characteristics 14

3.3.5 Error Handling and Extreme Conditions 15

3.3.6 System Interfacing 15

3.3.7 Quality Issues 15

3.3.8 System Modifications 15

3.3.9 Physical Environment 15

3.3.10 Security Issues 16

3.3.11 Resource Issues 16

3.4 Constraints 17

3.5 System Model 18

3.5.1 Scenarios 18

3.5.2 Use Case Models 20

3.5.3 Object Models 42

3.5.4 Dynamic Models 43

3.5.5 User Interface – Navigational Paths and Screen mock-ups 55

4.0 GLOSSARY 59

GENERAL 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.

CURRENT 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.

PROPOSED SYSTEM

1 Meeting 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.

2 Schedule 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 |Duration |

|Wed Weekly |11:00am |CS Labs |PC307f team & Luigi |1hr |

| | | |Barone | |

|Thurs Weekly |9:00am |CS Labs |Jean, Tristan, William &|2hrs |

| | | |Tom | |

|Friday 30th July |12:00pm |Motorola |PC307f team & Michelle |1hr |

| | | |Britto | |

|Friday 03rd September |12:00pm |Motorola |PC307f team & Michelle |1hr |

| | | |Britto | |

|Friday 15th October |12:00pm |Motorola |PC307f team & Michelle |1hr |

| | | |Britto | |

2 Overview

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:

1. To provide a secure way for the client to view, create, update, edit and delete data from the database in a web format.

2. 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.

3. Provide user-friendly and attractive read-only web pages to convey the information generated by querying the database.

4. Support changeability and expandability for future requirements.

3 Functional Requirements

The system must be capable of meeting numerous requirements, as follows;

1 Store/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.

2 Delete 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 Edit 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.

4 Store/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 and bowling pace (medium fast, fast medium, medium slow, slow medium or off-spin).

5 Delete 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.

6 Edit 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.

7 Store 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.

1 Allow 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.

8 Delete 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.

9 Edit 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.

10 Generate 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 *

1 Batting

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

2 Bowling

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 Player 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.

11 Generate 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 *

12 Store and Display Player Payment Details including paying player of the week (Priority 1)

As an additional facility, the system will allow an administrator 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.

13 Statistics 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.

14 Monitor 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.

15 Monitor 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.

16 Logon 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.

17 Administrator 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.

18 User 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.

19 Allow Administrator to change fields. (Priority 2)

The administrator will be able to adjust fields pertaining to all matches entered namely the price of a game, maximum bowls in an over, weighting of allocated points. These changes will manifest themselves on all online scorecards used subsequent to the change.

20 Search for specific scorecards according to user-specified criteria (Priority 1)

The users will specify fields, namely team names, dates or player names to search for specific score-cards for viewing.

21 Generate web pages to view all information available on the system (Priority 1)

All information on the system will be available online in the form of web pages created on the server by a server side scripting language which will handle the task of querying the database.

4 Non-Functional Requirements

1 User Interface and Human Factors

The system will be used by 2 main groups of stakeholders. The first is the administrator, who will require basic computer skills to interact with the Online Cricket Database System. Due to the web format, there will be no installation or configuration required. The second group is the public domain, where once again basic knowledge of computer functions; in particular web browsing skills will be required to view the online statistics. No training will be required, as there is a comprehensive online user manual. Due to the user friendly manner of the system, there will be a minimal possibility for user error. The web page will follow strict design conventions, including logically grouped data, bright trusting colours and a basic three click rule.

2 Documentation

Due to the relative simplicity of the system, combined with an online user manual, the system will be available to all computer skill levels. The appropriate documents will follow strict documentation conventions, including traceability. Where appropriate, an online email facility will be provided to answer user questions. Due to the read-only nature of the system for the majority of the target audience, only the administrators will need the documentation.

3 Hardware Consideration

The system will follow a client/server method of use and interaction. Due to the application residing on a centralized server and not on the client machine, the client will need a basic internet connection, internet communication devices, a basic graphics card to render the statistical information, small memory space to run internet explorer or like, and sufficient hardware space to store the temporary internet download files.

4 Performance Characteristics

The main performance factor that must be considered is the throughput and response time of the web aspect of the system. A poor internet connection will severely limit the performance of the web page, reducing response time. The client has expressed a limit of no more than 30 seconds loading time for the dynamic server generated web page, and up to 8 hours for a static web page that resides on the server to exist before being replaced by an updated webpage.

5 Error Handling and Extreme Conditions

Due to the large number of required user inputs to make the database and web facility function correctly, error handling is a high priority. This will be accounted for by input and output checks, data validation and user-friendly error responses which will inform the user of the errors and how they may be corrected. The system may also be inactive for a set period to perform maintenance. Through extensive testing processes erroneous inputs and navigational errors will be accounted for. In extreme conditions such as a system crash, we will rely on facilities provided by the database management system we are using outlined in section 3.3.7 to maintain the integrity of the data – completed database transactions will be conserved and incomplete transactions will be disposed of.

6 System Interfacing

Due to the client/server architecture of our system, input and output will be continual to and from the system. Input will be collated from the user and output will be returned according to standard network protocols. The user will be restricted according to the nature of that user. As mentioned in section 3.2.16, the administrator will have full access to the database and the other users will be restricted to what statistics are output online.

7 Quality Issues

To ensure that all data is secure on the databases, backups will be performed to maintain data integrity at the user’s discretion. This will not eliminate the possibility of server failure, but will improve the disaster recovery process. The system will trap input and output faults and will handle exceptions appropriately. In the unlikely event of a system failure, the system administrator will bring the system online as soon as possible, (hopefully within several minutes of the system going down) with the recovered data. Once again due to the client/server nature of the system, portability is not an issue. The system will be programmed using PHP and MYSQL, which are platform portable. The client has expressed that there is no preference to portability, with regard to being able to run the system on specific operating systems or servers. We will endeavor to make our system compatible with all modern web-browsers and the resources available at CSSE.

8 System Modifications

The client has expressed a need to provide facilities for future modifications and expansions. These will include adding queries to the system, which will in turn require modifications to the presentation of web pages. As a result all code must be commented thoroughly. Low coupling between subsystems and high cohesion between subclasses will ensure minimal dependency between modules thus making modification easier. Specifically code involving presentation and code involving queries should be kept well apart.

9 Physical Environment

The standard environment which exists in CSSE will be adequate.

10 Security Issues

As mentioned in sections 3.2.16 and 3.2.18, there are several security issues that must be handled. The physical security of the server is sufficient and logical security of the data will be reinforced by a range of firewalls, proxies, access control lists, password authentications, access attack preventions and denial of service attack prevention software. Installation wide security arrangements at CSSE will be used and the current system must not compromise them.

11 Resource Issues

The system administrator is responsible for installation and maintenance of the system. The data on the servers will be regularly backed up automatically by the server and placed in a safe and secure area. No other information is stored on the client’s local machine.

5 Constraints

The system will reside on a server running PHP and MySQL. The users will be expected to use typical web browsers such as Mozilla and Microsoft Internet Explorer that can display web pages generated by the server side scripting.

6 System Model

1 Scenarios

|Scenario name |Store Indoor Cricket Scorecard Data per Game for game on bay13, 5/8/03. |

|Participating actor instances |Luigi Barone: Administrator. |

|Flow of Events |Luigi Barone logs on to the system submitting a user name and password. |

| |Luigi Barone selects the option to input a new game record. |

| |Luigi Barone selects the participating teams, the date and time of the match. |

| |He fills in the details of the innings for both teams, over by over, including names|

| |of batsmen in each skin, bowlers for each over and the details of the associated |

| |runs. |

| |Once all fields are completed, Luigi Barone submits the online scorecard form. |

| |The system verifies that the data entered is in the correct format and tallies up |

| |the number of overs to verify that it is 16. |

| |The system tallies up the totals for each skin and team, calculating points scored. |

| |The system updates the database. |

| |The system sends Luigi Barone a receipt and presents him with a new blank score |

| |card. |

|Scenario name |Look-up a Game Record. |

|Participating actor instances |Justin: user. |

|Flow of Events |Justin goes to the system homepage. |

| |Justin selects the team that played in the game. |

| |The system presents the page for that team. |

| |Justin selects a link to the season he is interested in. |

| |Justin is presented with a page with links to all the games in that season. |

| |Justin selects the game on the date and time he is seeking, and is presented with a |

| |page containing links to each over. |

|Scenario name |Generate player statistics. |

|Participating actor instances |Justin: user. |

|Flow of Events | |

| |Justin visits the OICD homepage. |

| |Justin selects his team. |

| |System produces a webpage showing a list of all the players in Justin’s team. |

| |Justin clicks on the link bearing his name and is presented with details of his |

| |performance, points and payment records. |

2 Use Case Models

1 Actors

There are three actors identified by the client that interact with the OICD. These are the viewers, database server and administrator. Each of the actors interacts differently with the OICD, according to their rights/privileges and roles. These interactions are delineated in 3.5.2.2.

Top Level Use Case

The following top level use case describes the interactions between the actors identified in 3.5.2.1 and the OICD.

[pic]

Administrator Use Case

The following Use Case delineates the use case interactions of the administrator

[pic]

Viewer Use Case

The following Use Case delineates the use case interaction of the viewer. This interaction is only of note to identify that a viewer has read-only access compared to the administrators full read, write and execute functionalities.

[pic]

Database Server Use Case

The following Use Case delineates the use case interactions of the database server.

[pic]

2 Use Cases

The following Use Cases have been logically grouped according to section 3.5.2.1. Specifically, they are grouped under the areas of Administrator, Viewer and Database Server.

|Use Case 1 |Lock Account. |

|Goal In Context |The system locks the account after 3 unsuccessful login attempts. |

|Scope and Level |System. |

|Preconditions |Administrator has attempted 3 failed login attempts. |

|Success End Condition |System locks account for 30 minutes. |

|Failed End Condition |System does not lock the account due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Username and password fields are filled in and login button is pressed. |

|MAIN SUCCESS SCENARIO |Step |Action. |

| |1 |Administrator fills in the username and |

| | |password field and attempts to login. |

| |2 |Administrator fills in the username and |

| | |password field and attempts to login. |

| |3 |Administrator fills in the username and |

| | |password field and attempts to login. |

| | | |

| | |System locks the account for 30 minutes. |

| |4 | |

|EXTENSIONS |Step |Branching Action. |

| |4a |System takes the administrator to a logon|

| | |error page. |

|Use Case 2 |Monitor and Display Payment Information. |

|Goal In Context |Payment information is monitored and displayed using a web interface for viewing by |

| |all users. |

|Scope and Level |Administrator, Viewers. |

|Preconditions |Payment information is entered into the database. |

|Success End Condition |The payment information is displayed. Users can view this information. |

|Failed End Condition |Payment details are not available for viewing by users due to another error |

| |occurring. |

|Primary, Secondary actors |System. |

|Trigger |User uses the web interface to view the payment information. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |User uses the web interface to view |

| | |payment information. |

| |2 |Payment information is generated and |

| | |available for viewing. |

| | | |

|EXTENSIONS |Step |Branching Action |

| |2a |Payment information is unavailable for |

| | |viewing – viewer / administrator sent to |

| | |an error page. |

|Use Case 3 |Generate Player Statistics. |

|Goal In Context |Player statistics is generated and displayed using a web interface for viewing by |

| |all users. |

|Scope and Level |System. |

|Preconditions |Scorecard information is entered into the database. |

|Success End Condition |Player statistics are successfully generated and displayed for viewing. |

|Failed End Condition |Player statistics are unable to be viewed due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator request for player statistics to be generated by the system. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator request for system to |

| | |generate player statistics. |

| | | |

| | |The system generates the statistics for |

| |2 |viewing in the form of GUI functions. |

|EXTENSIONS |Step |Branching Action |

| |2a |Player statistics are unavailable for |

| | |viewing – viewer / administrator sent to |

| | |an error page. |

|Use Case 4 |Generate Team Statistics. |

|Goal In Context |Team statistics is generated and displayed using a web interface for viewing by all |

| |users. |

|Scope and Level |System. |

|Preconditions |Scorecard information is entered into the database. |

|Success End Condition |Team statistics are successfully generated and displayed for viewing. |

|Failed End Condition |Team statistics are unable to be viewed due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator requests for team statistics to be generated by the system. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator request for system to |

| | |generate team statistics. |

| |2 |The system generates the statistics for |

| | |viewing in the form of GUI functions. |

|EXTENSIONS |Step |Branching Action |

| |2a |Team statistics are unavailable for |

| | |viewing – viewer / administrator sent to |

| | |an error page. |

|Use Case 5 |Display Award Points. |

|Goal In Context |System calculates and displays award points from the scorecard information input. |

|Scope and Level |System. |

|Preconditions |Scorecard information is entered into the database. |

|Success End Condition |Award points are successfully generated for viewing. |

|Failed End Condition |Award points are unavailable for viewing due to another error occurring. |

|Primary, Secondary actors |System. |

|Trigger |Contestant clicks on link to view results. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Scorecard information is input into the |

| | |system. |

| | | |

| |2 |The system uses the information to |

| | |generate award points for viewing. |

|EXTENSIONS |Step |Branching Action |

| |2a |Award points are unavailable for viewing |

| | |due – viewer / administrator sent to an |

| | |error page. |

|Use Case 6 |Display Game Points. |

|Goal In Context |Administrator inputs game points decided after the game. |

|Scope and Level |System. |

|Preconditions |Game points for the ‘best and fairest player’ decided after the game. |

|Success End Condition |Game points are available for viewing. |

|Failed End Condition |Game points are unavailable for viewing due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator enters the game points data. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator enters the game points data|

| | |into the system. |

| |2 |System generates game points for viewing.|

|EXTENSIONS |Step |Branching Action |

| |2a |Game points unavailable for viewing – |

| | |viewer / administrator sent to an error |

| | |page. |

|Use Case 7 |Generate Web Page. |

|Goal In Context |All information on the system will be available for viewing online in the form of |

| |web pages. |

|Scope and Level |System. |

|Preconditions |Scorecard information has been entered into the system. All statistics and other |

| |details have been generated. |

|Success End Condition |Users are able to view all information on the system in the form of web pages. |

|Failed End Condition |The system is unsuccessful in generating the web pages due to another error |

| |occurring. |

|Primary, Secondary actors |System. |

|Trigger |Web pages are generated by the system after all the information has been input. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Scorecard as well as additional |

| | |information input into the system. |

| |2 |System generates web pages to allow users|

| | |to view this information. |

| | | |

|EXTENSIONS |Step |Branching Action |

| |2a |Web pages not generated – user / |

| | |administrator sent to an error page. |

|Use Case 8 |Logon to Database. |

|Goal In Context |Administrator is able to logon to the system. |

|Scope and Level |Administrator. |

|Preconditions |Administrator has received account details information. |

|Success End Condition |Administrator is able to logon to the system and receives an error. |

|Failed End Condition |Failure in logging on. |

|Primary, Secondary actors |Administrator, System. |

|Trigger |Username and password fields are filled in and login button is pressed. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator fills in the username and |

| | |password field. |

| |2 |Administrator clicks on the submit |

| | |button. |

| |3 |Administrator is directed towards the |

| | |logon page. |

|EXTENSIONS |Step |Branching Action |

| |3a |Administrator is unsuccessful in the |

| | |logon attempt, sent to an error page. |

|Use Case 9 |Search by Field. |

|Goal In Context |The user can specify to search by specific fields for scorecard viewing. |

|Scope and Level |Administrator, Viewers. |

|Preconditions |User is online and viewing the web pages. |

|Success End Condition |The scorecard information is viewed after a successful search. |

|Failed End Condition |The scorecard data is unavailable for viewing due to another error occurring. |

|Primary, Secondary actors |System. |

|Trigger |User inputs the search criteria to search for a scorecard. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |User inputs the search criteria required.|

| |2 |System returns a scorecard which matches |

| | |the search criteria. |

| | | |

|EXTENSIONS |Step |Branching Action |

| |2a |The scorecard is unavailable for viewing |

| | |– viewer / administrator sent to an error|

| | |page. |

|Use Case 10 |Create Team Profile. |

|Goal In Context |Administrator is able to create team profiles. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into the account. |

|Success End Condition |Team profiles are created. |

|Failed End Condition |Team profiles are not created due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to create a team profile. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator logs into account. |

| |2 |Administrator creates a new team profile.|

| | | |

| | |Web pages are generated to allow users to|

| |3 |view the team profile created. |

|EXTENSTIONS |Step |Branching Action |

| |3a |Team profiles are not created – |

| | |administrator sent to an error page. |

|Use Case 11 |Delete / Edit Team Profile. |

|Goal In Context |Administrator is able to delete or edit player profiles. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into account. |

|Success End Condition |Team profiles are deleted / edited. |

|Failed End Condition |Team profiles are unavailable to be deleted / edited due to another error occurring.|

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to delete / edit team profiles. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator logs into account. |

| |2 |Administrator deletes / edits team |

| | |profile. |

| | | |

| | |Web pages are generated to allow users to|

| | |view updated team profiles. |

|EXTENSTIONS |Step |Branching Action |

| |2a |Team profiles are not deleted / edited – |

| | |administrator sent to an error page. |

|Use Case 12 |Create Player Profile. |

|Goal In Context |Administrator is able to create player profiles. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into account. |

|Success End Condition |Player profiles are created. |

|Failed End Condition |Player profiles are unable to be created due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to create a player profile. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator logs into account. |

| |2 |Administrator creates a player profile. |

| |3 |Web pages are generated to allow users to|

| | |view the player profile. |

| | | |

|EXTENSIONS |Step |Branching Action |

| |3a |Player profiles are not created – |

| | |administrator sent to an error page. |

|Use Case 13 |Delete / Edit Player Profile. |

|Goal In Context |Administrator is able to delete or edit player profiles. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into account. |

|Success End Condition |Player profiles are deleted / edited. |

|Failed End Condition |Player profiles are unable to be deleted / edited due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to delete / edit a player profile. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator logs into account. |

| |2 |Administrator creates a player profile. |

| |3 |Web pages are generated to allow users to|

| | |view the player profile. |

| | | |

|EXTENSIONS |Step |Branching Action |

| |3a |Player profiles are not deleted or edited|

| | |– administrator sent to an error page. |

|Use Case 14 |Enter Scorecard Data. |

|Goal In Context |Administrator enters scorecard data after logging into the account. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into account. |

|Success End Condition |Administrator is able to enter all scorecard data information. |

|Failed End Condition |Administrator is not able to enter data due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to enter scorecard data information. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator logs into account. |

| |2 |Administrator enters scorecard data |

| | |information. |

|EXTENSIONS |Step |Branching Action |

| |2a |Administrator is unable to enter |

| | |scorecard data information – |

| | |administrator sent to an error page. |

|Use Case 15 |Change Fields. |

|Goal In Context |Administrator chooses to change fields. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into account. |

|Success End Condition |Administrator is able to change fields. |

|Failed End Condition |Administrator is unable to change fields due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to change the fields. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator logs into account. |

| |2 |Administrator changes fields. |

| | | |

|EXTENSIONS |Step |Branching Action |

| |2a |Administrator is unable to change fields |

| | |– administrator sent to an error page. |

|Use Case 16 |Change Password. |

|Goal In Context |Administrator can change the password. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged into account and has successfully input old password |

| |information. |

|Success End Condition |Administrator is able to change password. |

|Failed End Condition |Administrator is unable to change password due to another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to change password. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator is logged into account |

| | |successfully. |

| |2 |Administrator has typed old password |

| | |successfully. |

| | | |

| |3 |Administrator types in new password to be|

| | |changed to. |

| | | |

| | |Password is changed successfully. |

| |4 | |

|EXTENSIONS |Step |Branching Action |

| |4a |Administrator is unable to change |

| | |password – administrator sent to an error|

| | |page. |

|Use Case 17 |Delete / Edit Scorecard Data. |

|Goal In Context |Administrator is able to delete or edit the scorecard data. |

|Scope and Level |Administrator. |

|Preconditions |Administrator has logged into account. |

|Success End Condition |Administrator is able to delete or edit the scorecard data. |

|Failed End Condition |Administrator is unable to delete / edit scorecard data due to another error |

| |occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator is logged into account. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator is logged into account. |

| |2 |Administrator chooses to delete / edit |

| | |scorecard data. |

| |3 |Web pages are generated for users to view|

| | |updated data. |

|EXTENSIONS |Step |Branching Action |

| |3a |Administrator is unable to delete / edit |

| | |scorecard data – administrator sent to an|

| | |error page. |

|Use Case 18 |Display Statistics. |

|Goal In Context |Administrator is able to request for statistics to be generated dynamically. |

|Scope and Level |Administrator. |

|Preconditions |Administrator is logged in. |

|Success End Condition |System displays statistics for viewing. |

|Failed End Condition |Statistics are unable to be displayed to do another error occurring. |

|Primary, Secondary actors |System, Administrator. |

|Trigger |Administrator chooses to display statistics dynamically. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Administrator must be logged into |

| | |account. |

| |2 |Administrator requests for statistics to |

| | |be dynamically generated. |

| |3 |Statistics generated in the form of web |

| | |pages for viewing. |

|EXTENSIONS |Step |Branching Action |

| |3a |Statistics are unable to be displayed – |

| | |viewer / administrator sent to an error |

| | |page. |

|Use Case 19 |View Generated Information. |

|Goal In Context |Viewers / Administrator are able to view the generated information in the form of |

| |web pages. |

|Scope and Level |Viewers, Administrator. |

|Preconditions |Viewers / Administrator are online. |

|Success End Condition |Viewers / Administrator are able to view the generated information. |

|Failed End Condition |Viewers / Administrator are unable to view information due to another error |

| |occurring. |

|Primary, Secondary actors |System, Viewers, Administrator. |

|Trigger |Viewers / Administrator choose to view generated information. |

|MAIN SUCCESS SCENARIO |Step |Action |

| |1 |Viewers / Administrator are online. |

| |2 |Viewers / Administrator choose to view |

| | |generated information. |

| |3 |System allows viewers / administrator to |

| | |view the generated information in the |

| | |form of GUI and web pages. |

|EXTENSIONS |Step |Branching Action |

| |3a |Generated information is unable to be |

| | |viewed by viewers / administrator – |

| | |viewer / administrator sent to an error |

| | |page. |

3 Object Models

1 Data Dictionary

See the Glossary for detailed descriptions of vital elements.

2 Class Diagrams

The following class diagram shows the OICD databases and associated subsystems.

[pic]

4 Dynamic Models

State Charts

Administration Web Navigation Chart:

[pic]

This is the state chart which shows some of the navigation abilities of the administrator.

Viewer Read-Only Web Navigation Chart:

[pic]

This is the state chart which shows some of the navigation abilities of a viewer. As previously stated, a viewer may only read generated information.

Sequence Diagrams

The following sequence diagrams depict the sequence of events for all identified use cases identified in section 3.5.2.

[pic]

This is Change Fields Use Case. It involves the administrator changing core database field information.

[pic]

This is Change Password Use Case. It involves the administrator changing the password.

[pic]

This is Create Player Use Case. It involves the administrator creating a player profile.

[pic]

This is Create Team Use Case. It involves the administrator creating a team profile.

[pic]

This is delete/edit player profile Use Case. It involves the administrator editing a player.

[pic]

This is delete/edit scorecard data Use Case. The administrator edits a scorecard.

[pic]

This is delete/edit team data Use Case. The administrator edits a team profile.

[pic]

This is Display Personal Award Points Use Case. The administrator may view and edit points.

[pic]

This is Display Game Points Use Case. The administrator may view and edit points.

[pic]

This is the Display Statistics Use Case. The administrator initializes display of statistics.

[pic]

This is the create scorecard Use Case. The administrator creates a scorecard.

[pic]

This is the generate player statistics. The administrator initializes the statistics generating.

[pic]

This is the generate team statistics. The administrator initializes the statistics generating.

[pic]

This is the Lock Account Use case. The server locks the account.

[pic]

This is the Log On Use Case. The administrator logs on at the beginning of every sequence diagram and use case.

[pic]

This is the Monitor Payments Use Case. The administrator may monitor payment details.

[pic]

This is the Search Fields Use Case. The administrator may search the database for data.

[pic]

This is the View Information Use Case. The viewer browses the web sites information.

[pic]

This is the Generate Web Page Use Case. The administrator initializes a web page to be generated for viewing on the web.

5 User Interface – Navigational Paths and Screen mock-ups

[pic]

Figure 1 – OICD homepage

Figure 1 is a screen shot of the intended homepage for the system. From this point normal users may view the records of the team of their choice, and the administrator may login and update records.

[pic]

Figure 2 – online scorecard form

Figure 2 is a screenshot of the online scorecard input form where the administrator will fill in the details of the opposing teams, and then fill in each over one by one by pressing the numbers 1 to16 on the right of the form. Figure 3 demonstrates the appearance of the form that emerges after the link associated with the first innings in Figure 2 visited.

[pic]

Figure 3 – form in which to fill in the details of the first innings.

In the case of the every fourth over which may be have as many as ten bowls the form will be appropriately larger, with more entry fields as seen in Figure 4.

[pic]

Figure 4 - form in which to fill in the details of the fourth innings.

Normal users may view the Player records of a particular competitor, by navigating through his/her team’s website. An example of a player profile is shown in Figure 5.

[pic]

Figure 5 A player’s records

GLOSSARY

Administrator- An individual who is responsible for creating editing and deleting data concerning statistics, points payments and other records on the system, keeping the system up-to-date.

Award - Players are nominated as the fairest and best player at the end of each game.

Bowled Out - When the bowler hits the wicket with the ball while bowling, resulting in a deduction of runs on the part of the batsmen.

Catch - When the batsman is “out” after a fielder caught the ball immediately after he hit it.

Dot Balls - Bowls that resulted in neither an “out” nor runs being scored.

Dynamic – The information appearing on the webpage is not completely static. It is determined by the queries requested by the user, hence server-side scripting is required.

Game – A game of indoor cricket

GUI – Graphical User Interface

Innings – When 16 overs are batted by one particular side.

MySQL – Database management system used to store the information that will be used in the system. It is freely available for use at CSSE.

OICD - Online Indoor Cricket Database, the system we are implementing

Over – When 6 bowls are bowled by a particular bowler this is said to be an over. Every fourth over is the last over batted by a particular skin/partnership, wherein 6 bowls are guaranteed, however the over may continue to ten bowls or until the batsman is bowled out.

Partnership - A pair of batsmen who will typically bat fro four overs together, also referred to as a skin.

PHP – Server-side scripting language often used in conjunction with MySQL

Player- An individual who partakes in an indoor cricket match

Run Out – When a batsman does not reached the wicket before the ball touches it while he is running

Skin – A pair of batsmen who will typically bat four overs together

Stumping – When the wicket keeper connect the ball and the wicket while the batsman is not in his crease.

Team profiles - Information which is related to a particular team in the Indoor Cricket games. This information includes details of players, games, payments and points.

User -A typical user of the system who will go online and check results and statistics on the system, querying the database through their web-browser.

CSSE – Department of computer science and software engineering.[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download