srs_templatewithcrsexample

8/3/2019 SRS_TemplateWithCRSExample

1/18

SOFTWARE REQUIREMENTS SPECIFICATION

This document outline is based on the IEEE Standard 830-1993 for Software Requirements

Specifications.

This document was created in part by Steve Mattingly ([email protected]).

This document should specify what functions are to be performed on what data to produce whatresults at what location for whom.

FINAL: DRAFT

10 FEBRUARY 2008

This document is adapted from Software Project Survival Guide by Steve McConnell(Microsoft Press, 1998). The document template used to create this document, relateddocuments, plans, and other materials can be downloaded from the survival guidewebsite at http://www.construx.com/survivalguide/.


2/18

Software Requirements Specification (SRS)

REVISION CHART

This chart contains a history of this documents revisions. The entries below are provided solelyfor purposes of illustration. Entries should be deleted until the revision they refer to has actuallybeen created.

The document itself should be stored in revision control, and a brief description of each versionshould be entered in the revision control system. That brief description can be repeated in thissection. Revisions do not need to be described elsewhere in the document except inasmuch asthey explain the development plan itself.

Version Primary Author(s) Description of Version DateCompleted

Draft TBD Initial draft created for distribution andreview comments

TBD

Preliminary TBD Second draft incorporating initial review

comments, distributed for final review

TBD

Final TBD First complete draft, which is placedunder change control

TBD

SRS Course Registration System Page 2


3/18


PREFACE

The preface contains an introduction to the document. It is optional and can be deleted ifdesired.



4/18


CONTENTS

New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the tableautomatically. To update this table of contents in Microsoft Word, put the cursor anywhere inthe table and press F9. If you want the table to be easy to maintain, do not change it manually.

1. INTRODUCTION................................................................................................................7

1.1 PURPOSE................................................................................................................7

1.2 SCOPE....................................................................................................................7

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS............................................................7

1.4 REFERENCES...........................................................................................................7

1.5 OVERVIEW..............................................................................................................8

2. OVERALL DESCRIPTION....................................................................................................9

2.1 PRODUCT PERSPECTIVE.............................................................................................9

2.2 PRODUCT FUNCTIONS...............................................................................................92.2.1 Register for Courses ...................................................................................... ......9

2.2.1 Login......................................................................................................................92.2.2 Maintain Professor Information.............................................................................92.2.3 Maintain Student Information................................................................................92.2.4 Close Registration..................................................................................................92.2.5 Select Courses to Teach..................................................................................... ....92.2.6 Submit Grades........................................................................................................92.2.7 View Report Card........................................................................................... .....10

2.3 USERCHARACTERISTICS..........................................................................................10

3. SPECIFIC REQUIREMENTS...............................................................................................11

3.1 SOFTWARE PRODUCT FEATURES...............................................................................113.1.1 Register for Courses Use Case....................................................................... ....11

3.1.1.1 Brief Description...................................................................................................113.1.1.2 Flow of Events.......................................................................................................11

3.1.1.2.1 Basic Flow Create a Schedule.......................................................................113.1.1.2.2 Alternative Flows.............................................................................................11

3.1.1.2.2.1 Modify a Schedule.........................................................................113.1.1.2.2.2 Delete a Schedule...........................................................................113.1.1.2.2.3 Save a Schedule.............................................................................12

3.1.1.2.2.4 Add Course Offering......................................................................123.1.1.2.2.5 Unfulfilled Prerequisites or Course Full........................................123.1.1.2.2.6 No Schedule Found........................................................................123.1.1.2.2.7 Course Catalog System Unavailable..............................................123.1.1.2.2.8 Course Registration Closed............................................................12

3.1.1.3 Special Requirements............................................................................................123.1.1.4 Preconditions.........................................................................................................123.1.1.5 Postconditions........................................................................................................123.1.1.6 Extension Points....................................................................................................12



5/18


3.1.1.7 Register for Courses Sequence Diagram..............................................................133.1.1.8 Register for Courses Activity Diagram.................................................................13

3.1.2 Login Use Case...................................................................................................133.1.1.9 Brief Description...................................................................................................133.1.1.10 Flow of Events.....................................................................................................13

3.1.1.11 Basic Flow - Login..............................................................................................143.1.1.12 Alternative Flows................................................................................................143.1.1.13 Special Requirements..........................................................................................143.1.1.14 Preconditions.......................................................................................................143.1.1.15 Postconditions......................................................................................................143.1.1.16 Extension Points..................................................................................................143.1.1.17 Login Sequence Diagram....................................................................................143.1.1.18 Activity Diagram.................................................................................................15

:....................................................................................................................................153.1.3 Use Case Specification 3.....................................................................................153.1.4 Use Case Specification 4.....................................................................................153.1.5 Use Case Specification 5.....................................................................................153.1.n Paste use case specification n.............................................................................15

3.2 NON FUNCTIONAL REQUIREMENTS............................................................................153.2.1 Usability...............................................................................................................15

3.2.1.1 Windows Compliance...........................................................................................153.2.1.2 Designs for Ease-of-Use........................................................................................153.2.1.3 Online Help............................................................................................................15

3.2.2 Reliability.............................................................................................................153.2.2.1 Availability............................................................................................................163.2.2.2 Mean Time between Failures................................................................................16

3.2.3 Performance.........................................................................................................163.2.3.1 Simultaneous Users...............................................................................................163.2.3.2 Database Access Response Time..........................................................................163.2.3.3 Transaction Response Time..................................................................................16

4. INDEX..........................................................................................................................17

5. APPENDICES..................................................................................................................18



6/18


LISTOF FIGURES

New figures that are given captions using the Caption paragraph style will be added to the tableautomatically. To update this table of contents in Microsoft Word, put the cursor anywhere inthe table and press F9. If you want the table to be easy to maintain, do not change it manually.

This section can be deleted if the document contains no figures or if otherwise desired.



7/18


1. INTRODUCTION

This section should provide an overview of the entire document. No text is necessary between theheading above and the heading below unless otherwise desired.

1.1 Purpose

Describe the purpose of this specification and its intended audience.

1.2 Scope

Identify the software product(s) to be produced by name. Explain what the products will and willnot do. Describe how the software will be used, and identify relevant benefits, objectives, andgoals.

1.3 Definitions, Acronyms, and AbbreviationsDefine all terms, acronyms, and abbreviations used in this document.

1.4 References

List all the documents and other materials referenced in this document. This section is like thebibliography in a published book.



8/18


1.5 Overview

Describe in general of your project and paste your use case model/diagram in this section



9/18


2. OVERALL DESCRIPTION

2.1 Product PerspectiveThis section should place the product in perspective with other related products. If the product isindependent and self-contained, state that here. Otherwise, identify interfaces between theproduct and related systems.

2.2 Product Functions

This section should contain the summary of all the use cases in the use case model/diagram

2.2.1 Register for Courses

This use case allows a Registrar to close the registration process. Course offerings that do not have

enough students are cancelled. Course offerings must have a minimum of three students in them. Thebilling system is notified for each student in each course offering that is not cancelled, so the student canbe billed for the course offering.

2.2.1 Login

This use case describes how a user logs into the Course Registration System

2.2.2 Maintain Professor Information

This use case allows the registrar to maintain professor information in the registration system. Thisincludes adding, modifying, and deleting professors from the system.

2.2.3 Maintain Student Information

This use case allows the registrar to maintain student information in the registration system. Thisincludes adding, modifying, and deleting students from the system.

2.2.4 Close Registration

This use case allows a student to register for courses in the current semester. The student can alsomodify or delete course selections if changes are made within the add/drop period at the beginningof the semester. The Billing System is notified of all registration updates. The Course Catalog

provides a list of all the course offerings for the current semester.

2.2.5 Select Courses to Teach

This use case allows a professor to select the course offerings (date- and time- specific courseswill be given) from the course catalog for the courses that he/she is eligible for and wishes to teachin the upcoming semester

2.2.6 Submit Grades

This use case allows a professor to submit student grades for one or more classes completed in theprevious semester.



10/18


2.2.7 View Report Card

This use case allows a student to view his/her report card for the previously completed semester.

2.3 User CharacteristicsDescribe the general characteristics of the intended users, including

educational level

experience

technical expertise



11/18


3. SPECIFIC REQUIREMENTS

This section should describe all software requirements at a sufficient level of detail for designersto design a system satisfying the requirements and testers to verity that the system satisfiesrequirements.

3.1 Software Product Features

3.1.1 Register for Courses Use Case

3.1.1.1 Brief Description

This use case allows a Student to register for course offerings in the current semester. The Studentcan also modify or delete course selections if changes are made within the add/drop period at the

beginning of the semester. The Course Catalog System provides a list of all the course offerings

for the current semester. The main actor of this use case is the Student. The Course Catalog System is anactor within the use case.

3.1.1.2 Flow of Events

The use case begins when the Student selects the "maintain schedule" activity from the MainForm.

3.1.1.2.1 BASIC FLOW CREATEA SCHEDULE

1. The Student selects "create schedule."2. The system displays a blank schedule form.3. The system retrieves a list of available course offerings from the Course Catalog System.4. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of

available offerings. Once the selections are complete the Student selects "submit."

5. The "Add Course Offering" sub-flow is performed at this step for each selected course offering.6. The system saves the schedule.

3.1.1.2.2 ALTERNATIVE FLOWS

3.1.1.2.2.1 Modify a Schedule

1. The Student selects "modify schedule."2. The system retrieves and displays the Students current schedule (e.g., the schedule for the current

semester).3. The system retrieves a list of all the course offerings available for the current semester from the Course

Catalog System. The system displays the list to the Student.4. The Student can then modify the course selections by deleting and adding new courses. The Student

selects the courses to add from the list of available courses. The Student also selects any courseofferings to delete from the existing schedule. Once the edits are complete the Student selects"submit".

5. The "Add Course Offering" sub-flow is performed at this step for each selected course offering.6. The system saves the schedule.

3.1.1.2.2.2 Delete a Schedule

1. The Student selects the "delete schedule" activity.2. The system retrieves and displays the Student current schedule.3. The Student selects "delete."



12/18


4. The system prompts the Student to verify the deletion.5. The Student verifies the deletion.6. The system deletes the schedule.

3.1.1.2.2.3 Save a Schedule

At any point, the Student may choose to save a schedule without submitting it by selecting "save". Thecurrent schedule is saved, but the student is not added to any of the selected course offerings. The courseofferings are marked as "selected" in the schedule.

3.1.1.2.2.4 Add Course Offering

The system verifies that the Student has the necessary prerequisites and that the course offering is open.The system then adds the Student to the selected course offering. The course offering is marked as"enrolled in" in the schedule.

3.1.1.2.2.5 Unfulfilled Prerequisites or Course Full

If in the "Add Course" sub-flow the system determines that the Student has not satisfied the necessaryprerequisites or that the selected course offering is full, an error message is displayed. The Student caneither select a different course offering or cancel the operation, at which point the use case is restarted.

3.1.1.2.2.6 No Schedule Found

If in the "Modify a Schedule" or "Delete a Schedule" sub-flows the system is unable to retrieve theStudents schedule, an error message is displayed. The Student acknowledges the error and the use case isrestarted.

3.1.1.2.2.7 Course Catalog System Unavailable

If, the system is unable to communicate with the Course Catalog System after a specified number of tries,the system will display an error message to the Student. The Student acknowledges the error message andthe use case terminates.

3.1.1.2.2.8 Course Registration Closed

If, when the student selects "maintain schedule", registration for the current semester has been closed, amessage is displayed to the Student and the use case terminates. Students cannot register for courses afterregistration for the current semester has been closed.

3.1.1.3 Special Requirements

There are no special requirements associated with this use case.

3.1.1.4 Preconditions

Before this use case begins the Student has logged onto the system.

3.1.1.5 Postconditions

Student information is registered in the database.

3.1.1.6 Extension PointsThere is no extension points associated with this use case.



13/18


3.1.1.7 Register for Courses Sequence Diagram

: Student: Student : RegistrationForCoursesForm: RegistrationForCoursesForm : RegistrationController: RegistrationController: Course Catalog

System

: Course Catalog

System

: Schedule: Schedule : Student: Student

1: createSchedule()

2: getCourseOffering

3: getCourseOffering(Semester)

4: displayCourseOfferings()

5: displayBlankSchedule()

6: select 4 promary and 2 alternate()

7: createSchedulewithOfferings(CourseOfferingList)

8: new(forSemester:Semester,withPrimaryOfferings:CourseOfferingList,withAlternateOfferings:CourseOfferingList)

9: addSchedule(theSchedule,Schedule)

3.1.1.8 Register for Courses Activity Diagram

:

:

3.1.2 Login Use Case

3.1.1.9 Brief Description

This use case describes how a user logs into the Course Registration System. The actors starting this usecase are Student, Professor, and Registrar.

3.1.1.10 Flow of Events

The use case begins when the actor types his/her name and password on the login form.



14/18


3.1.1.11 Basic Flow - Login

1. The system validates the actors password and logs him/her into the system.2. The system displays the Main Form and the use case ends.

3.1.1.12 Alternative Flows

2.2.1 Invalid Name / PasswordIf in the basic flow the system cannot find the name or the password is invalid, an error message isdisplayed. The actor can type in a new name or password or choose to cancel the operation, at which

point the use case ends.

3.1.1.13 Special Requirements

There are no special requirements associated with this use case.

3.1.1.14 Preconditions

There are no preconditions associated with this use case.

3.1.1.15 Postconditions

The user is logged in the system.

3.1.1.16 Extension Points

There is no extension points associated with this use case.

3.1.1.17 Login Sequence Diagram

: Any Users: Any Users : LoginForm: LoginForm : LoginCtl: LoginCtl : User: User : MainAppForm: MainAppForm1: //get user info( )

2: getUserInfo(Integer, String)

3: isValid()

4: open

Sequence Diagram:

Login / E-1:Invalid User

Info



15/18


3.1.1.18 Activity Diagram

:

:

3.1.3 Use Case Specification 3

:


:


:

:

:

3.1.n Paste use case specification n

3.2 Non Functional Requirements

The following items provide a partial list of system attributes that can serve as requirements thatshould be objectively verified.

3.2.1 Usability

This section lists all of those requirements that relate to, or affect, the usability of the system.

3.2.1.1 Windows Compliance

The desktop user-interface shall be Windows 95/98 compliant.

3.2.1.2 Designs for Ease-of-Use

The user interface of the C-Registration System shall be designed for ease-of-use and shall be appropriatefor a computer-literate user community with no additional training on the System.

3.2.1.3 Online Help

Each feature of the C-Registration System shall have built-in online help for the user. Online Help shallinclude step by step instructions on using the System. Online Help shall include definitions for terms andacronyms.

3.2.2 Reliability

This section lists all reliability requirements.



16/18


3.2.2.1 Availability

The C-Registration System shall be available 24 hours a day, 7 days a week. There shall be no more than4% down time.

3.2.2.2 Mean Time between FailuresMean Time between Failures shall exceed 300 hours.

3.2.3 Performance

The performance characteristics of the system are outlined in this section.

3.2.3.1 Simultaneous Users

The system shall support up to 2000 simultaneous users against the central database at any given timeand up to 500 simultaneous users against the local servers at any one time.

3.2.3.2 Database Access Response Time

The system shall provide access to the legacy course catalog database with no more than 10 secondlatency.

3.2.3.3 Transaction Response Time

The system must be able to complete 80% of all transactions within 2 minutes.



17/18


4. INDEX

The index is optional according to the IEEE standard. If the document is made available inelectronic form, readers can search for terms electronically.



18/18


5. APPENDICES

Include supporting detail that would be too distracting to include in the main body of thedocument.


srs_templatewithcrsexample

Documents