Part I Functional Specification
Section 1 Sign up and Log in
1.1 Sign up
Any site visitor should be able to sign up as a member of the site. During the sign-up, an email address will be needed and a confirmation email will be sent so that this site visitor can activate his/her membership. Additional information like the sports the person normally plays and other personal information can be filled in during the process of the sign-up. A security question should be asked in case the user forgets the password.
1.2 Log in
After registration the site visitor can use an email address and a password to log in. A “Forgot Password” should be provided asking the security question and the email address so that the password can be sent by email. If the site visitor chooses to remember her login, next time she visits the site, she will be logged in automatically.
1.3 Anonymous Users
An anonymous user can perform the individual and team search but such searches are limited to 5 times. An anonymous user cannot see any individual/team profile.
Section 2 Individuals and Teams
2.1 Search
Individuals and teams should be search-able by their location, gender and age. They should also be searchable by the sports they play and their skill level of playing such sports. For location searches (this section and all other sections of the site), the site should calculate the distance between two post codes, and the distance is the “crow flies distance”, which does not take the routings into consideration.
2.2 Profiles
Individuals and teams have their profiles visible to selected Versus1 site visitors depending on their settings. Individuals should be able to update this information, or, if they are team administrators, update this information for their team.
2.2.1 Sports
Individuals and teams should have information of the sports they are playing visible. The sports information include things like their skill level, how many years they have playing, their club to play a specific sport (only one club for one sport), and preferred time to play, etc.
2.2.2 Information
Individuals and teams should have their basic information disclosed, including their location, their ages (if it is an individual, their contact email address, etc.)
2.2.3 Calendar (framework in source code but not yet implemented)
Individuals and teams have their match and event schedule displayed in a calendar. This is displayed to them as reminders when they have a match/event, and also for other people to see when this individual is available in order to arrange fixtures with them.
2.2.4 Contacts and Pals
Individuals and teams should be able to add another individual or team as their contacts or pals. When adding a pal, a notification should be sent to the pal to approve and make them pals with each other.
An individual should be able to view her contacts and pals, both from her personal contacts/pals and from her teams’ contacts/pals. She should be able to edit or remove her individual contacts and pals, and if she is an administrator of a team, edit or remove this team’s contacts and pals.
The contact list is only visible to a particular individual or a team member, and pals are visible to everybody.
2.2.5 Clubs (framework in source code but not yet implemented)
An individual or a team can join one or more clubs, and this information should be visible to general public depending on the individual/team settings. They can then quit the club or join more clubs at a later time.
A person should be able to search the clubs by their post codes and club guide prices so this person can easily go to the club page to see the club information or join and quit the club.
2.2.6 Photo Album
An individual or a team can upload their photos to its profile and all the photos should be listed in thumbnail view, paginated. Other site visitors can view these thumbnails, as well as the large version.
2.2.7 Team Members
If the team’s status is “Open”, it can accept new members. Before a member joins a team, she can request a tryout so that a notification will be sent to a team administrator to arrange the tryout.
Once the team profile is accessed, anybody should be able to see its current members, and then request to join the team. A “Closed” team cannot accept new team members.
Team members should have full control of that team except deletion of the team member and accepting new members, or giving controls to other team members. Only team creator can.
2.3 Events (feature not yet designed nor is it included in source code)
An individual or a team can join one or more events, the events an individual/team is attending should be easily available to this individual/team for quick reference. Once joined an event, they can leave the event or join more event at a later time.
Events should be searchable by their locations, keywords and sport names. Once the individual or the team joins the event, it will be visible from the individual’s or the team members’ calendars.
2.4 Leagues (feature not yet designed nor is it included in source code)
An individual or a team can request to join one or more leagues as participants or reserves in a certain league division, and the request should be processed by the league administrator/creator. The leagues an individual or a team has joined should be easily available to this individual/team for quick reference. Once joined a league, they can leave the league or join more leagues at a later time.
League should be searchable by their locations, keywords and sport names. Once the individual or the team joins league, their matches in the league will be visible from the individual’s or the team members’ calendars.
2.5 Fixtures
An individual can arrange matches with another individual (or, if she is a team administrator, arrange matches with other teams) on a specified sport, date/time, the location (could be a club name), and additional notes. The fixture then is visible to this individual/team for quick reference.
Then the opponent will need to accept the fixture to “publish” this fixture. If the fixture is not yet accepted, the opponent will not be displayed to the public in the requestor’s fixture list (the fixture itself is still there with only the requestor’s name). If the fixture is rejected, it should not display in either opponent’s fixture list.
Once published, the fixtures will be available in the individual/team’s profile (subject to the individual/team security settings), except this fixture’s location.
2.6 Results
An individual can add results for her previous fixtures (or, if she is a team administrator, add results for her team’s previous fixtures with other teams) on a specified sport, date/time, the location (could be a club name), and additional notes. The result then is visible to this individual/team for quick reference.
Then the opponent will need to accept the result to “publish” this result. If the result is not yet accepted, the opponent will not be displayed to the public in the requestor’s result list (the result itself is still there with only the requestor’s name). If the result is rejected, it should not display in either opponent’s result list.
Once published, the result will be available in the individual/team’s profile (subject to the individual/team security settings), except location of the match.
2.7 News Feed
News and announcements from Versus1 site administrator, event and general announcements from individual or team’s clubs, match results of their league and the events they are attending, and announcements of professionals that they are fans of and their personal trainers and coaches, etc. should be picked up and displayed to the individual or the team.
2.8 Inbox
Individuals and teams should be able to receive, edit and send messages. Nearby clubs should be visible when people view their message box, first sorted by the position they paid for, and then by the distance they are from the current individual/team.
2.9 Professionals and Fans (feature not yet designed nor is it included in source code)
An individual can search professionals by their names, locations and sports they play, and then add a professional to become a fan of that professional. A team administrator can add a professional to the team in order for the entire team to become a fan of that professional.
Similarly an individual or a team can stop being a fan of a professional.
2.10 Report Abuse/Block
If a person violates the terms and conditions of the Versus1 site, e.g. upload inappropriate pictures, other people should be able to report this person to the site global administrator. An individual or a team should also be able to block another individuals or teams so they will not receive messages or fixtures from the blocked individual/team.
2.11 Settings
Individuals and teams should be able to control their privacy settings including whether to display sports, calendar, fixtures, results, personal information, clubs and contracts and pals to general public or only to the individual/team’s pals, or only to the individual/team themselves.
2.12 Team Administration
A team can be created by an individual once they log in. The creator will be the first team administrator, who can accept new team members, join the team to an event or league, add fixtures and results, and make the team as fans of a professional, etc. The team creator then will be able to add other team members as team administrators, in which case if one team administrator doesn’t have Internet access, or goes on holiday, other administrators can be delegated to do the job.
Section 3 Clubs
(any feature on clubs was never implemented, but framework is in source code)
3.1 Club Creation
A global administrator should be able to create a club. An email address and the club’s name should be provided so the club can be created. A password will be generated upon creation and sent to the provided email address. Once created, the club can log in using the email address and password to log in to fill in the club information (e.g. organise club event, publish club’s general announcements, etc.)
A person without an individual profile should be able initiate the club creation process. A club creation request in this case will be sent to the global administrator for approval.
3.2 Club Deletion
Once the club stopped paying or violates the terms and conditions of Vs.One site, a global administrator should be able to delete the club. After deletion, the club page will not be accessible from anywhere in the site, and those links to the club under other sections of the site should change to plain texts.
3.3 Previous Results
The club creator should be able to fill in (or edit) the tournament/league match results (winners and runners up) if the matches are held in that club. People should see these people’s names and scores of these matches.
3.4 Events
The club creator should be able to fill in (or edit) the coming events that club organises. People should see the time and date that event is held, and other things like picture, price, direction, etc.
3.5 Upload Results and Fixtures
The club creator should be able to upload a document with the club match results and fixtures so other people can download.
3.6 Members
People should be able to see all members of a club. These members should be categorised as normal members, teams, personal trainers, coaches and professionals. An individual or a team should be able to request to join a club, which will be sent to the club creator, and the club inbox, for approval. An individual/team should be able to quit the club as they wish.
3.7 Club Info
This is the general club information including contact details, price guide, location, opening times etc. The club creator should fill it in upon club creation, or edit afterwards. Quick contact include the club email and telephone, etc.
The club administrator should be able to add/change the price information to the club info page, and this can have prices for different packages (e.g. Gold/Silver package), or different type of fees (e.g. Green fees).
The club administrator should be able to upload the pictures and documents relevant to what have happened in the club.
The club administrator should be able to create user polls (votes).
The club should list a form to allow people to send their own feedback to the club manager/administrator.
3.8 General Announcements
This is general announcements of a club which should be filled in or edited by the club creator.
3.9 Member of the Month
The club creator should be able to select one club member as member of the month. Then a short description of the reason why he/she is the member of the month should be given.
Part II Non-functional Requirements
Section 1 Technologies
The website should be developed using Microsoft .NET Framework 3.5. It should use Microsoft SQL Server 2005 or later version as the database system,
Section 2 Hosting Service and Domain Registrar
The hosting service should provide a shared Windows 2003 host server, installed with Microsoft .NET Framework 3.5, Microsoft SQL Server 2005 or later version and IIS 6.0. The hosting company should provide effective ways of managing these, and deploying the website to it once the development is finished.
Ideally the hosting service should not have any restriction on the disk space allowance and bandwidth allowance. This is because people can upload many photos or event result documents (which take disk spaces and bandwidth), and other people can download them many times (which take significant amount of bandwidth).
Section 3 Standard Compliance
There are no mandatory standard compliance requirements apart from making sure the site runs under all modern browsers including Internet Explorer 6+, Firefox 2+, Safari 3 and Chrome.
Ideally during development, XHTML and accessibility are considered. In the future the website may need to support mobile devices and/or include site visitors with certain disabilities.
Section 4 Security, performance and maintainability
Site visitors’ passwords should not be disclosed to anybody but themselves, and even a global administrator cannot see their passwords. The passwords should be encrypted in the database, and never be sent in plain text on the wire.
The individual’s profile information (e.g. their full name, email address, etc.) should not be disclosed to other people if the individual selects not to (See Part I – Section 2.2). Where necessary, the location of a fixture should not be disclosed to this person and her opponent(s).
Under the normal user load, the site should in general have a short page response time so the hosting service should provide a fast enough internet connection. Whenever possible, avoid page reloads and use the Ajax techniques instead. The images and scripts should be kept as minimal as possible to reduce the page load time.
The development deliverables do not only include the running website, but all the source code and documentations for later maintenance. Different modules should be as decoupled as possible so that if changes have to be made to one module, other modules are unaffected.
