S REQUIREMENTS SPECIFICATION - comp.utm.my · Software Requirements Specification ... The billing system is notified for each student in each course offering that is not cancelled,

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

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 what results at what location for whom.

FINAL: DRAFT 10 FEBRUARY 2008

Software Requirements Specification (SRS)

SRS – Course Registration System Page 1

REVISION CHART

This chart contains a history of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created.

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

Version Primary Author(s) Description of Version Date Completed

Draft TBD Initial draft created for distribution and review comments

TBD

Preliminary TBD Second draft incorporating initial review comments, distributed for final review

TBD

Final TBD First complete draft, which is placed under change control

TBD



PREFACE

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



CONTENTS

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

1. INTRODUCTION................................................................................................................6

1.1 PURPOSE..................................................................................................................6 1.2 SCOPE......................................................................................................................6

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ....................................................6 1.4 REFERENCES............................................................................................................6 1.5 OVERVIEW...............................................................................................................7

2. OVERALL DESCRIPTION..................................................................................................8 2.1 PRODUCT PERSPECTIVE ...........................................................................................8

2.2 PRODUCT FUNCTIONS ..............................................................................................8 2.2.1 Register for Courses ................................................................................................ 8 2.2.1 Login ........................................................................................................................ 8 2.2.2 Maintain Professor Information .............................................................................. 8 2.2.3 Maintain Student Information ................................................................................. 8 2.2.4 Close Registration ................................................................................................... 8 2.2.5 Select Courses to Teach........................................................................................... 8 2.2.6 Submit Grades ......................................................................................................... 8 2.2.7 View Report Card .................................................................................................... 9

2.3 USER CHARACTERISTICS .........................................................................................9

3. SPECIFIC REQUIREMENTS.............................................................................................10 3.1 SOFTWARE PRODUCT FEATURES ...........................................................................10

3.1.1 Register for Courses Use Case XXXXX................................................................. 10 3.1.1.1 Brief Description.................................................................................................... 10 3.1.1.2 Flow of Events ....................................................................................................... 10

3.1.1.2.1 Basic Flow – Create a Schedule ..........................................................................10 3.1.1.2.2 Alternative Flows ................................................................................................10

3.1.1.2.2.1 Modify a Schedule............................................................................10 3.1.1.2.2.2 Delete a Schedule .............................................................................10 3.1.1.2.2.3 Save a Schedule ................................................................................11 3.1.1.2.2.4 Add Course Offering ........................................................................11 3.1.1.2.2.5 Unfulfilled Prerequisites or Course Full...........................................11 3.1.1.2.2.6 No Schedule Found...........................................................................11 3.1.1.2.2.7 Course Catalog System Unavailable ................................................11 3.1.1.2.2.8 Course Registration Closed ..............................................................11

3.1.1.3 Special Requirements ............................................................................................ 11 3.1.1.4 Preconditions ......................................................................................................... 11 3.1.1.5 Postconditions ........................................................................................................ 11



3.1.1.6 Extension Points .................................................................................................... 11 3.1.1.7 Register for Courses Sequence Diagram ............................................................... 12 3.1.1.8 Register for Courses Activity Diagram ................................................................. 12

3.1.2 Login Use Case...................................................................................................... 12 3.1.1.9 Brief Description.................................................................................................... 12 3.1.1.10 Flow of Events ..................................................................................................... 12 3.1.1.11 Basic Flow - Login .............................................................................................. 12 3.1.1.12 Alternative Flows................................................................................................. 13 3.1.1.13 Special Requirements .......................................................................................... 13 3.1.1.14 Preconditions ....................................................................................................... 13 3.1.1.15 Postconditions ...................................................................................................... 13 3.1.1.16 Extension Points .................................................................................................. 13 3.1.1.17 Login Sequence Diagram..................................................................................... 13 3.1.1.18 Activity Diagram ................................................................................................. 13

: ....................................................................................................................................... 13 3.1.3 Use Case Specification 3 ....................................................................................... 14 3.1.4 Use Case Specification 4 ....................................................................................... 14 3.1.5 Use Case Specification 5 ....................................................................................... 14 3.1.n Paste use case specification n ............................................................................... 14

3.2 NON FUNCTIONAL REQUIREMENTS .......................................................................14 3.2.1 Usability................................................................................................................. 14

3.2.1.1 Windows Compliance............................................................................................ 14 3.2.1.2 Designs for Ease-of-Use ........................................................................................ 14 3.2.1.3 Online Help............................................................................................................ 14

3.2.2 Reliability............................................................................................................... 14 3.2.2.1 Availability ............................................................................................................ 14 3.2.2.2 Mean Time between Failures................................................................................. 14

3.2.3 Performance .......................................................................................................... 15 3.2.3.1 Simultaneous Users................................................................................................ 15 3.2.3.2 Database Access Response Time........................................................................... 15 3.2.3.3 Transaction Response Time................................................................................... 15

4. INDEX.............................................................................................................................16

5. APPENDICES ..................................................................................................................17



LIST OF FIGURES

New figures that are given captions using the Caption paragraph style will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the 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.

Error! No table of figures entries found.



1. INTRODUCTION

This section should provide an overview of the entire document. No text is necessary between the heading 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 will not do. Describe how the software will be used, and identify relevant benefits, objectives, and goals.

1.3 Definitions, Acronyms, and Abbreviations Define 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 the bibliography in a published book.



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



2. OVERALL DESCRIPTION

2.1 Product Perspective This section should place the product in perspective with other related products. If the product is independent and self-contained, state that here. Otherwise, identify interfaces between the product 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. The billing system is notified for each student in each course offering that is not cancelled, so the student can be 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. This includes 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. This includes 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 also modify or delete course selections if changes are made within the add/drop period at the beginning of 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 courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in 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 the previous semester.



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 Characteristics Describe the general characteristics of the intended users, including

• educational level

• experience

• technical expertise



3. SPECIFIC REQUIREMENTS

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

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 Student can 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 an actor 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 Main Form.

3.1.1.2.1 BASIC FLOW – CREATE A 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 Student’s 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 course offerings 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." 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". The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings 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 necessary prerequisites or that the selected course offering is full, an error message is displayed. The Student can either 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 the Student’s schedule, an error message is displayed. The Student acknowledges the error and the use case is restarted.

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 and the 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, a message is displayed to the Student and the use case terminates. Students cannot register for courses after registration 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 Points There is no extension points associated with this use case.



3.1.1.7 Register for Courses Sequence Diagram

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

3.1.1.11 Basic Flow - Login

1. The system validates the actor’s 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 / Password If in the basic flow the system cannot find the name or the password is invalid, an error message is displayed. 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

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 that should 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 appropriate for 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 shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronyms.

3.2.2 Reliability This section lists all reliability requirements.

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 than 4% down time.

3.2.2.2 Mean Time between Failures Mean 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 time and 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 second latency.

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



4. INDEX

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



5. APPENDICES

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

Documents

S REQUIREMENTS SPECIFICATION - comp.utm.my · Software Requirements Specification ... The billing system is notified for each student in each course offering that is not cancelled,