Online Backstage Management System
Software Requirements SpecificationSoftware Requirements Specification Page 2 of 59
Table of Contents
Table of Contents............................................................................................................ 2
1. Introduction................................................................................................................. 5
1.1. Purpose of this Document:.................................................................................. 5
1.2. Acronyms and Definitions .................................................................................. 5
1.3. RSSS Definitions ................................................................................................ 6
1.4. References........................................................................................................... 7
2. General Overview ....................................................................................................... 8
2.1. User Characteristics ............................................................................................ 8
2.1.1. User interface requirements ........................................................................ 8
2.1.2. Product Style Requirements........................................................................ 8
2.1.3. Ease of Use ................................................................................................. 8
2.1.4. Ease of Learning ......................................................................................... 9
2.2. Product Perspective............................................................................................. 9
2.3. Functional Requirements Overview ................................................................. 10
2.4. Data Requirements Overview........................................................................... 10
2.5. Constraints, Assumptions, Dependencies, Guidelines...................................... 10
2.5.1. Assumptions / Constraints ........................................................................ 10
2.5.2. Dependencies ............................................................................................ 11
2.5.3. Guidelines ................................................................................................. 11
2.6. User view of Product Use ................................................................................. 11
3. Specific Requirements .............................................................................................. 12
3.1. External Interface Requirements....................................................................... 12
3.1.1. System / Guide Book ................................................................................ 12
3.1.2. Wireless Network...................................................................................... 12
3.1.3. User Interface............................................................................................ 12
3.1.4. Web Server................................................................................................ 13
3.1.5. Database.................................................................................................... 13
3.1.6. Operating System...................................................................................... 13
3.1.7 System Context Diagram .............................................................................. 14
3.2. Functional Requirements .................................................................................. 15
3.2.1. Functional Requirements Template .......................................................... 15
3.2.2. Functional Requirement 1: Import data from guide book ........................ 15
3.2.3. Functional Requirement 2: Register Competitor ...................................... 16
3.2.4. Functional Requirement 3: Configurable Screens .................................... 16
3.2.5. Functional Requirement 4: Recording of Results..................................... 17
3.2.6. Functional Requirement 5: Distribute Updated information to key staff . 17
3.2.7. Functional Requirement 6: Maintain Historical Records ......................... 17
3.2.8. Functional Requirement 7: No client install ............................................. 18
3.2.9. Functional Requirement 8: Resemble Existing System............................ 18
3.2.10. Functional Requirement 9: Printouts / Reporting ..................................... 18
3.2.11. Functional Requirement 10: Security ....................................................... 19
3.2.12. Functional Requirement 11: Administration Panel................................... 19Software Requirements Specification Page 3 of 59
3.2.13. Functional Requirement 12: Multiple Sites .............................................. 19
3.2.14. Functional Requirement 13: Group/School Registration.......................... 20
3.2.15. Functional Requirement 14: Move Competitor between sections............ 20
3.2.16. Functional Requirement 15: Register by section ...................................... 20
3.2.17. Functional Requirement 16: Welcome Screen ......................................... 21
3.2.18. Functional Requirement 17: Display sections that competitor is in ......... 21
3.2.19. Functional Requirement 18: Data Backup / Restore................................. 21
3.2.20. Functional Requirement 19: Field Validation........................................... 22
3.2.21. Functional Requirement 20: Roles............................................................ 22
3.2.22. Functional Requirement 21: Discipline .................................................... 23
3.2.23. Functional Requirement 22: Section......................................................... 24
3.2.24. Functional Requirement 23: Competitor .................................................. 26
3.2.25. Functional Requirement 24: Competitor Number .................................... 26
3.2.26. Functional Requirement 25: Competitor Sequence Number.................... 27
3.2.27. Functional Requirement 26: Communication Tool .................................. 27
3.2.28. Functional Requirement 27: PDA Compatibility ..................................... 28
3.2.29. Functional Requirement 28: TV Display.................................................. 28
3.2.30. Functional Requirement 29: Debating ...................................................... 28
3.3. Non-Functional Requirements.......................................................................... 29
3.3.1. Non-Functional Requirement 1: Website Theme ..................................... 29
3.3.2. Non-Functional Requirement 2: Easy to Use ........................................... 29
3.3.3. Non-Functional Requirement 3: Maintainability...................................... 29
3.3.4. Non-Functional Requirement 4: User Manuals ........................................ 29
3.3.5. Non-Functional Requirement 5: Date Formats......................................... 29
3.3.6. Non-Functional Requirement 6: Language............................................... 30
3.3.7. Non-Functional Requirement 7: Network ................................................ 30
3.4. Data Requirements............................................................................................ 30
3.4.1. Discipline .................................................................................................. 30
3.4.2. Section....................................................................................................... 31
3.4.3. Competitor ................................................................................................ 32
3.5. Performance Requirements............................................................................... 32
3.6. Quality Attributes / Requirements .................................................................... 32
3.6.1. Security ..................................................................................................... 32
3.6.2. Availability ............................................................................................... 32
3.6.3. Reliability.................................................................................................. 33
3.6.4. Maintainability.......................................................................................... 33
3.7. Other Requirements .......................................................................................... 34
4. Appendix A............................................................................................................... 35
4.2. Use Case Diagrams ........................................................................................... 35
4.2.1. Use Case 1: User Logon, not admin ......................................................... 36
4.2.1.1. Use Case Diagram..................................................................................... 36
4.2.1.2. Use Case Detailed Description ................................................................. 36
4.2.2. Use Case 2: User Logon, admin ............................................................... 37
4.2.2.1. Use Case Diagram..................................................................................... 37
4.2.2.2. Use Case Detailed Description ................................................................. 37
4.2.3. Use Case 3: User Logoff........................................................................... 38Software Requirements Specification Page 4 of 59
4.2.3.1. Use Case Diagram..................................................................................... 38
4.2.3.2. Use Case Detailed Description ................................................................. 38
4.2.4. Use Case 4: Register Competitor - By Section......................................... 39
4.2.4.1. Use Case Diagram..................................................................................... 39
4.2.4.2. Use Case Detailed Description ................................................................. 39
4.2.5. Use Case 5: Register Competitor - By Competitor / School .................... 40
4.2.5.1. Use Case Diagram..................................................................................... 40
4.2.5.2. Use Case Detailed Description ................................................................. 40
4.2.6. Use Case 6: Import Data from Guidebook ............................................... 42
4.2.6.1. Use Case Diagram..................................................................................... 42
4.2.6.2. Use Case Detailed Description ................................................................. 42
4.2.7. Use Case 7: Print Reports ......................................................................... 43
4.2.7.1. Use Case Diagram..................................................................................... 43
4.2.7.2. Use Case Detailed Description ................................................................. 43
4.2.8. Use Case 8: Backup Data.......................................................................... 45
4.2.8.1. Use Case Diagram..................................................................................... 45
4.2.8.2. Use Case Detailed Description ................................................................. 45
4.2.9. Use Case 9: Restore Data.......................................................................... 46
4.2.9.1. Use Case Diagram..................................................................................... 46
4.2.9.2. Use Case Detailed Description ................................................................. 46
4.2.10. Use Case 10: Configure Screens............................................................... 47
4.2.10.1. Use Case Diagram................................................................................. 47
4.2.10.2. Use Case Detailed Description ............................................................. 47
4.2.11. Use Case 11: Enter Results....................................................................... 48
4.2.11.1. Use Case Diagram................................................................................. 48
4.2.11.2. Use Case Detailed Description ............................................................. 48
4.2.12. Use Case 12: Update Section Information (i.e. Order)............................. 49
4.2.12.1. Use Case Diagram................................................................................. 49
4.2.12.2. Use Case Detailed Description ............................................................. 49
4.2.13. Use Case 13: Move Competitor between sections.................................... 50
4.2.13.1. Use Case Diagram................................................................................. 50
4.2.13.2. Use Case Detailed Description ............................................................. 50
4.2.14. Use Case 14: Display Competitor Information......................................... 51
4.2.14.1. Use Case Diagram................................................................................. 51
4.2.14.2. Use Case Detailed Description ............................................................. 51
4.3. Entity Relationship Diagrams ........................................................................... 52
4.4. State-Transition Diagrams ................................................................................ 53
4.4.1. Competitor ................................................................................................ 53
5. Acceptance Criteria................................................................................................... 54
5.1. Acceptance criteria – Functional Requirements ............................................... 54
5.2. Acceptance Criteria – Non-Functional Requirements ...................................... 57
Declaration:................................................................................................................... 58
References..................................................................................................................... 59Software Requirements Specification Page 5 of 59
1. Introduction
1.1. Purpose of this Document:
The main purpose of this document is to outline the functional and performance
requirements of the Online Backstage Management System. This is not a design oriented
document; the design will be outlined in the Software Design Description (SDD)
1.2. Acronyms and Definitions
Any acronyms referenced in this document will be listed below:
ACRONYM MEANING
AJAX Asynchronous Javascript And XML
OBMS Online Backstage Management System
RSSS Royal South Street Society
SDD Software Design Description
SPMP Software Project Management Plan
SRS Software Requirement Specification
WBS Work Breakdown StructureSoftware Requirements Specification Page 6 of 59
1.3. RSSS Definitions
WORD MEANING RELATES TO
Adjudicator The “Judges” for each Discipline All
Arranger Person who arrange the music being
performed
Vocal, Piano,
Instrumental
BO Black Out – Refers to whether the stage is in
darkness. Options generally ‘S’ start and ‘F’
finish
Dance and
Callisthenics
Chairman Announces each performance and provides
results
All
Composer Person who created the original music Vocal, Piano,
Instrumental
CYC Refers to a stage backing curtain, options
include ‘B’ black, ‘W’ white or ‘S’ silver
All
Discipline An overall classification such as junior vocal,
Debating, speech and drama
All
Division A sub-category within a section All
Floor Plan Refers to stage layouts for props and or
equipment
Dance,
Callisthenics,
Instrumental
Lyrics Person who wrote the lyrics Vocal, Piano,
Instrumental
MID Refers to a curtain across the middle of the
stage, options ‘yes’ or ‘no’
Dance and
Callisthenics
Registration Where competitors confirm their arrival, and
supply relevant information
All
REVEAL Raising or lowering of the front curtain
required, options ‘yes’, ‘no’, ‘start’, ‘finish’
Dance and
Callisthenics
Section A specific category within a discipline All
Stage Manager Responsible for ensuring each section runs
smoothly and deals with any issues
All
Steps Refers to a set of mobile stairs that can be
used on stage, options are a number of sets of
steps 1-4, and colour being ‘gold’ or ‘silver’
Dance and
Callisthenics
Title The name of the piece being performed Vocal, Piano,
InstrumentalSoftware Requirements Specification Page 7 of 59
1.4. References
The following documents are referenced to produce this document:Software Requirements Specification Page 8 of 59
2. General Overview
The application being built for the Royal South Street Society is an Online Backstage
Management System. It will involve the transformation of the current paper based system
used to manage competitors and their results, into a web based application that can
distribute key information to all required users instantly, without the requirement to
manually print and then distribute this information.
This general overview section outlines the requirements of the application, as seen by the
user. The other sections of the document are the technical specifications of the
requirements for the application.
2.1. User Characteristics
2.1.1. User interface requirements
The user interface must conform to the ease of use and ease of learning
requirements outlined below, so it must be clean, with all information easy to
find. Validation will be used on any fields that require it, and context sensitive
help will be implemented to provide assistance to users. Technologies such as
AJAX or similar may be used to provide an application that functions like a
desktop application, removing unnecessary screen updates or delays.
The user interface will be defined in detail in the Solution Design Document, as
there are no requirements for the user interface outlined by the client. Provided
the application gives the required functionality, design of the user interface will be
left to the project team.
2.1.2. Product Style Requirements
There is no requirement on style of the system. Component and font size, screen
layout and other specifics will be decided in the design phase, as the team
researches what will be the most user friendly and accessible design for the end
users. Client feedback will be important for this, as this will highlight anything
that is not straightforward to someone that is not familiar with the system.
2.1.3. Ease of Use
The system to be developed for the Royal South Street Society must be both
simple and intuitive to use.Software Requirements Specification Page 9 of 59
2.1.4. Ease of Learning
The system must be intuitive to use, so that current volunteers familiar with the
paper-based system can easily adapt to the computerized version. This will be
achieved by duplicating the current paper-based system as much as possible. The
ideal scenario will be that any user who is familiar with basic computer and web
browser functions, and is familiar with the current paper-based system, will be
able to use the system without any training.
2.2. Product Perspective
The new system for Royal South Street Society will be a stand-alone application. Its
only interface to another system will be through the guide book generated from the
office system, which is in Microsoft Word Format. (.doc).
It will be run on a client managed web server. Data will be distributed to client
machines over a wireless network.Software Requirements Specification Page 10 of 59
2.3. Functional Requirements Overview
The application will enable volunteers of Royal South Street Society to perform
competitor registration, and manage the distribution of data that comes with the
competition. There will be different user roles to go with the different people
involved in a competition, such as registration, stage manager, chairperson and
adjudicator.
The system will allow users to:
Register competitors.
Search for competitors.
Enter results.
View results.
View section information.
Change the order competitors will compete in.
Move a competitor to another section.
Enter section results.
Automatically import information from the guide book.
Functional requirements are documented in further detail in Section 3.2 - Functional
Requirements, and Use Cases in Section 4.2- Use Case Diagrams.
2.4. Data Requirements Overview
The system will store all discipline, section, competitor and result data for retrieval by
users. It will also store system configuration to enable the custom screens. Any
historical data will also be stored so it is accessible, but also identifiable as historical
data.
2.5. Constraints, Assumptions, Dependencies, Guidelines
2.5.1. Assumptions / Constraints
Client will perform all system maintenance once handed over.
Client will provide the training for users.
Client will setup the network and perform maintenance on it.
Client will be responsible for hardware maintenance.Software Requirements Specification Page 11 of 59
2.5.2. Dependencies
The system is dependent on the guide book containing accurate data. If the data is
inaccurate in the guide book, manual updates by the administrator will be required
or any other form of import will be considered.
2.5.3. Guidelines
There are no guidelines at this stage.
2.6. User view of Product Use
From a user’s perspective, we will be trying as much as possible to simply swap their
current paper system for registration and stage management, with the new
computerized system. The goal is to replicate the system as much as possible, so that
the data entry and processing is the same as if they were to use their paper based
system, simply moved to a computer screen. This will remove problems of lost paper,
and the possibility of volunteer injury through trying to distribute the information.
The system will store information on disciplines, competitors and sections, as well as
their results.Software Requirements Specification Page 12 of 59
3. Specific Requirements
The below sections outline the specific requirements of the system.
3.1. External Interface Requirements
The sections below describe the requirements of the application to each of the
external interfaces to it.
3.1.1. System / Guide Book
The key input for this system is a guide book produced from the office
registration system. This guide book is produced in MS-Word format (.doc), and
may not have a predictable layout for parsing. The source system of this
document cannot be updated, so it is the responsibility of our system to have the
capability to parse and import this guide book. Some manual intervention by an
administrator to convert / import this document is acceptable, but the more
automated this can be, the better. It is likely that text files containing the required
information could be produced in replacement of the guide book for easier
parsing. These are the options available to the project team, thus the team is going
to use an easy means to parse information into our system.
3.1.2. Wireless Network
The system will interface with the wireless network through an intermediate
application, the web server on the operating system. Therefore the application will
be network-independent, as all network management will be performed by the
operating system and web server.
3.1.3. User Interface
The user interface must be accessible without the installation of client software.
Therefore the interface will be web-based. This interface must conform to the
relevant standards, and also meet the Ease of Use and Ease of Learning
requirements outlined in sections 2.1.3 and 2.1.4.Software Requirements Specification Page 13 of 59
3.1.4. Web Server
The web server must be easy to install and maintain, while also supporting the
coding language that is used to develop the application. A client managed web
server will be needed, as the system will not be accessible via the internet.
3.1.5. Database
The database will be separate to the application, and must be reliable and easy to
use. This database must interface with the web server, so that the web based
application can interface with it. It does not have to be on the same physical
machine as the web server, but this will be the most logical place for it to improve
performance, etc.
3.1.6. Operating System
The operating system of the server must be easy to use, with little maintenance
required by the client. The client has experience in Linux, specifically Red Hat,
but any similar Linux distribution will be acceptable.Software Requirements Specification Page 14 of 59
3.1.7 System Context Diagram
Performance
Chairman
Adjudicator
Server
Stage Manager
Registration
Front of House
OBMS other location
InternetSoftware Requirements Specification Page 15 of 59
3.2. Functional Requirements
3.2.1. Functional Requirements Template
This template is how all following functional requirements should be documented.
A general description will be used in the place of this paragraph, plus a table for the
inputs, processing and outputs for the component.
INPUTS: Which inputs; in what form/format will inputs arrive; from what
sources input will be derived, legal domains of each input element.
PROCESSING: Describes the *outcome* rather than the *implementation*;
include any validity checks on the data, exact timing of each
operation (if needed), how to handle unexpected or abnormal
situations.
OUTPUTS: The form, shape, destination, and volume of the output; output
timing; range of parameters in the output; unit measure of the
output; process by which the output is stored or destroyed; process
for handling error messages produced as output.
MANDATORY: Yes/No/Future
List of functional requirements:
3.2.2. Functional Requirement 1: Import data from guide book
Currently the Royal South Street Society have two systems, an old computerized system
used in the office for collection of competitor information for billing purposes and
compilation of the “Guide Book”, and a paper based system for managing the
competition. The office system is required to provide the information on the
competitors, sections, and disciplines. The only output from this system is a word
document that is printed and used as a guide book. The requirement for the Online
Backstage Management System is to import this word document into the database.
Refer to Appendix A, use case 6 on this item.
INPUTS: Guide Book document from the office application – Word
Format(.doc)
PROCESSING: 1. Convert the document to a text file.
2. Parse the document, reading all sections, disciplines, and
competitor details.
3. Perform data validation.
OUTPUTS: Insert the information into the application database.
MANDATORY: YesSoftware Requirements Specification Page 16 of 59
3.2.3. Functional Requirement 2: Register Competitor
When a competitor arrives on the day, they need to register to say that they have
arrived, and provide any information required for their event. These competitors will
already have registered for the competition, and will be listed in the guide book. The
system must be able to register them based on name. Depending on the section, they
will be required to provide different information. Refer to Appendix A, use cases 4 and
5 on this item.
INPUTS: Competitor’s name, age, sections, other information for section.
PROCESSING: Sections that the competitor has to register for are brought up.
Request information required for each section
Validate data inputs.
OUTPUTS: Insert the information into the application database
List competitor as “Registered” and “Available to Compete”.
MANDATORY: Yes
3.2.4. Functional Requirement 3: Configurable Screens
Due to the various information required for each section in an event, and the fact that
many volunteers have different ways for doing the same job, the system must have the
ability for screens to be configured so that certain information can be selectable in
whether it is displayed or not. For example, the administrator will want to turn off
names from being displayed to the Adjudicators. This could apply to both the data input
and output screens. In the data input screens, this could consist of mandatory fields.
Refer to Appendix A, use case 10 on this item.
INPUTS: Various information types that must be collected / displayed.
PROCESSING: Allow the user to select whether information is collected /
displayed.
OUTPUTS: Store the user selections for use in building screens.
MANDATORY: YesSoftware Requirements Specification Page 17 of 59
3.2.5. Functional Requirement 4: Recording of Results
For each section, the adjudicators record their results and determine a winner. The
system must be able to store the competitors who won a place. There can be multiple
winners of each place. Refer to Appendix A, use case 11 for more information on this
item.
INPUTS: Competitor Name, Score, Place (First, Second, Third, Honorable
Mention, Highly Commended).
PROCESSING: Calculate the competitors place order.
OUTPUTS: Record the data for later retrieval.
MANDATORY: Yes
3.2.6. Functional Requirement 5: Distribute Updated information
to key staff
A large part of this project is the distribution of information. The current paper process
involves printing data out and walking to the various people to provide them with the
information. The system must allow for the information to be distributed dynamically to
those people, and also advise them that the information has changed. Refer to Appendix
A, use case 12 on this item.
INPUTS: Any information that has changed.
PROCESSING: Find out which people will need the updated information.
OUTPUTS: Advise the users that they have updated information.
MANDATORY: Yes
3.2.7. Functional Requirement 6: Maintain Historical Records
A major requirement is for the historical information from each year to be available for
easy recall. This may be used by the chairperson to speak about a person who has just
performed, etc.
INPUTS: All information at the end of each year.
PROCESSING: Mark information as old data.
OUTPUTS: Allow for easy recall of information.
MANDATORY: YesSoftware Requirements Specification Page 18 of 59
3.2.8. Functional Requirement 7: No client install
The system must be written so that there is no software install required on the client
side. This is to ensure that setup for the client is as simple and painless as possible. As
this will be accomplished via a website, the system must support both Internet Explorer
and Firefox web browsers.
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY: Yes
3.2.9. Functional Requirement 8: Resemble Existing System
The new system must resemble the current, paper based system.
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY: Yes
3.2.10. Functional Requirement 9: Printouts / Reporting
The system must be able to print out some of the information as a backup, if the system
goes down.
Each of the screens containing section and / or competitor information will have a
“Printer Friendly” screen to have the information readable on paper. Refer to Appendix
A, use case 7 for more details on this item.
INPUTS: Section Information.
PROCESSING: Format for printout.
OUTPUTS: Display information on screen for printing.
MANDATORY: YesSoftware Requirements Specification Page 19 of 59
3.2.11. Functional Requirement 10: Security
The system will have two layers of security, wireless networking security, and
administration security. Wireless security will be handled by the client, while the
administration panel security will be handled by the application. Refer to Appendix A,
use case 2 and 3 on administration panel security
INPUTS: User information.
PROCESSING: Verify client details.
OUTPUTS: Advise of authentication result.
MANDATORY: Yes
3.2.12. Functional Requirement 11: Administration Panel
The system must have an Administration Panel that can be used to perform all
administration functions from any client machine. As per FR10 it will be secure, so that
only authorized users can access the panel. Refer to Appendix A, use case 2 and 3 on
administration panel
INPUTS: User administration functions.
PROCESSING: Store configuration data.
OUTPUTS: Run application based on stored configuration.
MANDATORY Yes
3.2.13. Functional Requirement 12: Multiple Sites
The system may be used at multiple sites simultaneously. Therefore it must be able to
maintain data integrity between the sites. Optionally, it should have a system in place to
merge the multiple sites data automatically into the master system.
INPUTS: Information input during the running of the event.
PROCESSING: Place data in database, without any errors.
OUTPUTS: A single correct database.Software Requirements Specification Page 20 of 59
MANDATORY: No
3.2.14. Functional Requirement 13: Group/School Registration
Some sections allow schools/groups to register in sections, rather than individual
competitors. As these schools like to register for all sections they are in on the day in
one go, the system must allow for a user to list all the sections the school/group is in,
and register them all at once. Refer to Appendix A, use case 5 for more details on this
item.
INPUTS: Name of School/Group to register.
PROCESSING: Find and display the sections School/Group is in.
OUTPUTS: School/Group registered.
MANDATORY: Yes
3.2.15. Functional Requirement 14: Move Competitor between
sections
On rare occasions, a user will be moved into a different section, prior to the competitor
registering. The system must allow for the stage manager or chairperson to move this
person to another section. Refer to Appendix A, use case 13 for more details on this
item
INPUTS: Name of the competitor to move.
PROCESSING: Remove the competitor from the old section, add to the new
section, and place them to perform last.
OUTPUTS: Competitor moved to new section.
MANDATORY: Yes
3.2.16. Functional Requirement 15: Register by section
With the current system, competitors are registered per section, based on the guide
book. The system must allow for the person registering competitors to bring up a
section, and list the people competing in that event. Refer to Appendix A, use case 4 for
more details on this item.Software Requirements Specification Page 21 of 59
INPUTS: Section to register competitors.
PROCESSING: Get competitors in this section.
OUTPUTS: Display competitors in this section, and option to register the
competitor.
MANDATORY: Yes
3.2.17. Functional Requirement 16: Welcome Screen
The system must have a welcome screen that will display important information for the
day. This will primarily be a list of sections that are to occur on the day.
INPUTS: Current day.
PROCESSING: Find all sections for the day.
OUTPUTS: Display sections for the day.
MANDATORY: Yes
3.2.18. Functional Requirement 17: Display sections that
competitor is in
The system will allow for a user to search for a competitor, and bring up the sections
that the user is in. This will allow for the implementation of registration by schools.
INPUTS: Name of Competitor.
PROCESSING: Find competitor information.
OUTPUTS: List details for the competitor, including the section that they are
in.
MANDATORY: Yes
3.2.19. Functional Requirement 18: Data Backup / Restore
Due to the importance of the data being used, and the need to keep historical data for
reference information, the system will require a procedure for backing up the data. This
may be an automatic / nightly system, or a manual user initiated system. An attempt to
recover a lost backup will also be considered. Refer to Appendix A, use case 8 and 9
for more details on this itemSoftware Requirements Specification Page 22 of 59
INPUTS: All data stored by the system.
PROCESSING: Process the data so it can be backed up.
OUTPUTS: Backup the data to physical media, i.e. tape.
MANDATORY: Yes
3.2.20. Functional Requirement 19: Field Validation
To ensure that the application is as error free as possible and easy to use, all fields will
have validation on them. This could include checks that the data is in the correct format,
or that mandatory fields have not been left blank.
INPUTS: User input.
PROCESSING: Confirm field contains the correct data.
OUTPUTS: Submit information, or display error.
MANDATORY: Yes
3.2.21. Functional Requirement 20: Roles
The system will have multiple users with different purposes, so each type of user will be
defined as a role. There are 5 main roles that need to be part of the application:
Registration
Chairman
Stage Manager
Administrator
Adjudicator
Registration
Collects the required information from each competitor. Ensures copies are sent to the
relevant people in time for the section to comment. Need to have up-to-date
information to answer questions from competitors such as: how many have
withdrawn, which competitor are they up to, who won a previous section. Refer to
Appendix A, use case 1 and 3 on this role.
Chairman
The chairman is responsible for announcing each performer including relevant details
of the performance. They require accurate, up-to-date information. They will notify
backstage when the house (audience) is ready. They announce the final place getters
as decided by the adjudicators, and are often required to fill time with commentary.Software Requirements Specification Page 23 of 59
Stage Manager
The stage manager ensures the correct performers are on stage and the next performer
is ready at the side of the stage, or stage-side. They deal with any issues arising on the
stage. They require accurate, timely information on the performers and the sequence
they will be performing. They must know who is performing currently, and who is
next. They must also know the stage requirements, such as curtains, props, etc.
Adjudicator
The adjudicators are the judges of the event. They would see the same information as
the chairperson, but would not be able to see names. Refer to Appendix A, use case
10 on this role.
Administrator
The administrator is responsible for the smooth running of the application. They will
have access to run backups, configure screens, and perform any other tasks that
should not be attempted by the other users. The administrator role will be the only
role that requires a password. Refer to Appendix A, use case 2 and 3 on this role
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY: Yes
3.2.22. Functional Requirement 21: Discipline
A discipline is an overall category for different sections, for example, a discipline will
have many sections (events) in it. A list of disciplines is as below:
Instrumental
Speech & Drama
Twilight Concerto
Senior Vocal
Choral
Dancing
Modern Vocal
Country Music
Junior Vocal
Debating
Electronic Organ
Theatre Pipe Organ
Piano ForteSoftware Requirements Specification Page 24 of 59
Each discipline can have many sections within it.
The system must store the following information for each discipline:
Discipline Identifier – up to 5 characters as a unique identifier.
Discipline Description – a brief description of the discipline.
Discipline Name – name of the discipline.
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY:
Yes
3.2.23. Functional Requirement 22: Section
A section is a specific category within a Discipline. It can also be called an event. Each
section can only be part of one discipline.
Each section will have the following information:
Section Identifier / Section Number.
Section Description.
Date section is scheduled.
Time section is scheduled.
The sequence that each section is during the time allotment (Each day is split
into 2 or 3 sessions. Morning, Afternoon and Evening. The time listed for each
section is the start time of the “session” e.g. 9am start for the morning session
which may have four sections. It must be possible to identify the order of
sections during each session.)
Any age limit that might apply to the section.
The location of the section.
Any time limits that apply.
Any special instructions – these will be entered by the administrator.
INPUTS: N/A
PROCESSING: N/ASoftware Requirements Specification Page 25 of 59
OUTPUTS: N/A
MANDATORY:
YesSoftware Requirements Specification Page 26 of 59
3.2.24. Functional Requirement 23: Competitor
A competitor is a specific person or school that will be performing in a section. A
competitor can compete in many different sections during the competition.
A competitor must have the following information:
Surname:
Given Name:
Location:
Sections Competing in:
Notes: - anyone can manually enter notes in here.
Age:
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY:
Yes
3.2.25. Functional Requirement 24: Competitor Number
Each competitor, when they compete in a section, will be given a number unique to that
section. Once created, this number cannot be changed. Any new competitors will be
given the next available number.
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY:
YesSoftware Requirements Specification Page 27 of 59
3.2.26. Functional Requirement 25: Competitor Sequence
Number
The competitor sequence number describes the order in which the competitors must
perform. It is used by the stage manager to keep track of who goes on stage when. This
number can be changed if required to change the order of presentation. This number is
unique only in the section it is created in.
INPUTS: N/A
PROCESSING: N/A
OUTPUTS: N/A
MANDATORY:
Yes
3.2.27. Functional Requirement 26: Communication Tool
As each of the users of the system will be distributed in different parts of the event
venue, the ability to convey messages through the system would be beneficial. This
must be integrated into the rest of the application, and must follow the same principles
of ease-of-use section 2.1.3, ease-of-learning section 2.1.4, etc as the other components.
INPUTS: Recipient, Message.
PROCESSING: Determine where the recipient is logged on.
OUTPUTS: Display the message on the recipients screen.
MANDATORY:
FutureSoftware Requirements Specification Page 28 of 59
3.2.28. Functional Requirement 27: PDA Compatibility
For use by users, and other roaming volunteers, PDA compatible screens would be
utilized by users with wireless capable PDA’s, to display relevant information quickly.
If implemented, this would be a read only section with information on the schedule for
the day, and an overview of each of the sections.
INPUTS: N/A
PROCESSING: Convert data to PDA compatible/readable form.
OUTPUTS: Display the message on the PDA.
MANDATORY:
Future
3.2.29. Functional Requirement 28: TV Display
Currently, TVs and fixed video cameras are used to show the screen in places where the
stage is not directly visible. The possibility of displaying information about the event
that is currently running, coming up, etc will be investigated as part of this project; this
is an optional requirement at this stage.
INPUTS: N/A
PROCESSING: Convert data to TV compatible/readable form.
OUTPUTS: Display the message on the TV.
MANDATORY:
Future
3.2.30. Functional Requirement 29: Debating
Debating is a unique discipline, in that competitors compete as teams of 3, against
another team. One team is assigned as affirmative, the other as negative, and the debate
is a set topic. The system must be able to account for this scenario.
INPUTS: Teams and Topics.
PROCESSING: Store the data.
OUTPUTS: Display the teams and Topics.
MANDATORY:
MandatorySoftware Requirements Specification Page 29 of 59
3.3. Non-Functional Requirements
3.3.1. Non-Functional Requirement 1: Website Theme
The client is flexible in terms of the color scheme to be used for the website;
however, his input will be considered. Client will be involved in every
development stage of the website. The logo’s look and color is not to be changed
without client’s consent.
3.3.2. Non-Functional Requirement 2: Easy to Use
A requirement of the system is that it is easy to use. This information will be
documented in the ease of use (Section 2.1.3) and ease of learning (Section 2.1.4)
sections of this document. An example of this is to allow users to navigate using
the TAB key, not the mouse.
3.3.3. Non-Functional Requirement 3: Maintainability
The project team will not be responsible for the system once it is handed over to
the client. Therefore the system must be well developed and documented to
ensure that the client can maintain the system without assistance from the project
team.
3.3.4. Non-Functional Requirement 4: User Manuals
There are three separate user manuals that are required for this system. The first is
an end user manual, which outlines how the end user will use the system. This
will be broken up into role-based manuals. The second is an administration
manual, so that a user can administer the system. The final manual will be a
maintenance manual, so that the client has a reference when they go to update the
system.
3.3.5. Non-Functional Requirement 5: Date Formats
The system must conform to the Australian date format, i.e. dd/mm/yyyy.Software Requirements Specification Page 30 of 59
3.3.6. Non-Functional Requirement 6: Language
The application will be written in Australian English.
3.3.7. Non-Functional Requirement 7: Network
The application will run over a wireless network, which is supplied by the client.
3.4. Data Requirements
As the purpose of this application is to store and distribute information, it must store a
large amount of data. Listed below is the data that must be stored by the application.
Discipline information is listed at Functional Requirement 21: Discipline
Section information is listed at Functional Requirement 22: Section
Competitor information is listed at Functional Requirement 23: Competitor
Location: The location for the event will be stored in the application: e.g. Her
Majesties Theatre:
Id
Name
Address
Information about the application settings, screen configuration, etc will also be
stored. This data will be documented in the SDD. Also refer to Section 4.3 for ER
diagram.
3.4.1. Discipline
The following information is what needs to be stored for each discipline.
Discipline Identifier – up to 5 characters as a unique identifier.
Discipline Description – a brief description of the discipline
Discipline Name – Name of the discipline.
The following data needs to be collected for the disciplines:
RELATES TO ACRONYM NAME MEANINGSoftware Requirements Specification Page 31 of 59
3.4.2. Section
The following information is what needs to be stored for each section:
Section Identifier / Section Number.
Section Description.
Date section is scheduled.
Time section is scheduled.
The sequence that each section is during the time allotment (Each day is
split into 2 or 3 sessions. Morning, Afternoon and Evening. The time listed
for each section is the start time of the “session” E.g. 9am start for the
morning session which may have four sections. It must be possible to
identify the order of sections during each session).
Any age limit that might apply to the section.
The location of the section.
Any time limits that apply.
Any special instructions – these will be entered by the administrator.
Vocal, Piano, Instrumental Arranger Person who arrange the music being
performed.
Dance and Callisthenics BO Black Out – Refers to whether the stage is in
darkness. Options generally ‘S’ start and ‘F’
finish.
Vocal, Piano, Instrumental Composer Person who created the original music.
All CYC Refers to a stage backing curtain, options
include ‘B’ black, ‘W’ white or ‘S’ silver.
Dance, Callisthenics,
Instrumental
Floor Plan Refers to stage layouts for props and or
equipment.
Vocal, Piano, Instrumental Lyrics Person who wrote the lyrics.
Dance and Callisthenics MID Refers to a curtain across the middle of the
stage, options ‘yes’ or ‘no’.
Dance and Callisthenics REVEAL Raising or lowering of the front curtain
required, options ‘yes’, ‘no’, ‘start’, ‘finish’.
Dance and Callisthenics Steps Refers to a set of mobile stairs that can be
used on stage, options are a number of sets of
steps 1-4, and colour being ‘gold’ or ‘silver’.
Vocal, Piano, Instrumental Title/Source The name of the piece being performed.
Speech, Drama Author Person who wrote the piece.
Speech and Drama Book Book piece is sourced from.
All Copyright Whether the item is under copyright, and the
original has been seen.Software Requirements Specification Page 32 of 59
3.4.3. Competitor
The following information is what needs to be stored for each competitor.
Surname:
Given Name:
Location:
Sections Competing in:
Notes: - Anyone can manually enter notes in here.
Age:
3.5. Performance Requirements
The application will need to handle 3 users concurrently initially, with the possibility
of 10 users in the future. A user can also be defined as an unattended system used
solely for displaying information.
The system will hold data for approximately 12 disciplines, 1000’s of sections,
1000’s competitors, and 1 event per year.
The above information says that the load on the system will not be very high. Despite
this, it is important that the system be responsive to all end users, to ensure that users
do not get frustrated with the system.
3.6. Quality Attributes / Requirements
3.6.1. Security
Due to the nature of the data that must be stored on the system, it must be secure.
As the requirements include wireless networking and a web server, there must be
security on both of these layers. Security of the network will be handled by the
client, and is not included as part of this project. Security will be implemented on
the administration side of the application, to ensure that only authorized users will
be able to perform administration functions.
3.6.2. Availability
The system does not require being up all the time, as the system will be re-located
to multiple sites for the events, and the events only run for part of the year. TheSoftware Requirements Specification Page 33 of 59
system will however require a high uptime, with the desired result being up 100%
during events.
3.6.3. Reliability
The system will be replacing the current paper-based system, so the system must be
reliable and not lose any of the input data.
3.6.4. Maintainability
The system will be maintained by the client after delivery, so the system must have
suitable documentation for the client to be able to do so. This will include detailed
design / code information to ensure someone with basic technological knowledge,
including programming knowledge in the application language, can maintain the
system.Software Requirements Specification Page 34 of 59
3.7. Other Requirements
No other requirements at this time. Any further requirements will require a change
request form to be raised and to follow the steps outlined in the Change Control
Process document.Software Requirements Specification Page 35 of 59
4. Appendix A
4.2. Use Case Diagrams
The various tasks that must be performed by users of the system will be documented
as Use Cases. Each Use Case in this document will consist of a Use Case Diagram,
and a Use Case Detailed Description.
Figure 1 – Example Use Case Diagram
USE CASE NAME: Name of use Case.
SCENARIO: Scenario – if multiple use cases with different actors.
TRIGGERING EVENT: What starts this use case.
BRIEF DESCRIPTION: Describe the use case.
ACTORS: Who is involved.
STAKEHOLDERS: Who uses the information from the use case.
PRECONDITIONS: What has to be true before hand.
POSTCONDITIONS What has to be done afterwards.
FLOW OF EVENTS: ACTOR SYSTEM
1. Flow of Events.
2. For the actor.
1.1. Flow of Events.
2.1. For the system.
EXCEPTION CONDITIONS: 2. If 2 is not true, use case ends
Table 1 – Example Use Case Detailed Description
Use Case
ActorSoftware Requirements Specification Page 36 of 59
4.2.1. Use Case 1: User Logon, not admin
4.2.1.1. Use Case Diagram
Below is the use case diagram for the use case: User Logon, not admin
4.2.1.2. Use Case Detailed Description
Below is the use case detailed description for the use case: user logon, not
admin
USE CASE NAME: Logon
SCENARIO: Logon to non-administration screens.
TRIGGERING EVENT: User opens application.
BRIEF DESCRIPTION:
A user starts up the application in order to do their role. As each role
requires different information, they must select their role to view their
customized screens.
ACTORS: Adjudicator, Stage Manager, Chairperson, Registration.
STAKEHOLDERS: System
PRECONDITIONS: No user can be currently logged on to the current system instance.
POSTCONDITIONS User will be shown a welcome screen.
FLOW OF EVENTS: ACTOR SYSTEM
1. User Opens Application.
2. User selects their role.
1.1. Display list of roles
available.
2.1. System displays welcome
screen.
EXCEPTION CONDITIONS: 2.1. If user selects admin, they would be prompted for a password.
Commencing Use Case #2
Logon
Any UserSoftware Requirements Specification Page 37 of 59
4.2.2. Use Case 2: User Logon, admin
4.2.2.1. Use Case Diagram
Below is the use case diagram for the use case: User Logon, admin
4.2.2.2. Use Case Detailed Description
Below is the use case detailed description for the use case: user logon, admin
USE CASE NAME: Logon
SCENARIO: Logon to administration screens.
TRIGGERING EVENT: User opens application.
BRIEF DESCRIPTION: The administrator is required to make some changes to the application.
They will logon to the administration screen to perform these changes.
ACTORS: Administrator
STAKEHOLDERS: Adjudicator, Stage Manager, Registration, Chairperson.
PRECONDITIONS: No user can be currently logged on to the current application instance.
POSTCONDITIONS User will be shown the administration screen.
FLOW OF EVENTS: ACTOR SYSTEM
1. User opens application.
2. User selects their role.
3. User enters password.
1.1. Display list of roles
available.
2.1. System displays password
screen.
3.1. System authenticates
password, and displays admin
screen.
EXCEPTION CONDITIONS:
Logon
Admin UserSoftware Requirements Specification Page 38 of 59
4.2.3. Use Case 3: User Logoff
4.2.3.1. Use Case Diagram
Below is the use case diagram for the use case: User Logon,
admin/registration
4.2.3.2. Use Case Detailed Description
Below is the use case detailed description for the use case: user logoff
USE CASE NAME: Logoff
SCENARIO: Logoff the System.
TRIGGERING EVENT: User completes tasks / wishes to change roles.
BRIEF DESCRIPTION: When the user has completed their tasks, or wishes to change roles.
ACTORS: Any User
STAKEHOLDERS: Any User
PRECONDITIONS: User must be logged on to the system.
POSTCONDITIONS User will be shown the logon screen.
FLOW OF EVENTS: ACTOR SYSTEM
1. User selects logoff.
2. User is shown logon screen.
1.1. System destroys all session
information, and redirects user to
the logon screen.
EXCEPTION CONDITIONS: 2. Users selects Logon (See Logon Use Case 1).
Logoff
Any UserSoftware Requirements Specification Page 39 of 59
4.2.4. Use Case 4: Register Competitor - By Section
4.2.4.1. Use Case Diagram
Below is the use case diagram for the use case: User Logon, admin
4.2.4.2. Use Case Detailed Description
Below is the detailed description for the use case: register competitor by
section.
USE CASE NAME: Register Competitor
SCENARIO: Register Competitor by Section.
TRIGGERING EVENT: Competitor wishes to register for their event.
BRIEF DESCRIPTION: When a competitor arrives at the venue for the competition, they must
register to say that they are at the venue and ready to compete.
ACTORS: Registration
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager.
PRECONDITIONS: User must be logged on to the system as the Registration role
Competitor must be in the imported data from the guide book.
POSTCONDITIONS Competitor will be listed as registered for that section.
FLOW OF EVENTS: ACTOR SYSTEM
1. User selects the section to
perform the registration on.
2. User selects the competitor from
the list, and marks them as
registered.
3. User enters the required
information.
1.1. System retrieves and
displays list of competitors for
the section.
2.1 System displays screen
prompting for the required
information for this section.
3.1 System stores input
information, and marks
competitor as “Registered”.
EXCEPTION CONDITIONS:
2. Competitor is not in list: Invalid competitor, end Case.
3.1 Incorrect / incomplete information: System will redisplay screen.
2.1 With incomplete fields highlighted.
Register
RegistrationSoftware Requirements Specification Page 40 of 59
4.2.5. Use Case 5: Register Competitor - By Competitor / School
4.2.5.1. Use Case Diagram
Below is the use case diagram for the use case: Register competitor by
competitor / school
4.2.5.2. Use Case Detailed Description
Below is the use case detailed description for the use case: register competitor
by competitor / school.
USE CASE NAME: Register Competitor
SCENARIO: Register Competitor by Competitor, School.
TRIGGERING EVENT: Competitor wishes to register for their event.
BRIEF DESCRIPTION:
When a competitor arrives at the venue for the competition, they must
register to say that they are at the venue and ready to compete. The
option to register by competitor / school will be available as this is how
groups prefer to register.
ACTORS: Registration
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager
PRECONDITIONS: User must be logged on to the system as the Registration role.
Competitor must be in the imported data from the guide book.
POSTCONDITIONS Competitor will be listed as registered for that section.
FLOW OF EVENTS: ACTOR SYSTEM
1. User enters competitor / school
name to search for.
2. User selects the correct
competitor / school from the list.
3. User selects the sections from
the list, and marks them as
registered.
4. User enters the required
information.
1.1. System searches
competitors, and displays list of
matches.
2.1. System retrieves competitor
/ school information, with list of
sections competitor must register
for.
3.1. System displays screen
prompting for the required
information for this section.
3.2. System will display 3.1 for
each section registration is
performed on.
4.1. System stores input
information, and marks
competitor as “Registered”
Register
RegistrationSoftware Requirements Specification Page 41 of 59
4.2. 4.1. is performed on each
section above.
EXCEPTION CONDITIONS:
2. Competitor is not in list: Invalid competitor, end Case.
4.1 Incorrect / incomplete information: System will redisplay screen.
3.1 With incomplete fields highlighted.Software Requirements Specification Page 42 of 59
4.2.6. Use Case 6: Import Data from Guidebook
4.2.6.1. Use Case Diagram
Below is the use case diagram for the use case: Import Data from Guidebook
4.2.6.2. Use Case Detailed Description
Below is the use case detailed description for the use case: import data from
guidebook.
USE CASE NAME: Import Data from Guidebook
SCENARIO: Import Data from Guidebook
TRIGGERING EVENT: Guide book is ready to import event information for the current year.
BRIEF DESCRIPTION:
When competitors enter the competitions, they are entered into an
office system used to record all of their information. Once entry has
closed, a guide book for the event is generated for printing. This guide
book in Microsoft Word form (.doc) will be the source of competitor
and section information for this application.
ACTORS: Admin
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin
PRECONDITIONS: User must be logged on to the system as the Administration role.
POSTCONDITIONS Competitor and section information for the event will be in the system.
FLOW OF EVENTS: ACTOR SYSTEM
1. Admin selects file to import.
2. Admin looks at these failures,
and performs fixes / manual entry.
1.1. System retrieves file, and
parses it.
1.2. System displays any failed
parses / entries.
2.1. System takes information
and stores it as the current year’s
information.
2.2. System locks import option
for this year.
2.3. System displays successful
screen.
EXCEPTION CONDITIONS:
Import
Guidebook
AdminSoftware Requirements Specification Page 43 of 59
4.2.7. Use Case 7: Print Reports
4.2.7.1. Use Case Diagram
Below is the use case diagram for the use case: Print Reports
4.2.7.2. Use Case Detailed Description
Below is the use case detailed description for the use case: Print Reports
USE CASE NAME: Print Reports
SCENARIO: Print Reports
TRIGGERING EVENT: User wishes to print a report for reference / backup.
BRIEF DESCRIPTION: Incase the system goes down; some reports will be available for
printing so that there is a backup of all important information.
ACTORS: Chairperson, Registration, Stage manager, Administrator
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
PRECONDITIONS: User must be logged into the system.
POSTCONDITIONS
FLOW OF EVENTS: ACTOR SYSTEM
1. User selects the reports screen.
2. User selects the report they wish
to view.
1.1. System gets list of reports
and displays them.
2.1. User prompts for any extra
information required for the
report.
Print Reports
Chairperson Admin
Registration Stage ManagerSoftware Requirements Specification Page 44 of 59
3. User inputs required
information.
4.1 User prints the report using
standard Operating System print
options.
3.1 System displays the report
on a screen in a printable format.
EXCEPTION CONDITIONS:Software Requirements Specification Page 45 of 59
4.2.8. Use Case 8: Backup Data
4.2.8.1. Use Case Diagram
Below is the use case diagram for the use case: Backup Data
4.2.8.2. Use Case Detailed Description
Below is the use case detailed description for the use case: Backup Data
USE CASE NAME: Backup Data
SCENARIO: Backup Data
TRIGGERING EVENT: Admin wishes to have a data backup.
BRIEF DESCRIPTION: To minimize data loss from a system problem, the administrator will
perform backups of all application data.
ACTORS: Administrator
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
PRECONDITIONS: User must be logged into the system.
POSTCONDITIONS Data will be backed up.
FLOW OF EVENTS: ACTOR SYSTEM
1. Admin goes to the backup
utility, choosing an output file.
2. Admin user places file on
backup media.
1.1. System generates backup
file, and provides it for
download.
EXCEPTION CONDITIONS:
Backup Data
AdminSoftware Requirements Specification Page 46 of 59
4.2.9. Use Case 9: Restore Data
4.2.9.1. Use Case Diagram
Below is the use case diagram for the use case: Restore Data
4.2.9.2. Use Case Detailed Description
Below is the use case detailed description for the use case: restore data
USE CASE NAME: Restore Data
SCENARIO: Restore Data
TRIGGERING EVENT: Admin wishes to restore a data backup.
BRIEF DESCRIPTION: If data has been lost from the system, the administrator should
perform a data restore/backup function
ACTORS: Administrator
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
PRECONDITIONS: User must be logged into the system.
POSTCONDITIONS Data will be restored.
FLOW OF EVENTS: ACTOR SYSTEM
1. Admin goes to the backup
utility, choosing an input file to
restore.
1.1. System will take the input
file, and perform a restore.
EXCEPTION CONDITIONS:
Restore Data
AdminSoftware Requirements Specification Page 47 of 59
4.2.10. Use Case 10: Configure Screens
4.2.10.1. Use Case Diagram
Below is the use case diagram for the use case: Configure Screens
4.2.10.2. Use Case Detailed Description
Below is the use case detailed description for the use case: configure screens
USE CASE NAME: Configure Screens
SCENARIO: Configure Screens
TRIGGERING EVENT: User wishes for the data displayed on screen to be changed.
BRIEF DESCRIPTION:
Due to different requirements by users for the data that they wish to
display on the screen, the system will have the ability for the
administrator to customize the screens each user type will see.
ACTORS: Administrator
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
PRECONDITIONS: User must be logged into the system.
POSTCONDITIONS User screens will display the chosen data.
FLOW OF EVENTS: ACTOR SYSTEM
1. Admin goes to the admin panel,
and chooses a role.
2. Admin user selects which field’s
user can see, and which they
cannot.
1.1. System produces a list of
valid data that the role can view.
2.1. System stores the selection
the user has made.
EXCEPTION CONDITIONS:
Configure
Screens
AdminSoftware Requirements Specification Page 48 of 59
4.2.11. Use Case 11: Enter Results
4.2.11.1. Use Case Diagram
Below is the use case diagram for the use case: Enter Results
4.2.11.2. Use Case Detailed Description
Below is the use case detailed description for the use case: Enter Results
USE CASE NAME: Enter Results
SCENARIO: Enter Results
TRIGGERING EVENT: Adjudicators determine the results for a section.
BRIEF DESCRIPTION: After each section, the adjudicators determine the place getters. These
results will then be recorded.
ACTORS: Chairman or Stage Manager
STAKEHOLDERS: Adjudicators, Chairperson
PRECONDITIONS: Adjudicator must be logged into the system.
POSTCONDITIONS Results will be in the system.
FLOW OF EVENTS: ACTOR SYSTEM
1. Adjudicator goes to the section
screen.
2. User associates a result with
each place getter.
1.1. System provides list of
competitor numbers, and an
option to associate a result with
each.
2.1. System will store the results.
EXCEPTION CONDITIONS:
Enter Results
AdjudicatorSoftware Requirements Specification Page 49 of 59
4.2.12. Use Case 12: Update Section Information (i.e. Order)
4.2.12.1. Use Case Diagram
Below is the use case diagram for the use case: Update Section Information
4.2.12.2. Use Case Detailed Description
Below is the use case detailed description for the use case: update section
information
USE CASE NAME: Update Section information
SCENARIO: Update Section information
TRIGGERING EVENT: Competitor wishes to change when they will compete.
BRIEF DESCRIPTION:
Sometimes a competitor will be unable to compete when they are
meant to, and will wish to change the time in which they compete. In
this case the stage manager will change the order that they compete.
The updated information will be instantly be viewable by stakeholders
ACTORS: Stage Manager, Registration
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
PRECONDITIONS: User must be logged into the system.
Competitor must be in the section and registered.
POSTCONDITIONS User will be placed in a different position.
FLOW OF EVENTS: ACTOR SYSTEM
1. User goes to the section screen.
2. User changes the position in
which the competitor will compete.
1.1. System generates list of
competitors and their details for
the section.
2.1 System stores the
competitor’s updated position,
and notifies all stakeholders.
EXCEPTION CONDITIONS:
Update Section
Information
Stage ManagerSoftware Requirements Specification Page 50 of 59
4.2.13. Use Case 13: Move Competitor between sections
4.2.13.1. Use Case Diagram
Below is the use case diagram for the use case: Move Competitor between
sections
4.2.13.2. Use Case Detailed Description
Below is the use case detailed description for the use case: move competitor
between sections.
USE CASE NAME: Move competitor between sections.
SCENARIO: Move competitor between sections.
TRIGGERING EVENT:
The competitor has a valid reason to change sections, and has been
approved by the office staff. Only the office staff can request that this
happen.
BRIEF DESCRIPTION: If a competitor must be moved out of a section to another section, this
will be performed by the stage manager.
ACTORS: Stage Manager
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Registration
PRECONDITIONS: User must be logged into the system.
Competitor cannot be registered.
POSTCONDITIONS Competitor will be in a new section, with a new competitor number.
FLOW OF EVENTS: ACTOR SYSTEM
1. User goes to the section the
competitor is in, and chooses to
move them.
2. User selects the section to move
the competitor to.
1.1. System displays a list of
sections the competitor can be
moved to.
2.1 System allocates the
competitor a new number based
on what is available for the
section.
2.2 System moves the
competitor to the new section.
2.3 System advises user that the
competitor has been moved.
EXCEPTION CONDITIONS:
Move Competitor
Stage ManagerSoftware Requirements Specification Page 51 of 59
4.2.14. Use Case 14: Display Competitor Information
4.2.14.1. Use Case Diagram
Below is the use case diagram for the use case: Display Competitor
Information
4.2.14.2. Use Case Detailed Description
Below is the use case detailed description for the use case: display competitor
information
USE CASE NAME: Display Competitor Information
SCENARIO: Display Competitor Information
TRIGGERING EVENT: User wishes to view competitor information.
BRIEF DESCRIPTION:
For a number of reasons, a user may wish to view the information
about a competitor, such as name, previous events and results, and
sections they are entered into in the current event.
ACTORS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
STAKEHOLDERS: Adjudicators, Chairperson, Stage Manager, Admin, Registration
PRECONDITIONS: User must be logged into the system.
POSTCONDITIONS Competitor information will be displayed.
FLOW OF EVENTS: ACTOR SYSTEM
1. User goes to competitor search
page.
2. User selects the best match.
1.1. System searches for a
competitor and brings up
possible matches.
2.1. System displays the selected
competitors information,
including past results and current
section information.
EXCEPTION CONDITIONS:
Display Competitor
Information
Any UserSoftware Requirements Specification Page 52 of 59
4.3. Entity Relationship Diagrams
A discipline has
A location
Competes
DISCIPLINE
Id (5 chars)
Description – Text
Name - Text
LOCATION
Id (5 chars)
Name – Text
Description – Text
Address - Text
SECTION
Id/Number
Description – Text
Date –Date
Time – Date
Sequence # - Num
Age Limit –
Location- Location
Time Limit
Instructions – Text
Discipline – ID FK
COMPETITOR
Surname
Given Name
Location:
Sections:
Notes:
Age:
School: BooleanSoftware Requirements Specification Page 53 of 59
4.4. State-Transition Diagrams
4.4.1. Competitor
The competitor goes through many states during the competition. They are shown
below in this state chart diagram.
Entered
Register
Registered
Competed
Competing
Competed with
Results
Results DecidedSoftware Requirements Specification Page 54 of 59
5. Acceptance Criteria
Acceptance criteria will ensure that all requirements are agreed to by the customer
business requirements (functional and non-functional) are clear and unambiguous. They
are also the metrics that measure success of the project. The objective of this section is to
identify and document acceptance criteria and associated metrics for each customer
business functional and non-functional requirement.
5.1. Acceptance criteria – Functional Requirements
FUNCTIONAL
REQUIREMENT #
REQUIREMENT ACCEPTANCE CRITERIA
AND ASSOCIATED METRICS
Functional
Requirement 1
Import Data from Guide Book Data from guide book (text)
has to be parsed into the
application without any loss
of data. All sections,
disciplines and competitors
have be parsed successfully
and data validation
performed.
Functional
Requirement 2
Register Competitor Sections competitor is
competing for are brought
up. Required competitor
information are entered and
validated then saved into the
database. The competitor
then be flagged as registered
Functional
Requirement 3
Configurable Screen The administrator should be
able to select what
information users want to be
displayed. The selection is
used to build a screen for
that user and only selected
information is displayed.
Functional
Requirement 4
Recording of Results Adjudicators determine the
winners of a section. The
application should be able to
calculate the winners place
order, like first, second,
third, honorable etc and data
to be recorded for later use.
Functional
Requirement 5
Distribute Updated Information to
key Staff
Updates to information
automatically cascaded to
all logged on users.Software Requirements Specification Page 55 of 59
Functional
Requirement 6
Maintain Historical Records At the end of a year, data for
that year should be saved
into the database without
any loss of data. The data
can retrieved at anytime for
historical purposes
Functional
Requirement 7
No Client Install Any PC can be connected to
the network and access the
application
Functional
Requirement 8
Resemble Existing System User can recognize that a
process in the application is
similar to their paper
process.
Functional
Requirement 9
Printouts/Reporting User can print out a
summary of each section.
Functional
Requirement 10
Security Admin panel cannot be
accessed by users without
the password.
Functional
Requirement 11
Administration Panel Administrator panel allows
admin to perform all
required import and
application configuration.
Functional
Requirement 12
Multiple Sites The application should be
able to be run in different
locations simultaneously
maintaining data integrity.
Functional
Requirement 13
Group/School Registration Schools can register an
entire day of sections in one
go.
Functional
Requirement 14
Move Competitor between Sections Administrator able to move
a competitor to a new
section
Functional
Requirement 15
Register by Section Registration can display the
next section, and select a
competitor to register.
Functional
Requirement 16
Welcome Screen User is shown a list of
sections for the day when
they logon.
Functional
Requirement 17
Display Sections that the Competitor
is in
User is able to search for a
competitor. The results
should show the sections
that competitor is entered in.
Functional
Requirement 18
Data Backup / Restore Administrator can backup
data to file, and restore it
again.
Functional Field Validation Mandatory fields prompt forSoftware Requirements Specification Page 56 of 59
Requirement 19 data when left empty.
Functional
Requirement 20
Roles Multiple Roles exist in the
database, so that users can
perform different functions.
Functional
Requirement 21
Discipline Under a discipline, there
should be one or more
sections.
Functional
Requirement 22
Section Ability of to show a Section
specific information like
section number, Section
description, the date and
time the section was created,
location of the section, age
limit that applies to that
section.
Functional
Requirement 23
Competitor Ability to show competitor
information such as
surname, given name,
location, sections competing
in, age and some notes
about the competitor.
Functional
Requirement 24
Competitor Number Ability of a competitor
number to be unique and
fixed.
Functional
Requirement 25
Competitor Sequence Number Ability to change as per
order of stage performance.
Functional
Requirement 26
Communication tool Ability of application to
allow logged in users to
send messages among
themselves. Does not have
to be implemented for the
project to be considered
successful.
Functional
Requirement 27
PDA Compatibility Ability to display relevant
information onto a wireless
capable PDA system. Does
not have to be implemented
for the project to be
considered successful.
Functional
Requirement 28
TV Display The system should be able
to convert data into TV
compatible form and thus
allow TV displays of
relevant information. Does
not have to be implementedSoftware Requirements Specification Page 57 of 59
for the project to be
considered successful.
Functional
Requirement 29
Debating Ability to distinguish
affirmative and negative
teams and the topic of
discussion. Topics and
teams should be displayed
ok.
5.2. Acceptance Criteria – Non-Functional Requirements
BUSINESS NONFUNCTIONAL
REQUIREMENT ID
REQUIREMENT ACCEPTANCE CRITERIA
AND ASSOCIATED METRICS
Non-Functional
Requirement 1
Website Theme Flexibility in color schemes.
Non-Functional
Requirement 2
Easy to Use Easy to navigate, ability to
use tab key to move
between sections
Non-Functional
Requirement 3
Maintainability Easy to follow
documentation, each section
of the application to have a
help content specifically for
that particular section.
Non-Functional
Requirement 4
User Manuals Ability to produce different
manuals: Administrator
manual, user manual.
Non-Functional
Requirement 5
Date Formats Australia date format of
dd/mm/yyyy
Non-Functional
Requirement 6
Language Written and read in
Australian English
Non-Functional
Requirement 7
Network The application should be
able to run effectively over a
wireless network with a
reasonable speed.Software Requirements Specification Page 58 of 59
Declaration:
I have read and understood the project requirements. I hereby agree to the terms of the
document.
NAME SIGNATURE DATE SIGNED
------/---------/------
------/---------/------
------/---------/------
------/---------/------
------/---------/------
------/---------/------Software Requirements Specification Page 59 of 59
References
John W. Satzinger, Robert B. Jackson, Stephen D. Burd (2004). System Analysis and
Design in a Changing World (3rd ed.), Thomson Cource Technology, Boston,
Massachusetts, USA.
Ludwig Consulting (2008). Templates and Guidance. Retrieved June 6, 2008, from
http://www.jiludwig.com/Template_Guidance.html
Oregon Government (2008). Requirements Specification Template. Retreived June 6,
2008, from
http://www.oregon.gov/DHS/admin/pmo/data/executing_templates/requirements_
template_lite.doc
Schwalbe, K. (2006). Information technology project management, (4th Ed.). Cambridge,
MA: Course Technology.
Stephen Cooper (2008). Software Requirements Specification. Retrieved June 6, 2008,
from
http://www.sju.edu/~scooper/spring01se/SoftwareRequirementsSpecification.htm
Unknown Author (2008). Unknown Title. Retrieved February 14, 2008 – Not accessible
June 6, 2008 from http://www.techwrl.com/techwhirl/magazine/writing/softwarerequirementspecs.html