This document introduces software requirement specification (SRS) and provides an example SRS for a Jazz Festival website. The key points are: 1. SRS is used to document system requirements through functional and non-functional requirements, use cases, scenarios, and other models. 2. The example SRS is for a website that displays jazz festival show schedules and allows tourists to customize their own schedules. 3. The SRS documents functional requirements, non-functional requirements, actors, scenarios, use cases, and class/dynamic models for the example jazz festival website system.

1. 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

2. 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

3. 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.

4. 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

5. 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?

6. 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?

7. 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

8. 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? …

9. 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

10. AccessFullSchedule Scenario in sequence diagram

11. CustomizePersonalSchedule Scenario in Sequence Diagram

12. Identifying use cases A use case specifies all possible scenarios for a given piece of functionality.

13. 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

14. Use case – cont. 2 Use case name CustomizePersonalSchedule Participating actor Initiated by the T ourist 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

15. 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)

16. Class Diagram

17. Dynamic Model (state chart for the use cases)

18. Role of Diagrams Diagram information + text information covers what you w ant 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?