Software requirement specification document formal template

1. Montreal Jazz Festival
Requirements Specification Document
Written by: Muhua Li

2. Table of Contents
1 Introduction ................................................................................................................. 3
1.1 Purpose of the system.......................................................................................... 3
1.2 Scope of the system............................................................................................. 3
1.3 Objectives and success criteria............................................................................ 3
1.4 Definitions, acronyms, and abbreviates .............................................................. 3
1.5 References ........................................................................................................... 3
1.6 Overview ............................................................................................................. 3
2 Current system............................................................................................................. 4
3 Proposed system.......................................................................................................... 4
3.1 System Overview ................................................................................................ 4
Functional Requirements................................................................................................. 4
3.1.1 The system shall allow tourists to access the full schedule of the Jazz
festival information ..................................................................................................... 4
3.1.2 The system shall allow tourists to select shows and customize personalized
schedule ..................................................................................................................... 4
3.1.3 The system shall maintain the show information........................................ 4
3.2 Non-Functional Requirements ............................................................................ 5
3.2.1 User interface and human factors................................................................ 5
3.2.2 Documentation ............................................................................................ 5
3.2.3 Hardware considerations ............................................................................. 5
3.2.4 Performance characteristics......................................................................... 5
3.2.5 Error handling and extreme conditions ....................................................... 5
3.2.6 Quality issues .............................................................................................. 5
3.2.7 System modifications .................................................................................. 5
3.2.8 Physical environment .................................................................................. 5
3.2.9 Security issues ............................................................................................. 5
3.2.10 Resource issues ........................................................................................... 6
3.3 Pseudo Requirements .......................................................................................... 6
3.4 System Models .................................................................................................... 6
3.4.1 Scenarios ..................................................................................................... 6
3.4.2 Use case model............................................................................................ 7
3.4.3 Object model ............................................................................................... 7
3.4.4 Dynamic model ........................................................................................... 8
3.4.5 User Interface (screen mock-up) ................................................................. 8
4 Glossary....................................................................................................................... 9
Table of Figures
Figure 3.1 Sequence Diagram for AccessFillSchedule Scenario........................................ 6
Figure 3.2 Sequence Diagram for CustomizePersonalSchedule Scenario.......................... 6
Figure 3.3 System Use Case Diagram................................................................................. 7
Figure 3.4 Class Diagram.................................................................................................... 7
Figure 3.5 Statechart Diagram of use cases ........................................................................ 8
Figure 3.6 Screen mock-up for Full Schedule..................................................................... 8
Figure 3.7 Screen mock-up for Personal Schedule ............................................................. 9
2

3. 1 Introduction
1.1 Purpose of the system
The purpose of the system is to facilitate accessing and handling of detailed information
of the Montreal Jazz Festival.
1.2 Scope of the system
This website is to display a table of Jazz shows including show time, location and band
name. Tourists can select whatever shows of interest, and upon request a customized list
of favorite shows is created as a personal guide to the festival.
1.3 Objectives and success criteria
The prioritized objectives for the system are as the following:
'Functionality specification. Refer to section 3.1.
'Thin server
'Maintainability
'Minimum latency
1.4 Definitions, acronyms, and abbreviates
'SRS: System Requirement Specification
'JVM: Java Virtual Machine
1.5 References
[1] Bernd Bruegge Allen H. Dutoit, “Object-Oriented Software Engineering:
Conquering Complex and Changing Systems”, Prentice Hall, 1999
[2] The Montreal Jazz Festival Website: http://www.montrealjazzfest.com/
1.6 Overview
This document is organized as follows:
'Introduction
'Current system: a description of the currently implemented functionality
'Proposed system: the specifications for the system to be developed
'Glossary: meaning of application terms in the proposed system
3

4. 2 Current system
The current system has a table view of the Jazz Festival schedule. The current system
does not allow the tourists to customize their personal schedule.
3 Proposed system
3.1 System Overview
The system has a client/server architecture. The overall system is described by navigating
the website. The interface is designed to serve tourists the full show schedule in table
form with band names, locations and show times. The table items are selectable to enable
tourists to make personalized schedules. The personalized schedules will be displayed on
a new table for a better visualization.
Functional Requirements
3.1.1 The system shall allow tourists to access the full schedule of
the Jazz festival information
Use case name AccessFullSchedule
Participating actor Initiated by the Tourist
Entry condition 1. The Tourist opens web browser and types the address of the Jazz
Festival website
Flow of events 2. The System presents a welcome page
3. The Tourist requests to view the full schedule
4. The System retrieves show information from DB
Exit condition 5. The System presents a full show schedule
3.1.2 The system shall allow tourists to select shows and customize
personalized schedule
Use case name CustomizePersonalSchedule
Participating actor Initiated by the Tourist
Entry condition 1. A full show schedule is displayed
Flow of events 2. The Tourist selects a favorite show
3. The Tourist repeats steps 2~3
4. The Tourist requests to view the personal schedule
Exit condition 5. The System presents the personalized schedule
3.1.3 The system shall maintain the show information
Use case name MaintainDBdata
4

5. Participating actor Initiated by the DB Maintainer
Description The Maintainer will use the standard DB interfaces to maintain the
Jazz Festival schedule information in the DB
3.2 Non-Functional Requirements
3.2.1 User interface and human factors
'Thy system shall be accessible through a web-based interface
'The tourists are assumed to have basic knowledge following instructions and links
3.2.2 Documentation
All standard documents as specified in reference [1] are required.
3.2.3 Hardware considerations
The user will use a PC with Internet access to use the system.
3.2.4 Performance characteristics
Refer to section 1.3.
3.2.5 Error handling and extreme conditions
' the server crashes, the personal user information may be lost
If
'The system shall store all information regarding the shows on persistent storage
3.2.6 Quality issues
Refer to section 1.3.
3.2.7 System modifications
N/A
3.2.8 Physical environment
The system shall be deployed on a PC in MC536.
3.2.9 Security issues
The tourists are not able to modify the show information.
5

6. 3.2.10 Resource issues
'IBM VisualAge for Java with servlet package
'JVM
3.3 Pseudo Requirements
'The system should be implemented using only standard Java language, and the
Servlet package
'The system should use a client/server architecture
'Thin server
3.4 System Models
3.4.1 Scenarios
:WelcomePage :WebServer :DBConn :Show :Schedule
Jane:Tourist
Access
website
Request full
LoadSchedule
schedule CreateShow
DisplayFull
Figure 3.1 Sequence Diagram for AccessFillSchedule Scenario
:Schedule :Show
Jane:Tourist
Select
Show CheckShow
Select CheckShow
Show
Request Personal
GetCheckedShow
Schedule
DisplayPersonal
Figure 3.2 Sequence Diagram for CustomizePersonalSchedule Scenario
6

7. 3.4.2 Use case model
Access Full
Schedule
extend
DB
Customize
Personal Schedule
Tourist
Maintain DB Data
Maintainer
Figure 3.3 System Use Case Diagram
3.4.3 Object model
3.4.3.1 Data dictionary
WelcomePage: an html web page, showing the welcome information
WebServer: a servlet class, the Jazz festival web server responding to the tourists’
quest
DB: data access interface for Jazz festival information stored
3.4.3.2 Class diagram
*
W e lc o m e P a g e W eb S erv e r
1
S c h e d u le D B C onn
D is p la y F u ll () L o a d S c h e d u le ()
D is p la y P e rs o n a l ()
1
1
* *
Show
C re a te S h o w ()
C h e c k S h o w ()
G e tC h e c k e d S h o w ( )
Figure 3.4 Class Diagram
7

8. 3.4.4 Dynamic model
Full Schedule
DisplayFull
Welcome
Entry: Display full schedule
CheckShow
DisplayPersonal
Full Schedule with selected shows Personal Schedule
Entry: Select shows DisplayFull Entry: Display personal schedule
Figure 3.5 Statechart Diagram of use cases
3.4.5 User Interface (screen mock-up)
Figure 3.6 Screen mock-up for Full Schedule
8

9. Figure 3.7 Screen mock-up for Personal Schedule
4 Glossary
Band: A person or group that perform a show
Time: Time that a specific show begins
Location: Playing area where a show is performed
Show: Combination information of a show including band name, show
location and time for performance
Schedule: A list of shows with time, location and band name
Tourist: Person who access the website for information of Jazz festival.
9