Introduction to SRS

• What’s SRS?
– Software Requirement Specification
• What’s it for?
– Requirement elicitation (functional & nonfunctional)
– Analysis
• Who are its users?
– The client, the users, the system analysts, the system
designers…
• Where is the template?
– B&D Textbook page 126
 What are to be written in SRS
• Introduction
– Purpose, scope, objectives, reference, …
• Current System
– Describe the current state of affairs
• Proposed System
– Overview
– Functional requirements
– Nonfunctional requirements
– Pseudo requirements
– System models (Scenarios, use cases, object model, dynamic models,
user interface)
• Glossary
 Example: Jazz Festival Website
• 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.
 Functional requirements
• The system shall allow the tourists to access
the full schedule of Jazz festival shows
• The system shall allow the tourists to select
their favorite shows and customize
personalized schedules
• The system shall maintain the schedule data
 Identifying nonfunctional
requirements
• User interface and human factors
– What kind of interface? A web-based interface
– What’s the level of expertise of the users? The tourists are
assumed to have basic web access knowledge
• Documentation
– What level and kind of document? As required in the textbook:
SRS, DD, TD
• Hardware considerations
– Hardware requirement? PC with Internet access
• Performance characteristics
– How responsive? Work load?
 Nonfunctional requirements
-- cont.
• Error handling and extreme conditions
– How to handle exceptions? Which exceptions?
• Quality issues
– Reliability/availability/robustness?
• System modifications
– Any future changes?
• Physical environment
– Where will the system be deployed?
• Security issues
– What kind of security? To what level?
• Resource issues
– Any constraints on the resources consumed?
 Identifying actors
• Actors represent external entities that interact with the
system
• Who are supported by the system to perform their work?
• Who execute the system’s main functions?
– The tourists
• Who perform secondary functions (maintenance &
administration)?
– The maintainer
• Will the system interact with external systems
– Database/File
 Identifying scenarios
• A scenario is a concrete, focused, informal
description of a single feature of the system
from the viewpoint of a single actor
• What are the tasks to perform?
• What information accessed? Who creates
that data?
• …
 Scenario – cont.
Scenario name AccessFullSchedule
Participating actor Jane: Tourist
Flow of events 1. Jane opens IE and enters the address of the
Jazz Festival website
2. The System presents a welcome page
3. Jane requests to view the full schedule
4. The System retrieves a full list of show from
DB
5. The System presents a full show schedule
 AccessFullSchedule Scenario
in sequence diagram
:WelcomePage :WebServer :DBConn :Show :Schedule
Jane:Tourist
Access
website
Request full
LoadSchedule
schedule CreateShow

DisplayFull
 CustomizePersonalSchedule
Scenario in Sequence Diagram
:Schedule :Show
Jane:Tourist
Select
Show CheckShow
Select CheckShow
Show
Request Personal
GetCheckedShow
Schedule

DisplayPersonal
 Identifying use cases
• A use case specifies all possible scenarios
for a given piece of functionality.
Access Full
Schedule

<<extend>>
DB
Customize
Personal Schedule
Tourist

Maintain DB Data
Maintainer
 Use case –cont.
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 information of show
from DB
Exit condition 5. The System presents a full show schedule
 Use case – cont. 2
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
 From Use Cases to Objects
• Identifying entity objects
– Terms that developers or users need to clarify to
understand the use case
– Recurring nouns in the use cases
• Identifying boundary objects
– The system interface with the actors (WelcomePage,
Schedule)
• Identifying control objects
– Coordinates boundary and entity objects (WebServer)
 Class Diagram
*
Welcome Page WebServer
1
1

* 1
Schedule DBConn

DisplayFull () LoadSchedule()
DisplayPersonal ()
1
1

* *
Show

CreateShow()
CheckShow()
GetCheckedShow()
 Dynamic Model
(state chart for the use cases)

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

 Role of Diagrams
• Diagram information + text information
covers what you want to represent in a
document.
• How much detail should a diagram reach?
– The detail and context the reader want.
– E.g. What should a class diagram provide in
SRS?