Download Case Study 1 - Requirements Specification Documents | CS 451 and more Papers Software Engineering in PDF only on Docsity!
Case Study 1—Requirements Specification Document
1 Abstract
This is the requirements document for the case study that will be used throughout the book. The system to be developed is for scheduling the courses in a computer science department, based on the input about classrooms, lecture times, and time preferences of the different instructors. Different conditions have to be satisfied by the final schedule. This document follows the IEEE standard for a requirements specification document, with some variations.
2 Introduction
2.1 Purpose
The purpose of this document is to describe the external requirements for a course scheduling system for an academic department in a University. It also describes the interfaces for the system.
2.2 Scope
This document is the only one that describes the requirements of the system. It is meant for use by the developers and will be the basis for validating the final delivered system. Any changes made to the requirements in the future will have to go through a formal change approval process. The developer is responsible for asking for clarifications, where necessary, and will not make any alterations without the permission of the client.
2.3 Definitions, Acronyms, Abbreviations
Not applicable.
2.4 References
Not applicable.
2.5 Developer’s Responsibilities
The developer is responsible for (a) developing the system, (b) installing the software on the client’s hardware, (c) conducting any user training that might be needed for using the system, and (d) maintaining the system for a period of one year after installation.
3 General Description
3.1 Product Functions Overview
In the computer science department there are a set of classrooms. Every semester the department offers courses, which are chosen from the set of department courses. A course has expected enrollment and could be for graduate students or undergraduate students. For each course, the instructor gives some time preferences for lectures. The system is to produce a schedule for the department that specifies the time and room assignments for the different courses. Preference should be given to graduate courses, and no two graduate courses should be scheduled at the same time. If some courses cannot be scheduled, the system should produce a “conflict report” that lists the courses that cannot be scheduled and the reasons for the inability to schedule them.
3.2 User Characteristics
The main users of this system will be department secretaries, who are somewhat literate with computers and can use programs such as editors and text processors.
3.3 General Constraints
The system should run on Sun 3/50 workstations running UNIX 4.2 BSD.
3.4 General Assumptions and Dependencies
Not applicable.
4 Specific Requirements
4.1 Inputs and Outputs
The system has two file inputs and produces three types of outputs.
Input file 1: Contains the list of room numbers and their capacity; a list of all the courses in the department catalog; and the list of valid lecture times. The format of the file is:
rooms room1 : cap room2 : cap : ; courses course1 , course2 , course3 , .... ; times time1 , time2 , time3 ;
Output 3: Error messages. At the minimum, the following error messages are to be given:
e1. Input file does not exist. e2. Input-file-1 has error e2.1. The course number has wrong format e2.2. Some lecture time has wrong format. e2.3. Classroom number has wrong format. e2.4. Classroom capacity out of range. e3. Input-file-2 has error e3.1. No course of this number. e3.2. No such lecture time. e4. More than permissible courses in the file; later ones ignored. e5. There are more than permissible preferences. Later ones are ignored.
4.2 Functional Requirements
- Determine the time and room number for the courses such that the following con- straints are satisfied:
(a) No more than one course should be scheduled at the same time in the same room. (b) The classroom capacity should be more than the expected enrollment of the course. (c) Preference is given to post-graduate courses over undergraduate courses for scheduling. (d) The post-graduate (undergraduate) courses should be scheduled in the order they appear in the input file, and the highest possible priority of an instructor should be given. If no priority is specified, any class and time can be assigned. If any priority is incorrect, it is to be discarded. (e) No two post-graduate courses should be scheduled at the same time. (f) If no preference is specified for a course, the course should be scheduled in any manner that does not violate these constraints.
Inputs: Input file 1 and Input file 2. Outputs: Schedule.
- Produce a list of all courses that could not be scheduled because some constraint(s) could not be satisfied and give reasons for unschedulability. Inputs: Input file 1, and Input file 2. Outputs: Output 2, i.e., list of unschedulable courses and preferences and why.
- The data in input file 2 should be checked for validity against the data provided in input file 1. Where possible, the validity of the data in input file 1 should also be checked. Messages should be given for improper input data, and the invalid data item should be ignored.
Inputs: Input file 1 and Input file 2. Outputs: Error messages.
4.3 External Interface Requirements
User Interface: Only one user command is required. The file names can be specified in the command line itself or the system should prompt for the input file names.
4.4 Performance Constraints
For input file 2 containing 20 courses and up to 5 preferences for each course, the reports should be printed in less than 1 minute.
4.5 Design Constraints
Software Constraints
The system is to run under the UNIX operating system.
Hardware Constraints
The system will run on a Sun workstation with 256 MB RAM, running UNIX. It will be connected to an 8-page-per-minute printer.
Acceptance Criteria
Before accepting the system, the developer must demonstrate that the system works on the course data for the last 4 semesters. The developer will have to show through test cases that all conditions are satisfied.
