Posted on

Course Registration

Rational Software Course Registration System Supplementary Specification Version 2003 Mastering OOAD with UML Course Registration System Supplementary Specification 03CourseRegSupplSpec. doc Issue: 2003 Issue Date: 2/4/03 Revision History Date 9/5/2000 10/2/2000 01/14/2003 Issue V2000 V2000 V2003 Description Generation for beta Final release Final Release Author Shawn Siemers Shawn Siemers Alex Kutsick Confidential ?Rational Software, 2003 Page 2 Mastering OOAD with UML Course Registration System Supplementary Specification 03CourseRegSupplSpec. doc Issue: 2003 Issue Date: 2/4/03 Table of Contents 1. 2. 3. 4. 5. . 7. 8. 9. Objectives Scope References Functionality Usability Reliability Performance Supportability Security 4 4 4 4 4 4 4 4 4 5 10. Design Constraints Confidential ?Rational Software, 2003 Page 3 Mastering OOAD with UML Course Registration System Supplementary Specification 03CourseRegSupplSpec. doc Issue: 2003 Issue Date: 2/4/03 Course Registration System Supplementary Specification 1. Objectives The purpose of this document is to define requirements of the Course Registration System. This Supplementary Specification lists the requirements that are not readily captured in the use cases of the usecase model.

The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system. 2. Scope This Supplementary Specification applies to the Course Registration System, which will be developed by the OOAD students. This specification defines the non-functional requirements of the system; such as reliability, usability, performance, and supportability, as well as functional requirements that are common across a number of use cases. (The functional requirements are defined in the Use Case Specifications. ). 3. 4. References None. Functionality Multiple users must be able to perform their work concurrently.

If a course offering becomes full while a student is building a schedule including that offering, the student must be notified. 5. 6. 7. Usability The desktop user-interface shall be Windows 95/98 compliant. Reliability The system shall be available 24 hours a day 7 days a week, with no more than 10% down time. Performance 1. 2. 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. The system shall provide access to the legacy course catalog database with no more than a 10 second latency.

Note: Risk-based prototypes have found that the legacy course catalog database cannot meet our performance needs without some creative use of mid-tier processing power The system must be able to complete 80% of all transactions within 2 minutes. 3. 8. 9. Supportability None. Security 1. The system must prevent students from changing any schedules other than their own, and professors from modifying assigned course offerings for other professors. ?Rational Software, 2003 Confidential Page 4 Mastering OOAD with UML Course Registration System Supplementary Specification 03CourseRegSupplSpec. oc 2. 3. Only Professors can enter grades for students. Only the Registrar is allowed to change any student information. Issue: 2003 Issue Date: 2/4/03 10. Design Constraints The system shall integrate with an existing legacy system, the Course Catalog System, which is an RDBMS database. The system shall provide a Windows-based desktop interface. Confidential ?Rational Software, 2003 Page 5 Mastering OOAD with UML Course Registration System Supplementary Specification 03CourseRegSupplSpec. doc Issue: 2003 Issue Date: 2/4/03 Confidential ?Rational Software, 2003 Page 6

Leave a Reply

Your email address will not be published.