Software Requirements

Specification

for

Sport Event Management

Framework (SEMF)

Version 1.0

Group 05

26th of September 2006

SoftwareRequirementsSpecificationforSportEventManagementFramework

Pageii

TableofContents
TableofContents...........................................................................................................................ii
1. Introduction..............................................................................................................................1
1.0
Purpose.......................................................................................................................................1
1.1
IntendedAudienceandReadingSuggestions.............................................................................1
1.2
ProjectScope..............................................................................................................................1
1.3References.........................................................................................................................................2

2. OverallDescription..................................................................................................................2
2.0
2.1
2.2
2.3
2.4
2.5

ProductFeatures.........................................................................................................................2
UserClassesandCharacteristics................................................................................................2
OperatingEnvironment..............................................................................................................3
DesignandImplementationConstraints.....................................................................................3
UserDocumentation...................................................................................................................3
Assumptions,DependenciesandGuidelines..............................................................................3

2.5.1
Assumptions............................................................................................................3
2.5.2
Dependencies...........................................................................................................3
3SystemFeatures..........................................................................................................................4
3.1Controlaccesstoresourcesinformation............................................................................................4

3.1.1 Description and Priority..................................................................................................4

3.1.2 Functional Requirements................................................................................................4

3.2Accreditation.....................................................................................................................................7

3.2.1 Description and Priority..................................................................................................7

3.2.2. Stimulus & Responses...................................................................................................7
3.2.3. Functional Requirements...............................................................................................7

3.3AccommodationandTransportationAllocation...............................................................................9

3.3.1 Description and Priority..................................................................................................9

3.3.2. Stimulus & Responses...................................................................................................9
3.3.3. Functional Requirements...............................................................................................9

3.4EventScheduling............................................................................................................................10

3.4.1 Description and Priority................................................................................................10

3.4.2. Stimulus & Responses.................................................................................................10
3.4.3. Functional Requirements.............................................................................................10

3.5ScoreLiveupdate...........................................................................................................................11

3.5.1 Description and Priority................................................................................................11

3.5.2. Stimulus & Responses.................................................................................................11
3.5.3. Functional Requirements.............................................................................................11

3.6Customizability...............................................................................................................................13

3.6.1 Description and Priority................................................................................................13

3.6.2. Functional Requirement...............................................................................................13

3.7Extensibility....................................................................................................................................13

3.7.1 Description and Priority................................................................................................13

3.7.2. Functional Requirements.............................................................................................13
4.ExternalInterfaceRequirements...........................................................................................14
a.
b.
c.

UserInterfaces..............................................................................................................................14
SoftwareInterfaces.......................................................................................................................14
CommunicationsInterfaces...........................................................................................................15

5OtherNonfunctionalRequirements........................................................................................15
5.1PerformanceRequirements.............................................................................................................15
5.2SafetyRequirements.......................................................................................................................15

SoftwareRequirementsSpecificationforSportEventManagementFramework

Pageiii

5.3SecurityRequirements....................................................................................................................15
5.4SoftwareQualityAttributes............................................................................................................15

6OtherRequirements.................................................................................................................16

SoftwareRequirementsSpecificationforSportEventManagementFramework

1. Introduction
1.0 Purpose
This is the software requirement specification for Sport Event Management System. This
will only contain higher level requirement specification for Sport Event Management
System. Sport Event Management System provides a framework for many other
components which dwell on top of it. Version of this document is 1.0 and any changes to
requirements or detailed software requirements will be published in a revised version.

1.1 Intended Audience and Reading Suggestions

This document is intended for providing higher level description of the system. Thus the
document will be useful for people who are involved in developing components for Sport
Event Management System, people who are involved in managing Sport Event, people
who are planning to implement a Sport Event Management System for their event and
any other person who need a higher level abstraction of the Sport Event Management
System.
People who are only interested in the feature and system overview can get most of the
things from referring to chapter 2: Overall Description.
People who are interested in extending the system or developing sub components on top
of the framework should read all the chapters. They should pay major attention to
functional requirement.
People who are trying to implement system to handle a sport event must also read though
almost all. They must also may attention to non-functional requirements.

1.2 Project Scope

The project vision is to provide software that will improve the efficiency, reduce cost and
time associated with planning and management of a Sport Event. Initially we will only
focus on achieving core functionality in the system and developing more modules that
will help to manage a core of a sport event. Future plans for other extensions will be
decided on completion of core functionalities.
Even though this project focuses on the fairly large events, small events should also be
able use system to good effects. By use of this system, people who are directly benefited
include decision makers, organizers, managers, players, officials, officers, media and
fans. There can be many other indirect benefactors.

SoftwareRequirementsSpecificationforSportEventManagementFramework

1.3 References

Somerville, I. (7ed) 2004, Software Engineering, New Delhi, Pearson Education

Rumbaugh, Jacobson J, Booch I, Grady, 1999, The Unified modeling language

reference manual, New Delhi, Pearson Education

2. Overall Description
2.0 Product Features
Main features of the product can be listed as below.
1. Control access to resources information
System will control the access to resource information and it will ensure the
system security by giving different access levels to different user groups.
2. Accommodation and transport allocation
System will handle accommodation and transportation facilities to the players and
visitors.
3. Event scheduling
System will generate the schedule automatically.
4. Score live update
System will publish live scores though World Wide Web and give interfaces to
access data to registered media
5. Customizability
6. Extensibility

2.1

User Classes and Characteristics

There are three types of users who are involved with this Framework. They are
1. Administrators
Root administrators
Local administrators
IT administrators
2. Scorers
3. Spectators

SoftwareRequirementsSpecificationforSportEventManagementFramework

All the above specified users should know some amount of English and the
basics of operating a computer and should be familiar with internet and any web browser
like MS Internet Explorer, Mozilla FireFox etc.
Other than above user characteristics root administrators should have specific
knowledge to install software.

2.2 Operating Environment

Windows 9x, windows ME, windows 2000, windows 2003, windows XP
or Linux can be used as the operating system.

2.3 Design and Implementation Constraints

Should have a server with open source software and enough performance
to handle the expected traffic.

Should have an internet connection

Other computers provided should have the following installed

MS Internet Explorer 5.0 or higher or Mozilla Firefox 1.0 or higher

Should have a well designed and maintained database.

2.4 User Documentation

User administration guide is provided to administrators

2.5 Assumptions, Dependencies and Guidelines

2.5.1

Assumptions

System users have their own server

All the computers used are networked

2.5.2

Dependencies

Open source software

2.6.3 Guidelines
Code is kept clean and simple for future upgrades and
maintenance

SoftwareRequirementsSpecificationforSportEventManagementFramework

3 System Features
3.1 Control access to resources information.
3.1.1 Description and Priority
Controlling the access to resource information is a high priority feature provided by the
product. This will ensure the information security by limiting the access to these
resources only to trusted roles.

3.1.2 Functional Requirements

1. All the people in the system have one or more roles. People should have access
level to read and change the information about resources according to their role.
2. Each role in the system will be associated with a resource types that they can
access and flags to represent whether it is allowed only to read or to both read and
write.
3. Users should not be able to access the information beyond their privilege limits
defined by its role.
4. The root administrator should be able to create initial accounts and assign the role.
The others also can create accounts given that their roles have the privilege to
create accounts.
5. In the core system, Access level will be granted in the following path.
a. The root administrator will create accounts for one administrator (local
administrator) of each party that participates to the sport event. These
administrators will have the access to information of Players, Coaches and
Administrator people who participate to the event. So the registration of
those people can be done under local administration before a specified
deadline. The deadline for the registration will be specified by the root
administrator but he should be able to change that later. After their
registration they need not to have granted any access to any part of the
system. But local administrators will have the authority to add, remove
players and assign to them to different sports events before the registration
deadline.
b. The root administrator will create accounts for IT managers of each
section of organizing committee. They will be able to recruit data entry
people to get support. The IT managers and people work under IT
managers will be given full access only to the resources in their

SoftwareRequirementsSpecificationforSportEventManagementFramework

corresponding section. But they should be able to read data from other
sections. These sections are identified as following.
i.
ii.
iii.
iv.
v.
vi.

Accreditation.
Playgrounds.
Sport Events.
Accommodations.
Transports.
Media.

In addition to this, the root administrator should be able to add additional

sections and remove unwanted sections according to the requirements.
c. The scorer will be recruited by root administrator or IT managers of Sport
Event Section. The scorers will be able to update the score when the event
is happening.
d. Spectators of games should be able to read following information without
any acknowledgement to the administrators.
1. Players and their past records.
2. Event Schedule.
3. Scores of past events.

Root Admin

Create Accounts for team admin

Create accounts for IT Officers

Team Admin

Register Players

Register Coachs

Regiser Officers

SoftwareRequirementsSpecificationforSportEventManagementFramework

Specify Rules and Constrains

Engage the relevent Module
Entring Data for the assigned
section
Recruite People

IT Officer

Access to records in other

sections

Registration
section

Playgrounds
Section

Sports Event
Section

Accomadation
Section

Transportation
Section

SoftwareRequirementsSpecificationforSportEventManagementFramework

3.2 Accreditation
3.2.1 Description and Priority
Accreditation will be a high priority feature provided by the system. This can be assumed
to be happening before a specified deadline. But System should be designed to handle
special cases.

3.2.2. Stimulus & Responses

Predetermine
Hotel
Booking
Enter by Number

Accreditation
Predetermine
Transportation

Detailed
Hotel
Allocation
Enter by Name

Detailed
Accreditation

Schedule
Transportatio
n
Accreditation cards

3.2.3. Functional Requirements

1. In accreditation the system should be capable of feeding the information in two
ways.
a. Entry By Number
This will be happening well before the specified deadline meet. Each team
will provide rough information how much players will be allocated for each
event. Hotel and transportation allocation can be assumed and organized

SoftwareRequirementsSpecificationforSportEventManagementFramework

considering these data. Other modules should use this information to roughly
calculate resources required for the corresponding section.
b. Entry By Name
This is a detailed description of each player participating to an event. There
are well defined set of information required by the system. Anyway the
information required should be able to customize according to the
requirement.
2. People should be categorized into several groups. These groups should be able to
customize by the root admin.
3. Accreditation card should be issued to every player, officers and other groups
involving the events from a designed template.
3. After the deadline of registration, the form will be frozen, so team administrators
cant add new personal to the system. But toot administrator should be able to
change, add or delete records even after the deadline.

SoftwareRequirementsSpecificationforSportEventManagementFramework

3.3 Accommodation and Transportation Allocation

3.3.1 Description and Priority
The System should be able to handle accommodation and Transportation of players and
visitors. This is a medium priority feature supported by the system.

3.3.2. Stimulus & Responses

Accommodation
allocated for each
player or team.

Transport Information

Hotel Information

Playground Records

Sport Event Records

Accommodation
and
Transportation
allocation system
Transportation used
from
accommodation to
the playground

3.3.3. Functional Requirements

1. Accommodation allocation should be done considering the following factors,
a. The transportation cost should be minimized.
b. Teams from same parties should be allocated consequence rooms as far as
possible.
2. Buses and other transportation media should be optimally utilized.
3. The accommodation and transportation information should be able to edit
manually.
4. The system should be able to print report on this information.

SoftwareRequirementsSpecificationforSportEventManagementFramework

3.4 Event Scheduling

3.4.1 Description and Priority
Event scheduling is a high priority feature supported by the System. This will be a high
requirement as there are lot of sport events and thousands of players registered with the
system; it is very difficult to do the scheduling manually.

3.4.2. Stimulus & Responses

Sport Event Records

Player Records
Scheduling
system
User Constrains

Event
Schedule

Playground
information

3.4.3. Functional Requirements

1. Event Schedules should to be generated considering the following information,
a. Time available slots for Playground.
b. Time allocation for Sport Events.
c. Events participated by each player.
d. Constraints provided manually.
Examples of constraints which will be supported by the system:
All the athletic events should start after finishing all the swimming events.
Football and Volleyball matches should not happen in same time slots.
Swimming events should start after 3pm.
2. The authenticated person can change the schedule manually, and then the system
should validate the schedule before accepting it.
3. The different user classes should be provided different views of the Schedule.

SoftwareRequirementsSpecificationforSportEventManagementFramework

3.5 Score Live update

3.5.1 Description and Priority
Score live update is a high priority feature of the system. This is the main feature of the
system which would be available to public and media.

3.5.2. Stimulus & Responses

Publish the result through

World Wide Web.

Sport Event Records

Player Records

Automatic or manual
online input

Scheduling
system

Give interfaces to access

data to registered media.

3.5.3. Functional Requirements

4. The System will be used only when a game is happening.
5. The online spectators should have a view of the current score of the game.
6. The scorer should have a user interface which is very easy to handle, so he can
update the changes quickly.
7. Both the scorers and spectators views should be able to customize according to
the game.
Example:
For an athletic event the time and position of each player is displayed in the
spectators view.
For volleyball event the score and the time is displayed in the spectators view.
8. When the score is fed automatically, the web site should update without any
involvements of humans. That is then the process should be completely
automated. The score and time information can be fed automatically for events

SoftwareRequirementsSpecificationforSportEventManagementFramework

like Athletic and Swimming. In the future it will be able to automate the other
events as well.

Participating Teams

Results for pass events

Players Records

Web Spectator/
Registered Media

Live Results

Event Schedule

Games Records

SoftwareRequirementsSpecificationforSportEventManagementFramework

3.6 Customizability
3.6.1 Description and Priority
The system should be customizable according to the requirements of the users. It should
be reusable from small scale to large scale Sports events. This is a high priority feature of
the system.

3.6.2. Functional Requirement

1. Features of the system will be added and removed dynamically. For an example
for small scale sport programs, management of accommodation and transportation
are not very important. So they will be removed from the system easily in such
cases.
2. The sport events arranged in a sport program are different from one to another.
The system should be customizable to handle these differences.

3.7 Extensibility
3.7.1 Description and Priority
Extensibility is a key feature of the system. This allows adapt the system to changes in
the environment very easily. The system can be extended by adding more control over
data or adding new game events which have different characteristics than the convention
games.

3.7.2. Functional Requirements

1. System should be able to integrate with modules which use processed data in the
existing system and generate completely new result.
Example:
Take a situation where the system is used to provide security to the whole event.
Then they should have the access to accommodation, transportation, playground
section and get information from there and generate the security plan. Then the IT
Manager of the security section should be able to add the module to the system
easily.
2. The games are having different characteristics. When there is a completely new
game introduced, then the IT Manger of the event section should be able to add
the game characteristics just by using a graphical interface or using similar easy
method.

SoftwareRequirementsSpecificationforSportEventManagementFramework

4. External Interface Requirements

a.

User Interfaces

There are many stake holders in the system and they have different interests in the
system. Thus system has to make sure that they get to what they want with minimum
effort.
All the user interfaces will be presented using web pages. This will allow this product to
be used in multiple platforms.
User interfaces should be extremely user friendly and comprehensive. System should
provide necessary information at the same time not overloading pages with information.
Each page in the interface should have navigation bar which indicates the place he is
currently at. Also same navigation or other mechanism should allow him to easily go up
and down the hierarchy.
If the user is logged into the system it should be clearly displayed on the page. Also there
should be a logout button in a clearly visible area for such users.
If privileged user try to modify data every time it should prompt for verification.
All the error messages should contain the cause of error and a description of the error
message.
Maximum width of the page should be 800. This is to cater people who are using lower
resolution. But interface layouts should not be out of order when they are viewed with
higher resolution displays.
All formatting of the display area should use style sheets. Every implementation of styles,
layouts or any other scripting should be browser independent.

b.

Software Interfaces

Connection to shared resources like databases should be done using the libraries provide
in the core of the system. Also each module can have its own library functions which are
specific to that module. Module developers should user provided libraries to develop
their modules as far as possible. Also there can be lot of web services offered by modules.
These are intended of information sharing. Using these modules any stake holder (like
hotel owners, transport providers, etc) can interact with the system. Also there can be any
number of modules which can provide external interfaces, which can be used to interact
with the system.

SoftwareRequirementsSpecificationforSportEventManagementFramework

c.

Communications Interfaces

System will make use of email facility or similar kind of messaging service to most of the
authorized users. This will enable them to manage their work much easily. System might
provide easy to manage and integrate module.
Also some modules will interact with internal and external modules through web
services. Communication with external modules will be though secure. This security can
be achieved either at protocol level or at application level.

5 Other Nonfunctional Requirements

5.1 Performance Requirements
Every function provided by the system should be robust without slowing down the
system or annoying the users.
If there are more request queries on the system than it can handle, system should
operate without crashing by limiting number of queries. Also at such a time system
should not drag the functionalities of the more privileged users.

5.2 Safety Requirements

Since the product is freely available to use, any kind of loss, damage or harm caused by
use of the product will be a concern of the user.

5.3 Security Requirements

All the data associated with the product should be secure and only the privileged users
should have the access to the data.
Write on the data should only be provided if there are required privileges. And only read
only access should be grated for users who are viewing the data.
All the manipulation of modification should be logged in details for security auditing.

5.4 Software Quality Attributes

System should be adaptable to every sport event which needs the functionalities
provided by the system. System should have an availability of 99% when implemented.
All the functionalities provided by the system should be checked for correctness with test
data and should guarantee that these are within required standards before use.
Modules developed for the system should be independent of other modules and should
adhere to the guidelines (if any) provided. They should be loosely coupled with the core
of the system and flexible to changes.
All the functionalities in the system should adhere to international standards to improve
interoperability.

SoftwareRequirementsSpecificationforSportEventManagementFramework

System should be used on any platform that support open technologies. Also it should
be easily maintainable.
System should be heavily reliable and robust.
Most importantly system should be easily usable. People should be able to work on the
system with minimum training and higher level of comfort.

6 Other Requirements
If system is to be used in some event people who planned to use the system should
make sure that the system is behaving accordance with the target legal frame and
requirements. And if it is not they should make appropriate adjustments.