MyCourses a UML Docoment With Usecase and Class Diagrams

COMSATS Institute of Information Technology, Islamabad Campus

Spring 2011

MyCourses-A Course

Scheduling System CIIT-Spring-392-002

S O F T W A R E E N G I N E E R I N G - I I ( C S C 3 9 2 )

Certificate of Approval

It is certify that the semester project of BS (CS) “MyCourses-A Course Scheduling System“

was analyzed and designed by the following mentioned group members using object-oriented

techniques under the guidance of “Miss Sarah Masood” and supervision of “Mr. Saif ur

Rehman Khan” that in their opinions; it is fully adequate, in quality for passing the Software

Engineering-II (CSC 392) course of the degree of Bachelors of Science in Computer Sciences.

1. Miss Fareeha Amjad (SP09-BCS-014)

2. Miss Asma Kaleem (SP09-BCS-006)

________________________ __________________________

(Supervisor) (Project Coordinator)

________________________

(Course Instructor)

1 | P a g e

Table of Contents

1. Executive Summary ............................................................................................................................... 3

2. Vision Document ................................................................................................................................... 4

3. Software Requirement Specification .................................................................................................... 8

4. Software Project Plan: ........................................................................................................................ 16

4.1 Cost Estimation ..................................................................................................... 16

4.2 Software Schedule: ............................................................................................... 18

5- Software Test Plan Document ............................................................................................................ 23

6- Software Acceptance Test Plan ........................................................................................................... 28

7- Test Cases ............................................................................................................................................ 36

8- Test Summary Report ......................................................................................................................... 53

9- Formal Specification ............................................................................................................................ 74

10- Functional Category List With System Attributes ........................................................................... 80

11- Use Cases: ....................................................................................................................................... 84

Brief use-cases: ............................................................................................................. 84

Expanded Use-Cases: ................................................................................................... 85

Use Case Model: ........................................................................................................... 93

12- CRC Index Cards .............................................................................................................................. 94

13- Role Play Diagrams (RPD) .............................................................................................................. 109

14- System Glossary ............................................................................................................................ 139

15- Conceptual Model ......................................................................................................................... 140

16- System Operations ........................................................................................................................ 143

17- Operation Contracts ...................................................................................................................... 145

18- System Sequence Diagrams: ......................................................................................................... 151

19- UML Diagrams ............................................................................................................................... 156

1- Class Diagram ..................................................................................................... 156

2- Component Diagram ........................................................................................... 157

3- Deployment Diagram .......................................................................................... 158

4- Package Diagram ................................................................................................ 159

5- Activity Diagram ................................................................................................ 160

6- Sequence Diagram .............................................................................................. 163

2 | P a g e

20- Appendixes .................................................................................................................................... 165

Glossary ...................................................................................................................... 165

3 | P a g e

1. Executive Summary

Course scheduling is a tedious and error-prone task when done manually or semi-manually. For

this reason a program that can automatically produce course scheduling with given requirements

and constraints is very important. The goal of this project is to develop a course scheduler,

MyCourses. MyCourses will make it possible to enter data and requirements in a simple way

using a web-based interface, calculate and propose a schedule, enable manual updates, and

finally present the schedule for the selected courses. Since different people (students, lecturers,

program planners, etc.) will use the program its user friendliness is crucial. An efficient

automatic scheduling is also important, but even more important is a possibility to manually re-

schedule or pre-schedule some courses or course elements (like lectures, labs, etc.).

The goal of this project is to develop a course scheduler. Every university each year is facing

with the same problem: How to schedule a large number of courses in an optimal way while

fulfilling a number of constraints, such as available lecture rooms, limited availability of

lecturers, students‟ selections of the courses, and similar. MyCourses makes it possible to enter

data and requirements in a simple way using a web-based interface, calculate and propose a

schedule, enable manual updates, and finally present the schedule (manually re-schedule or pre-

schedule some courses) for the selected courses. The program should be implemented as a

distributed web-based, application, and data should be stored in a database.

My Courses will be implemented as an interactive program that enables entering data, calculates

and proposes a scheduling for courses, makes it possible to manually update the proposed

schedule, but keeping track of the consistent scheduling, and provides a presentation of

scheduled courses.

The document audience is administrator, manager, faculty and students. A program

administrator, who is responsible for management of the programs as the university defines

programs. A program manager, when enabled, can enter all details about the program such as If

the course is new, then the program manager creates it first, and then creates a new instance of it.

The main lecturer defines the details about the course instance he is assigned for.

4 | P a g e

2. Vision Document

1- Introduction:

This document sets out the high level vision for the Software Engineering II

project. We have to create a web-based course scheduler which will propose a schedule,

enable manual updates, and present the schedule for the selected courses.

2- Positioning:

2.1- Problem Statement

The problem of Every university faces the problem of course scheduling

every semester. Course scheduling is a tedious and

error-prone task when done manually or semi-

manually.

The impact of which is This has lead to the following two specific problems:

How to schedule a large number of courses in an

optimal way.

How to schedule the courses while fulfilling a large

number of constraints; such as available lecture rooms,

limited availability of lecturers, students’ selections of

the courses, etc.

A successful solution would be If we create a program with a web-based interface that

enables entering data and constraints related to the

course scheduling. The program calculates and

proposes a scheduling for courses and makes it possible

to manually update the proposed schedule, meanwhile

keeping track of the consistent scheduling.

The program must be user-friendly so that different

users can use this program as manual re-scheduling or

pre-scheduling of some courses is important.

2.2 Position Statement:

5 | P a g e

We will create a distributed web-based application, and data should be

stored in a database. Since the program is aimed for universities, FLOSS (Free/Libre and

Open Source Software) will be used.

3- Stakeholder and User Descriptions:

3.1 Stakeholder Summary:

Name Nominations Responsibilities

Designers Fareeha Amjad

Asma Kaleem The designers are responsible

for designing and maintaining

the data format, liaising and

working with the project

coordinator to ensure that it

meets their requirements.

Project Coordinator Sara Masood The coordinator is responsible

to check the work done by the

project members is alright or

not.

Project Manager Saif-ur-Rehman The manager checks the work

flow and assigns tasks to the

project members.

3.2 User Summary:

Name Description Responsibilities Stakeholder

Program

Administrator

They are typically

coordinators of a

certain department or

the HODs. They could

also be people from

the examination

department.

He is responsible for management of

the programs at the university defined

programs.

He identifies the program, its running

period (starting and ending year).

He enters data about different

resources: The available lecture rooms

and laboratories in which the courses

(or particular elements) will take place,

and some other elements such as data

The designers

will act as

stakeholders

for these

users.

6 | P a g e

about number of available places, or

availability of the room is entered.

Program

Manager

They are typically

coordinators of a

certain department or

the HODs. They could

also be people from

the examination

department.

He will have the overall responsibility

for the

Program.

He can enter all details about the

program.

The designers

will act as

stakeholders

for these

users.

Main lecturer Professors He defines the details about the course

instance he is assigned for. The designers

will act as

stakeholders

for these

users.

Automatic

scheduling

process-users

They could be

professors or

coordinators or people

from the examination

department.

Several users can run a

(semi)automatic scheduling process

that provides a schedule

proposal for a course or a set of

courses

The designers

will act as

stakeholders

for these

users.

Users that use

the program to

present data

They could be

professors or

coordinators or HOD or

people from the

examination

department.

Different users can use the program to

present data. For example: Availability

and utilization of the facilities; Schedule

of a particular course etc

The designers

will act as

stakeholders

for these

users.

3.3 User Environment

It is recommended that FLOSS tools are used in the project

3.4 Alternatives and Political Landscape

This project has been made by many developers and is commercially available as

well. It is possible that an alternative or similar format is present in the market. This is a

purely academic project and is not available for sale.

4- Product Overview:

7 | P a g e

This is a web-based application. It will perform its main functions as well as the

program will be configurable and flexible – i.e. that it can be configured with different

rules of scheduling (for example definition of semesters, periods of the course execution,

and similar). At the same time it is important that the program is user-friendly and that it

is easy to import/export data to other systems which the universities can have.

The project includes requirements solicitation, requirements specification, design and the

Implementation. The program will be implemented as a distributed web-based,

application, and the data will be stored in a database. Since the program is aimed for

universities, FLOSS (Free/Libre and Open Source Software) will be used.

5- Product Features:

1- User-friendly

2- Standards based

3- Free to use

4- Extensible

5- Able to perform all the required functionalities

6- Able to schedule effectively and efficiently

8 | P a g e

3. Software Requirement Specification

1. Introduction

The system “MyCourses-A Course Scheduling System” will provide a systematic way to

schedule courses which is considered very tedious when done manually or semi-

manually. It is also subjected to many errors. Therefore, our system will ease its users for

scheduling the courses for the semester.

In the following pages the reader is likely to find further elaboration of the project, and

how it will be carried out and what will be its feature characteristics and in which

environment it would likely work.

Purpose

The purpose of our system is to ease its user in the most error-prone and tedious of all tasks i.e.

course scheduling by providing a user friendly interface and making the application web-based

that enables entering data and constraints related to the course scheduling. The program

calculates and proposes a scheduling for courses and makes it possible to manually update the

proposed schedule, meanwhile keeping track of the consistent scheduling.

It will also enable the user to schedule some courses manually and also alert the user if an

error is made. The feature application of this product is to tell the user right there and then

when an error is made and also an added accessory is when it proposes a possible schedule.

Scope

Our software will be a web application built on the Java and MySQL platforms. The interface of

the software will be clear and intuitive to even non-technical users. We intend to include a

number of features that will make our software as useful as possible to users, including:

A secure login and registration system which allows only authenticated users to access the product features.

A robust search engine which can search all the registered courses including the objectives and course contents of the specific course.

Allow the user to see the previous professor who was teaching this course‟s schedule. A simple administration interface for the manager to perform tasks including user management,

updating system settings, and overall maintenance of the system. Integration with all the university‟s departments. This will help in indicating error if a teacher

from a certain department is not allocated 2 lectures at the same time Entering the available resources such as available lecture rooms, project labs, labs etc. The system must automatically schedule the courses that provide a schedule proposal for a

course or a set of courses: the days and time and places should be scheduled. The scheduler is not necessarily an automatic solver- but it allows some manual predefinition of

the schedule and manual changes after the proposal is created. And if during the manual scheduling any error occurs the scheduler must alert the user and also propose other options available.

Finally the scheduler will be able to present the schedule.

9 | P a g e

Definitions, Acronyms and Abbreviations

a. Automatic Scheduling: Scheduling done by the system itself

b. Course: The subjects taught to the students. Courses are organized by the department’s name.

c. Interface: A view of a semester which is visible to a user’s eye.

d. Manual Scheduling: Scheduling done manually by the user himself by drag and drop service provided by the system.

e. Resources: The things needed to teach a course e.g. lecture rooms etc

f. Scheduler: Something that is responsible for scheduling within the resources and requirements.

References

1. MyCourses-Course Scheduling System Score 2011 Student Contest on Software

Engineering- http://score-contest.org/2011/Projects.php#crnkovic

2. M. Dikaiakos, G. Tsouloupas; The Crossgrid SRS Template-

http://grid.ucy.ac.cy/gridbench/repository/CG2.3-D2.1-v1.0-UCY001-SRS.pdf

3. The IEEE SRS Template-

http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org

%2Fiel4%2F5841%2F15571%2F00720574.pdf%3Ftp%3D%26isnumber%3D15571

%26arnumber%3D720574&authDecision=-203

Overview

"The requirement document contains the general information and functionality about

MyCourses". The scope and boundaries of the project are mentioned in the SRS. The

functionality it will perform and the non-functional requirements are also illustrated.

Rest of the document is divided into chapters to enhance better understanding.

· In chapter 2 the overall description is provided.

http://score-contest.org/2011/Projects.php#crnkovic

http://grid.ucy.ac.cy/gridbench/repository/CG2.3-D2.1-v1.0-UCY001-SRS.pdf

http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel4%2F5841%2F15571%2F00720574.pdf%3Ftp%3D%26isnumber%3D15571%26arnumber%3D720574&authDecision=-203



10 | P a g e

· The chapter 3 shows the Specific Requirements.

2. Overall Description

2.1 Product Perspective

This product is original, self-contained project.

2.2 Product Functions

The system is designed to ease the user to schedule the courses. It will have the following

functions:

- Easy log-in - User-friendly interface - Drop-down menu to select department - Automatic Scheduling - Manual Scheduling - Error alerts - Presentation of the schedule for different users - Secure

2.3 User Characteristics

The user must be a part of the COMSATS Institute of Information Technology. He/she could be

a professor, a coordinator, a student etc.

2.4 Constraints

TBD

2.5 Assumptions and Dependencies

TBD

2.6 Apportioning of requirements

TBD

3. Specific Requirements

3.1 Performance Requirements:

11 | P a g e

The maximum staff connected at the same time will be 10. But it will be designed to be able to

connect simultaneously up to 50 users at any time of the day.

Interfaces will have an automated system that will allow a maximum response time of 5 seconds.

3.2 Usability Requirements:

This product will be very simple and easy to use. The overall system would be easily

used by people with basic computer systems training and with little understanding of

English. The system should be designed in a way that makes it easy for user to remember

the steps they should follow. Ideally, the system should be free of errors, but in case that

the users do something wrong the errors messages should be indicated in plain English, in

that way, it will be easier for users to understand what they are doing wrong when using

the system

3.3 Security Requirements:

This is a very safe system; we do not foresee any kind of risk for the people using it, neither to the

property nor to the environment.

All the staff will have access to the system, but only the Administrator will have rights to either

add new users or delete the ones that are leaving. Employees (faculty) will be able to generate

reports and update information and student will be able to access the information they are

required.

The system will prevent its data from incorrect usage by use of form validations.

Any user who uses the system shall have a Login ID and Password.

Any modification (insert, delete, and update) for the Database shall be synchronized and done only by the administrator.

Administrators shall be able to view and modify all information.

3.4 Precision requirements:

This product has been designed to be the most accurate possible, we should take into

consideration that this is a very simple system with no calculation formulae involved.

3.5 Reliability Requirements:

It is a very simple product, in which only input of information and generation of reports is

involved, our aim is to deliver a very reliable product with minimal degree of failures, and

therefore minimal maintenance is required.

3.6 Availability Requirement:

The system will be available for use 24 hours per day, 365 days per year.

3.7 Robustness Requirements:

12 | P a g e

The system's ability to continue functioning under abnormal circumstances is great. The system

will continue operating in local mode whenever it loses its link to the central server, but only

during the time the system gets linked to the backup server that will be set up for this kind of

circumstances. Also in case of disaster, there is a ring of staff who will be chosen to connect

from their homes either using cable or broadband.

3.8 Scalability or Extensibility Requirements:

Due to the nature of the system, the capacity of processing information is indefinite. We are

fully aware that the list of visitor will increase, that it is why we are designing our database in

MS SQL, which is a very powerful application to keep records.

3.9 Portability Requirements:

The system is web based with its target browser being internet Explorer; however, it would be expected to run across various web browsers.

3.10 Maintainability Requirements:

Since this system is web based should be maintained by either via phone or email where technical assistance will be available.

The level of support this system will require is very low. The help desk will be able to provide the necessary support. Also it will have some help tab in the main interface.

3.11 Functions:

Following functions must the software include:

- The system shall tell the user that the password is case-sensitive.

- The system shall not let a user use the unauthenticated processes.

- The system shall check a teacher’s workload and does not assign work

more than that.

- Teacher’s name shall only be alphabets

4- System Features:

4.1- User Authentication:

4.1.1- Description:

For security reasons and data hiding; user authentication is highly prioritized.

13 | P a g e

4.1.2- Stimulus/ Response Sequence:

Actor Action System Response

1: The user shall be able to open the page of

the website by entering the correct

username and password.

2: The user is connected to the server.

4.1.3- Functional Requirements:

FQEQ-1 The system shall be able to provide secure login to its users

4.2- Listing all the courses of a department

4.2.1- Description:

The user must be able to list all the courses of the chosen department.

4.2.2- Stimulus/ Response Sequence:


1. The user shall be able to choose the

department of his/her choice.

2. The page for the department should open.

3. The user; when clicks to list the courses:

the courses of that department shall be

listed.

4. The system displays the list of all the

courses.


FQEQ-2 The system shall be able to list the courses offered by the department

FQEQ-3 The system shall be able to search the department.

FQEQ-4 The system shall be able to provide description of the courses offered.

4.3- Edit the course content

4.3.1- Description:

The user shall be able to edit the description of a selected course.

4.3.2- Stimulus/ Activity Sequence:

14 | P a g e


1. The user shall be able to open the page to

“Add Information”.

2. The system opens the required page

asking for the name of the course and the

course ID.

3. The user shall be able to select the ID .

4. The system displays the name of the

course automatically.

5. The user shall be able to “edit” on the

area he/she wants editing and clicks Ok

when done entering all the desired

information.

6. The system updates the information.


FQEQ-5 The system shall be able to edit the course content.

FQEQ-6 The system shall be able to enable the view of the previous course content.

FQEQ- 7 The system shall be able to save the new course content.

FQEQ-8 The system shall be able to search the courses

4.4- Generating the time-table:

4.4.1- Description:

The user shall be able to generate a schedule.

4.4.2- Stimulus/Activity Sequence:


1. The user shall be able to enter the

semester for which he/she wants to

schedule.

2. The system asks to enter the semester.

3. The user shall be able to enter all the

courses for that semester.

4. The user shall be able to pick the

teachers.

5. The system displays the probable

schedule.

15 | P a g e


FQEQ-9 The system shall be able to schedule manually.

FQEQ-10 The system shall be able to schedule automatically.

FQEQ- 11 The system shall be able to view the schedule.

FQEQ-12 The system shall be able to edit the schedule.

FQEQ-13 The system shall be able to save the schedule.

16 | P a g e

4. Software Project Plan:

4.1 Cost Estimation

The FEMSEC model helps us to find the final cost of the project.

First we need to know the size of the project and the formula for finding the size is

=

( + 4 + ) [kloc].

Where

= 6000 kloc.

= 2000 kloc.

= 3 kloc.

=

( 6000 + 4 ( 3) + 2000).

= 8012 kloc. This the size.

Now as the final size is given we can find the ideal work load where productivity is 3000 loc/py.

1) Ideal load :

=

=

× 12 = 32.0[PM].

2) Optimal labour allocation.

Now we will find where r = 60 %

=

=

=

17 | P a g e

= 2 [P].

3) The shortest duration time.

=

( r . – r +

)

=

. 32.0 ( 0.6 . 2 – o.6 +

)

= 25.6 [M].

4) Expected work load .

= ×

= 2 × 25.6 = 51.2 [PM].

5) The final expected project cost.

= × ×

Where = 6000 py.

= 2 × 25.6×

= 25600 [$].

This was the final cost of our project.

Now we have to find Effort as it is a algorithm critical area so the reliability is HIGH

PCAP = HIGH= 0.70 and we will use organic mode to calculate effort.

EFFORT = EAF × 3.2 ×

EFFORT = 0.70 × 3.2 ×

EFFORT = 7.92

18 | P a g e

4.2 Software Schedule: Roles of different people:

Role Count Names

Project Manager 1 Saif Ur Rehman

On-site Coordinator 1(50%time) Sara Masood

Developer(s) 2 Fareeha Amjad

Asma Kaleem

Tester(s) 2 Fareeha Amjad

Asma Kaleem

Schedule:

Phase

Person

Performing

the task

Duration

(days) Start Date End Date

Requirement

Collection

Vision Document Asma Kaleem 5 2nd March, 2011 7th March, 2011

SRS Fareeha Amjad 14 7th March, 2011 21st March, 2011

Cost Estimation Asma Kaleem 14 7th March, 2011 21st March, 2011

Project Plan Asma Kaleem 14 7th March, 2011 21st March, 2011

User Stories Fareeha Amjad 14 7th March, 2011 21st March, 2011

Test Cases Fareeha Amjad

Asma Kaleem 4 21st March, 2011 25th March, 2011

Software Design

Z Spec Language Fareeha Amjad

Asma Kaleem 3 25th March, 2011 28th March, 2011

19 | P a g e

OOA model Fareeha Amjad

Asma Kaleem 3 25th March, 2011 28th March, 2011

System Model Fareeha Amjad

Asma Kaleem 7 28th March, 2011 4th April, 2011

Use Case Diagram Fareeha Amjad

Asma Kaleem 7 28th March, 2011 4th April, 2011

Conceptual Model Fareeha Amjad

Asma Kaleem 7 4th April, 2011 11th April, 2011

System Sequence

Diagram

Fareeha Amjad

Asma Kaleem 7 4th April, 2011 11th April, 2011

Class Diagram Fareeha Amjad

Asma Kaleem 10 11th April, 2011 21st April, 2011

Object Diagram Fareeha Amjad

Asma Kaleem 10 11th April, 2011 21st April, 2011

Component Diagram Fareeha Amjad

Asma Kaleem 8 21st April, 2011 29th April, 2011

Deployment

Diagram

Fareeha Amjad

Asma Kaleem 8 21st April, 2011 29th April, 2011

Composite

Collaboration

Diagram

Fareeha Amjad

Asma Kaleem 7 29th April, 2011 6th May, 2011

Package Diagrams Fareeha Amjad

Asma Kaleem 7 29th April, 2011 6th May, 2011

Sequence Diagram Fareeha Amjad

Asma Kaleem 3 6th May, 2011 9th May, 2011

State Machine

Diagram

Fareeha Amjad


20 | P a g e

Interaction

Diagrams

Fareeha Amjad


Development Fareeha Amjad


Quality Check

Software Quality

Assurance

Fareeha Amjad

Asma Kaleem 3 20th May, 2011 23rd May, 2011

Testing

Software Testing Fareeha Amjad

Asma Kaleem 4 23rd May, 2011 27th May, 2011

Deployment Fareeha Amjad

Asma Kaleem 10 27th May, 2011 6th June, 2011

Project Plan Summary:

Requirement Collection (23 days)

Design (52 days)

Development (4 days)

Quality (3 days)

Testing (4 days)

Deployment (10 days)

Gant Chart:

21 | P a g e

ID Task Name Start Finish Duration

Mar 2011 Apr 2011 May 2011

2/27 3/6 3/13 3/20 3/27 4/3 4/10 4/17 4/24 5/1 5/8 5/15 5/22 5/29

1 .8w3/7/20113/2/2011Vision Document

2 2.2w3/21/20113/7/2011SRS

3 2.2w3/21/20113/7/2011Cost Estimation

4 2.2w3/21/20113/7/2011Project Plan

5 2.2w3/21/20113/7/2011User Stories

6 1w3/25/20113/21/2011Test Cases

7 .4w3/28/20113/25/2011Z Spec Language

8 .4w3/28/20113/25/2011OOA model

9 1.2w4/4/20113/28/2011System Model

10 1.2w4/4/20113/28/2011Use Case Diagram

11 1.2w4/11/20114/4/2011Conceptual Model

12 1.2w4/11/20114/4/2011System Sequence Diagram

13 1.8w4/21/20114/11/2011Class Diagram

14 1.8w4/21/20114/11/2011Object Diagram

15 1.4w4/29/20114/21/2011Component Diagram

16 1.4w4/29/20114/21/2011Deployment Diagram

17 1.2w5/6/20114/29/2011Composite Collaboration Diagram

18 1.2w5/6/20114/29/2011Package Diagram

19 .4w5/9/20115/6/2011Sequence Diagram

20 1w5/13/20115/9/2011State Machine Diagram

21 .4w5/16/20115/13/2011Interaction Diagram

22 1w5/20/20115/16/2011Development

23 .4w5/23/20115/20/2011Software quality assurance

24 1.2w5/30/20115/23/2011Software Testing

25 1.4w6/6/20115/27/2011Deployment

The Work Break Down Structure:

22 | P a g e

AON Chart:

2nd

March 2325

th

March

2nd

March 025

th

March

Requirements

25th March 52 16

th May

25th March 0 16

th May

Design

16th May 4 20

th May

16th May 0 20

th May

Development

20th May 3 23

rd May

20th May 0 23

rd May

Quality

23rd

May 4 27th May

23rd

May 0 27th May

Testing

27th May 10 6

th June

27th May 0 6

th June

Desployment

S

T

A

R

T

F

I

N

I

S

H

23 | P a g e

5- Software Test Plan Document

1- Test Plan Identifier: TP-1

2- References:

Project Plan

SRS

Software Process Model

3- Introduction:

This is the Master Test Plan for the project „MyCourses-A Course Scheduling

System‟. This plan will address all parts of the project. The primary focus of this plan is

to ensure that all inputs provide the desired outputs.

The project will have three levels of testing; Unit, System/Integration, and

Acceptance. The details for each level are addressed in the approach section and will be

further defined in the level specific plans.

The estimated time line for this project is approximately 2 months. However any

delays during the semester schedule of the university may have significant effects on the

test plan. The acceptance testing is likely to be taken after each iteration.

4- Test Items(Functions):

We are going to check the functional and non functional requirements of the system.

5- Software Risk Issues:

The critical areas of the project are:

- Complex algorithm

- Software link to the university database

- Getting all the information regarding the subjects on the website

- Integrating previous and new information

- Managing time of every teacher

- Managing all student‟s issues regarding the schedule

- Documentation

The risks involved with the software are:

- Short Time

- Rules and Regulations of the university

- Multiple Clients

- Many users

24 | P a g e

6- Features to be Tested:

The following is the list of items that are to be focused on during testing of the

application. The level of risk scale is :(H for high; M for medium and L for low):

- All information regarding all courses; H

- Entering the course‟s parameters; M

- No redundant data; H

- Documentation; H

- Interface to the system; H

- Having different views for different users; M

- Security; H

- Data integrity; H

- Server availability; H

7- Features Not to be Tested:

The following is a list of the areas that will not be specifically addressed. All testing in

these Areas will be indirect as a result of other testing efforts.

- Network Security and dial-in access:

The software is independent of this issue as it would not affect it in any way.

- Changes in courses:

The changes are the responsibility of the administration.

- Slow network access:

This depends on the type of connection the user is logged in on.

8- Approach:

8.1-Testing Levels:

The testing for the „MyCourses-A course scheduling system‟ will consist of Unit,

System/Integration (combined) and Acceptance test levels. It is hoped that there will be at

least one full time independent test person for system/integration testing. However, with

the time line established; most testing will be done by the development team.

UNIT Testing will be done by the developer and will be approved by the project

coordinator; Miss Sara Masood. Proof of unit testing (test case list, sample output, and

defect information) will be provided by the programmers to the project coordinator

before unit testing will be accepted and passed on to the project manager.

SYSTEM/INTEGRATION Testing will be performed by the developers and with

assistance from the project coordinator as required. No specific test tools are available for

this project. Programs will enter into System/Integration test after all critical defects have

been corrected.

25 | P a g e

ACCEPTANCE Testing will be performed by the actual end users and/or the project

manager with the assistance of the developers. Programs will enter into Acceptance test

after all critical and major defects have been corrected. Prior to final completion of

acceptance testing all open critical and major defects MUST be corrected and verified by

the project manager.

8.2- Meetings:

The team will meet once every two weeks to evaluate progress to date and to identify

error trends and problems as early as possible. The project coordinator will meet with

development and the project manager once every two weeks as well. These two meetings

will be scheduled on different weeks. Additional meetings can be called as required for

emergency situations.

8.3- Measures and Matrices:

The following information will be collected by the Development team during the Unit

testing process. This information will be provided to the project manager at program

turnover as well as be provided to the project coordinator on a biweekly basis.

- Defects by module and severity.

- Defect Origin (Requirement, Design, Code)

- Time spent on defect resolution by defect, for Critical & Major only. All Minor

defects can be totaled together.

The following information will be collected by the development team during all

testing phases. This information will be provided on a biweekly basis to the project

manager and to the project coordinator.

- Defects by module and severity.

- Defect Origin (Requirement, Design, Code)

- Time spent on defect investigation by defect, for Critical & Major only. All Minor

defects can be totaled together.

- Number of times a program submitted to test team as ready for test.

- Defects located at higher levels that should have been caught at lower levels of

testing.

9- Item Pass/Fail Criteria: Once the project is submitted to the project manager, after using the product if he is

happy or satisfied with our work and effort then the project has passed otherwise it has

failed.

10- Suspension Criteria and Resumption Requirements: Whenever a major flaw is found; unless it is not corrected testing should be stopped there

and then as it is of no use.

If during testing more than half of the tests do not indicate any error and if there is a

shortage of time then it is alright not to test the remaining test items.

26 | P a g e

11- Test Deliverables: Acceptance test plan

Test cases

Test summary report

12- Remaining Test Tasks:

TASK Assigned To Status

Create Acceptance Test Plan Fareeha Amjad

Create Test Cases Asma Kaleem, Fareeha Amjad

Create Summary Report Asma Kaleem

13- Environmental Needs: Access to both the development and production systems is the required element to

support the overall testing efforts at all levels within the project scope.

14- Staffing and Training Needs: The system is user friendly and it does not need special training. However we are going

to make a presentation highlighting the characteristics of our project.

15- Responsibilities:

Developer 1

(Fareeha Amjad)

Developer 2

(Asma Kaleem) Project Manager

Acceptance Test Plan X

Test Cases X X

Summary Report X

Acceptance Testing X

Miss Fareeha Amjad will make „Acceptance Test Plan‟ and „Test Cases‟. Miss Asma

Kaleem will make „Test Cases‟ and „Summary Report‟. The Project Manager will

perform Acceptance Testing. The entire project team will participate in the review of the

system and detail designs as well as review of any change requests that are generated by

the user/manager or as a result of defects discovered during development and testing

27 | P a g e

16- Schedule: Following are the testing activities to be performed:

A- Review of Requirements document and initial creation of Inventory classes, sub-

classes and objectives.

B- Development of Master test plan.

C- Review of the System design document and will further definition the Inventory

classes, sub-classes and objectives.

D- Development of System/Integration and Acceptance test plans.

E- Review of the Detail design document(s)

F- Unit test time within the development process.

17- Planning Risks and Contingencies:

A- Limited Team Members:

As there are only two people working in this project. There is a shortage of people.

The entire burden is thus being put on two shoulders.

B- Limited Time:

There are roughly 2 months left to complete the project and there is so much to do.

18- Approvals: Project Manager

Project Coordinator

28 | P a g e

6- Software Acceptance Test Plan INTRODUCTION

This document is the Acceptance Test Plan (ATP) for “MyCourses-A Course Scheduling

System”. The acceptance test verifies that the system works as required and validates that the

correct functionality has been delivered. The ATP establishes the acceptance test framework

used by the team to plan, execute, and document acceptance testing. It describes the scope of the

work performed and the approach taken to execute the tests created to validate that the system

performs as required. The details of the ATP are developed according to the requirements

specifications, and must show traceability back to those specifications.

The system “MyCourses-A Course Scheduling System” will provide a systematic way to

schedule courses which is considered very tedious when done manually or semi-manually. It is

also subjected to many errors. Therefore, our system will ease its users for scheduling the

courses for the semester.

Our software will be a web application built on the Java and MySQL platforms. The interface of

the software will be clear and intuitive to even non-technical users. We intend to include a

number of features that will make our software as useful as possible to users, including:

A secure login and registration system which allows only authenticated users to access

the product features.

A robust search engine which can search all the registered courses including the

objectives and course contents of the specific course.

Allow the user to see the previous professor who was teaching this course‟s schedule.

A simple administration interface for the manager to perform tasks including user

management, updating system settings, and overall maintenance of the system.

Integration with all the university‟s departments. This will help in indicating error if a

teacher from a certain department is not allocated 2 lectures at the same time

Entering the available resources such as available lecture rooms, project labs, labs etc.

The system must automatically schedule the courses that provide a schedule proposal for

a course or a set of courses: the days and time and places should be scheduled.

The scheduler is not necessarily an automatic solver- but it allows some manual

predefinition of the schedule and manual changes after the proposal is created. And if

during the manual scheduling any error occurs the scheduler must alert the user and also

propose other options available.

Finally the scheduler will be able to present the schedule.

29 | P a g e

ACCEPTANCE TEST APPROACH

The approach we will be using is both the black box testing and the white box testing. The black

box testing approach will be used to check if the application‟s requirements and specifications

are according to the customer‟s needs. The white box testing will do the same accept for the fact

that it will use the actual code required for the testing.

ACCEPTANCE TEST PROCESS

The following is the process we will adopt for Acceptance Testing:

Establish Acceptance Test Framework

The Acceptance Test Plan establishes the acceptance test framework used by the team to plan,

execute, and document acceptance testing of system. Industry best practices for acceptance

testing and data derived from the acceptance test team‟s interface with the software development

processes form the basis for the AT framework.

Plan Acceptance Test Activities

A successful acceptance test effort requires plannning. The acceptance test team identifies the

tasks that need to be accomplished, including milestones. The functional requirements are the

primary drivers for identifying those tasks.

The acceptance test schedule is the timeline of acceptance testing activities and deliverable due

dates. For each acceptance testing effort, a test schedule is developed identifying the major test

preparation, test execution, and test reporting activities, as well as providing interim checkpoints

to measure the progress of acceptance testing. Mr. Saif Ur Rehman Khan and Miss Sarah

Masood will monitor the acceptance test effort.

Exhibit 1: Sample Acceptance Test Schedule

Activity Planned

Completion Date

Actual Completion

Date

Deliverable/ Checkpoint

Plan Acceptance Testing 11th April 2011 Preliminary Acceptance Test

Schedule

Identify Test Materials 11th April 2011 Preliminary Acceptance Test

Matrix

Establish Acceptance Test

Environment 11th April 2011

Acceptance Test Environment

Inventory

Conduct Acceptance Test

Readiness Review 1st June 2011

Draft Acceptance Test Plan

Matrix

Completed Test Readiness

Review Checklist

30 | P a g e

Activity Planned

Completion Date

Actual Completion

Date

Deliverable/ Checkpoint

Execute Tests 6th June 2011 Acceptance Test Progress

Complete Acceptance Testing 7th June 2011 Acceptance Test Summary

Report

Document Acceptance Testing 7th June 2011 Final Acceptance Test Report

Develop Acceptance Test Cases

In the following subsections, the process used to create acceptance test cases is described.

Sources for Test Cases

The acceptance tests are made from the requirements, user stories, existing documentation,

interviews, and research. The team reviews the software documentation, other documentation,

and existing software to identify software components and features. The acceptance test team

also attends requirements and design meetings and interviews persons involved in the system

analysis, development, test, and operations to identify gaps and clarify questions.

Structure for Acceptance Test

Comprehensive acceptance test materials are a critical component of a successful acceptance test

program. The acceptance test team uses a requirements-driven, structured approach to identify

acceptance test data.

The test casses are grouped into: functional and system test casses. Functional are those test

casses that are made via user stories and system test casses are those that are created to check

that the system‟s non functional requirements work properly such as security etc.

Test Procedures Development

Test procedures provide the testers with precise steps that should be followed to execute a test.

Test procedures are essentially the recipe used to perform the test. Test cases are identified and

documented as progressively detailed modules. Then they are prioritized on the basis of user

stories and then tests are performed as scheduled and documented.

Testing Priority

Assigning a test priority provides built in mitigation for schedule risks. Therefore, prior to the

test effort, the most critical system features are identified and assigned a priority level. The most

critical items are tested first, followed by progressively less critical items. This ensures the

critical items are tested when insufficient test time is allocated for acceptance testing. This

approach also provides immediate feedback on the critical system features early in the

acceptance test so the developers can begin addressing serious defects immediately. Any test

cases and system features that are not tested are documented and provided in the Acceptance

Test Summary Report.

31 | P a g e

We are going to prioritize on the basis of user stroies. The priority given to those user stories will

be given to their corresponding test casses.

Test Tools

We are not going to use any tool. We are going to test manually.

Acceptance Test Materials

As the acceptance test activities are performed, acceptance test plan materials are created and

added to the acceptance test plan as appendices. Each test for a particular release has its own

corresponding appendix, which is continously updated throughout the acceptance test.

The test casses are documented in another file in detail.

Develop Test Traceability Documentation

Test traceability is used to verify that functional requirements are accounted for, and tested in the

delivered software. It provides traceability between the requirements and the test materials. The

acceptance test team develops the traceability from the baselined requirements documents for the

software.

Each test case is formed from the user stories provided to us at the start of the project.

Set Up the Acceptance Testing Environment

Environment Preparation

In preparation for acceptance testing, the team identifies and addresses missing or incorrectly

configured hardware and software components.

Preparatory activities involve constructing the actual acceptance test environment and installing

the hardware and software, including the software to be tested, in order to ensure the

configuration is correct. Changes need to be closely managed and controlled. Prior to an

installation or configuration, the team checks and go through the test plan document as well as

the acceptance test plan document. Deviations from the planned activities are recorded and

reported to the acceptance test team. The test team begins acceptance testing by conducting an

initial series of ad hoc, diagnostic tests designed to exercise the acceptance test environment and

verify that major system software capabilities are available and functioning. The team also

checks the documentation.

Hardware/Software

Hardware requirements are a fully functional laptop or desktop computer. Software requirements

include code, Java IDE etc.

Conduct Acceptance Test Readiness Review (ATRR)

The ATRR is a critical acceptance testing checkpoint. At this review, Miss Sarah Masood, and

the developers jointly review the status of the System Test results and known problems, the

32 | P a g e

developed system and its associated documentation, the planned acceptance testing, the

acceptance test environment, and the support environment to determine whether or not to begin

acceptance testing. With the Acceptance Test Plan as the guiding document, components

reviewed include, but are not limited to:

Software components

Database

Environmental components

Documentation

Known problems and outstanding issues from the System Test

Inventory of the acceptance test environment

If the status of one or more of the components is unsatisfactory, the parties identify corrective

actions and schedule another ATRR. If the status is acceptable, then testing will proceed.

Execute Tests

Acceptance test execution is an iterative process that begins with the initial execution of the

planned tests. If no defects are discovered, then the test procedure has “passed.” If defects are

discovered, they are documented, corrected, and retested.

Acceptance testing continues until all the acceptance tests are successfully executed. However,

if the deadlines are near then team focuses on critical functionality. If test time expires before

completion of the acceptance tests, this would be documented.

Record Issues/Defects

As the issues and defects are identified, they are recorded. For each defect it is documented, area

of defect, who found it, where was it found etc is provided and a preliminary assessment of the

severity.

Retesting Corrected Software

After the defect has been detected it is removed and again presented for testing. Accompanying

the software correction, an inventory of changed components, and the defects corrected,

evidence of unit and/or System Testing, and instructions for installing the correction are also

provided and then the testing of these corrected components takes place.

Acceptance Regression Testing

After receipt of a software correction, the team performs regression testing to ensure the defect

or issue has been resolved and previously working software is not impacted.

Document Acceptance Test Results

At the end of the acceptance test, the acceptance test team produces two reports summarizing the

results of the acceptance test. The Test Summary Report is a short report summarizing the test

activities, and identifies outstanding deficiencies and issues. The Acceptance Test Final Report is

the detailed record of the acceptance test activities. It records which tests were performed, the

33 | P a g e

pass/fail status of each test, and the discrepancies or issues found. In addition, the Acceptance

Test Final Report identifies new tests added to the planned tests.

Conduct Acceptance Test Status Meetings

The acceptance testing will be done periodically to discuss the status of work. This will ensure

any major issues or defects are identified in a timely manner so they can be resolved.

Acceptance Test Deliverables

The following is a list of deliverables produced during the acceptance test phase:

Acceptance Test Plan

Acceptance Test Summary Report

Acceptance Test Final Report

Support Client Acceptance

The management department of COMSATS is the stakeholder who determines whether to accept

or reject the delivered software. Acceptance testing exercises the software and provides data to

be used in that decision. The management department of COMSATS will use the acceptance test

results from the Acceptance Test Summary Report to determine whether the software, as-built,

fulfills their mission requirements. If they determine that the software fulfills the requirements,

the will accepts the software and the system is prepared for production. If they determine that

the software does not fulfill its requirements, they will make a determination on further action.

ACCEPTANCE TEST ENTRANCE / EXIT CRITERIA

Acceptance Test Entrance Criteria

The following must be completed:

A. Acceptance Test Plan updated with the current tests

B. Completed System Test Report

C. Any open system issues.

Acceptance Test Exit Criteria

Acceptance Test Exit is based on the following criteria:

A. Completion of the Acceptance Test Final Report, which provides the final status of

acceptance test activities.

REPORTS

Interim Status Reporting

Exhibit 2: Sample Interim Status Report

34 | P a g e

INTERIM TEST STATUS REPORT

Tester Names: Date:

Functional Areas Number of

tests executed

Subtotal of tests

passed

Subtotal of tests failed

Percent Failed

Number of tests not tested

Issue/Defect Reporting

Exhibit 3: Issue/Defect Report Sample

ISSUE/DEFECT REPORT

Tester Name: Software Version:

Area of Software Impacted:

Preliminary Severity Assessment:

Nature of Issue/Defect:

What occurred:

How did it occur:

When did it occur:

Describe how to reproduce the error:

SCR INFORMATION

Assigned SCR Number: Severity: Status:

Functional Area 2

Functional Area 1

35 | P a g e

Acceptance Test Final Report

Exhibit 5: Acceptance Test Final Report Sample

ACCEPTANCE TEST FINAL REPORT

System Name: Date:

General description of the acceptance test effort:

Unresolved Defects

Issue/Defect Impact

(H, M, L)

Risk Mitigation (If known)

Work Around

(If known)

RISKS

The following are typical, general overall acceptance test risks:

1. Insufficient test time

Risk: If the amount of time available is too short, the team may not have enough time

to complete acceptance testing or perform regression testing.

Mitigation: Develop a critical path of tests, prioritized by importance.

36 | P a g e

7- Test Cases

Test Case: Enter description of the course , T1

Description: This test case simulates one of the frequently performed actions is which the user enters

the course requirements such as the allocation of books, reference books, the schedule of course etc.

The user will search the course by course ID, and then modify/add the course description.

Data Requirements:

{username} username must be unique and valid

{password} password must be valid

{courseID} must be unique for every course

Step

Number

Step Description Expected Result Transaction

Name

User

Think

Time

1) Enter the website’s URL and

press enter. And log-in with

{username} and {password}.

Main menu screen is

displayed.

User_login

2) Click the ‘Add Information”

button

Page opens asking for

the course name and

course ID.

Course_

identification

3) Click the drop down menu of

the course ID and choose the

ID

The name of the course

automatically appears

Select_course

4) Click Ok Form appears

containing the course’s

description (if already

present)

Description_

Course

5) Click “Edit” on the area that

needs to be edited; then click

Ok

Confirms if it must be

edited.

Edit_

Description

Test Case: Enter description of the course, T2



37 | P a g e


Data Requirements:




Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


button


the course name and

course ID.

Course_

identification



ID



Select_course

4) Click Ok Form appears

containing the course’s

description (if already

present)

Description_

Course

5) Click “Edit” on the area that

needs to be edited; then click

CANCEL.

Confirms if it must be

canceled.(no change)

Edit_

Description

Test Case: Enter description of the course, T3




Data Requirements:


38 | P a g e



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


button


the course name and

course ID.

Course_

identification



ID



Select_course

4) Click Cancel Return to main menu. Back_to_Main

Test Case: Searching the course, T4

Description: The user will search the course by course ID. The user wants to search the course for

various purposes.

Data Requirements:




Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Enters the name or course ID Page opens for the Course_

39 | P a g e

on the search bar course. identification

Test Case: Searching the course, T5

Description: The user will search the course by course ID. The user wants to search the course for

various purposes.

Data Requirements:




Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Enters the wrong name or

course ID on the search bar

Page opens informing

the user to enter the

correct course details.

Course_

identification

Test Case: Listing the courses offered by a certain department, T6

Description: The user enters the name of the department to list the courses offered by that department.

Data Requirements:



{departmentName} must be unique name for each department

Step

Number


Name

User

Think

Time

40 | P a g e




Main menu screen is

displayed.

User_login

2) Choose the department from

the drop down menu

Page of the chosen

department opens.

Department_

identification

3) Click the list of courses. The list of courses

offered by the

department opens.

List_courses

Test Case: View the course offered by a certain department, T7

Description: The user enters the name of the department to list the courses offered by that department.

Data Requirements:



{departmentName} must be unique name for each department

Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


the drop down menu

Page of the chosen

department opens.

Department_

identification

3) Click the list of courses. The list of courses

offered by the

department opens.

List_courses

4) Click on the course The course details open. Description_

Course

41 | P a g e

Test Case: Adding a new course, T8

Description: The user adds a new course.

Data Requirements:




Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


the drop down menu

Page of the chosen

department opens.

Department_

identification

3) Click ‘Add Course” Form appears New_course

4) Enter the name, ID and the

department it links to then

add all the required

information then click Ok.

Confirms the

information.

Add_

Course

Test Case: Adding a new course, T9

Description: The user adds a new course.

Data Requirements:




Step

Number


Name

User

Think

42 | P a g e

Time




Main menu screen is

displayed.

User_login


the drop down menu

Page of the chosen

department opens.

Department_

identification

3) Click ‘Add Course” Form appears New_course

4) Enter the name, ID and the

department it links to then

add all the required

information then click Cancel.

Confirms it must be

cancelled.(no course

added)

Add_

Course

Test Case: Auto-Scheduling, T10

Description: The user wants to schedule automatically; the system generates an automatic schedule.

Data Requirements:




Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Auto Schedule’ Page opens that asks for

the semester

Semester_

identification

3) Enter the semester and

department along with the

courses offered for that

Page opens to choose

teachers (if multiple

teachers are available

Assign_course

43 | P a g e

semester for a particular course)

4) Click Schedule. Conforms the schedule Auto_Schedule



Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


the semester

Semester_

identification



courses(drop down menu)

offered for that semester




for a particular course)

Assign_courses


5) Click Cancel Returns to the previous

page

Assign_courses



Data Requirements:


44 | P a g e


Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


the semester

Semester_

identification









Assign_course

4) Click Cancel. Returns to main menu Back_to_Main

Test Case: Manual-Scheduling, T13

Description: The user wants to schedule manually.

Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Manual Schedule’ Page opens that asks for

the semester

Semester_

identification





Assign_courses

45 | P a g e





4) Drag the course and drop it

in the table at the place you

want it to be.

Conforms the move Manual_Schedule

5) Click Ok and repeat step 4

and 5, then click Done.

Confirms the table Assign_courses



Data Requirements:



Step

Number

Step Description Expected Result Transaction Name User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Manual Schedule’ Page opens that asks

for the semester

Semester_

identification









Assign_courses


in the table at the wrong

place.

Shows up a warning and

does not save the move

Manual_Schedule


46 | P a g e


Data Requirements:



Step

Number

Step Description Expected Result Transaction Name User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Manual Schedule’ Page opens that asks

for the semester

Semester_

identification









Assign_courses


in the table at the place that

creates a clash


does not save the move

Manual_Schedule

Test Case: Edit Auto-Scheduling, T16

Description: The user wants to schedule automatically; the system generates an automatic schedule but

edits it and schedule manually.

Data Requirements:



Step

Number


Name

User

Think

Time

47 | P a g e




Main menu screen is

displayed.

User_login


the semester

Semester_

identification




semester





Assign_course


5) Click edit and move courses

manually.

Confirms the move. Edit_Schedule




Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


the semester

Semester_

identification







Assign_course

48 | P a g e

semester for a particular course)



at a wrong place.


does not save the move.

Edit_Schedule




Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login


the semester

Semester_

identification




semester





Assign_course



at a place that creates a

clash.


does not save the move.

Edit_Schedule

49 | P a g e

Test Case: Presenting the Schedule, T19

Description: The user wants to present the generated schedule.

Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Show Table’ Page opens that asks for

the semester and

department.

Semester_

identification


department

Page opens that displays

the schedule of that

semester.

Show_Schedule

Test Case: Presenting the Schedule, T20

Description: The user wants to present the generated schedule.

Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

50 | P a g e

2) Click “Show Table’ Page opens that asks to

open ‘your schedule’

Semester_

identification

3) Click ‘your schedule’. Page opens that displays

the schedule of the

logged in teacher.

Show_Schedule

Test Case: Saving the Schedule, T21

Description: The user wants to present the generated schedule and save it.

Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Show Table’ Page opens that asks to

open ‘your schedule’

Semester_

identification

3) Click ‘your schedule’. Page opens that displays

the schedule of the

logged in teacher.

Show_Schedule

4) Click save Confirms it and asks for

saving destination.

Save_Schedule

Test Case: Saving the Schedule, T22

Description: The user wants to present the generated schedule and save it.

51 | P a g e

Data Requirements:



Step

Number


Name

User

Think

Time




Main menu screen is

displayed.

User_login

2) Click “Show Table’ Page opens that asks for

the semester and

department.

Semester_

identification


department

Page opens that displays

the schedule of that

semester.

Show_Schedule

5) Click save Confirms it and asks for

saving destination.

Save_Schedule

Test Case: Log-in, T23

Description: The user will log-in to his/her account to go to the main menu.

Data Requirements:



Step

Number Step Description Expected Result

Transaction

Name

User

Think

Time


press enter

Page is displayed asking

for {username} and

{password}

Enter_login

2) Enter {username} - Enter_username

52 | P a g e

3) Enter {password} - Enter_password

4) Click Ok Main Menu is displayed. User_login



Data Requirements:



Step


Transaction

Name

User

Think

Time


press enter


for {username} and

{password}

Enter_login

2) Enter wrong {username} - Enter_username

3) Enter {password} - Enter_password

4) Click Ok

Display message

“Incorrect username or

password”

Incorrect_login



Data Requirements:

53 | P a g e



Step


Transaction

Name

User

Think

Time


press enter


for {username} and

{password}

Enter_login

2) Enter {username} - Enter_username

3) Enter wrong {password} - Enter_password

4) Click Ok

Display message

“Incorrect username or

password”

Incorrect_login

8- Test Summary Report GENERAL INFORMATION

Test Stage: Unit Functionality Integration System

Interface

Performance Regression Acceptance Pilot

Specify the testing stage for this Test Summary Report.

Test Log

Number:

T1 Test Case

Number:

01 Summary

Review

Date:

04/22/11

54 | P a g e

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T2 Test Case

Number:

02 Summary

Review

Date:

04/29/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

55 | P a g e

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T3 Test Case

Number:

03 Summary

Review

Date:

05/6/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

56 | P a g e

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T4 Test Case

Number:

04 Summary

Review

Date:

05/10/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


57 | P a g e

Interface



Test Log

Number:

T5 Test Case

Number:

05 Summary

Review

Date:

05/14/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T6 Test Case

Number:

06 Summary

Review

Date:

05/18/11

58 | P a g e

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T7 Test Case

Number:

07 Summary

Review

Date:

05/23/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

59 | P a g e

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T8 Test Case

Number:

08 Summary

Review

Date:

05/28/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

60 | P a g e

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T9 Test Case

Number:

09 Summary

Review

Date:

05/31/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


61 | P a g e

Interface



Test Log

Number:

T10 Test Case

Number:

10 Summary

Review

Date:

05/31/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T11 Test Case

Number:

11 Summary

Review

Date:

05/31/11

62 | P a g e

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T12 Test Case

Number:

12 Summary

Review

Date:

05/31/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

63 | P a g e

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T13 Test Case

Number:

13 Summary

Review

Date:

06/02/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

64 | P a g e

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T14 Test Case

Number:

14 Summary

Review

Date:

06/02/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


65 | P a g e

Interface



Test Log

Number:

T15 Test Case

Number:

15 Summary

Review

Date:

06/02/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T16 Test Case

Number:

16 Summary

Review

Date:

06/06/11

66 | P a g e

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T17 Test Case

Number:

17 Summary

Review

Date:

06/06/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

67 | P a g e

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T18 Test Case

Number:

18 Summary

Review

Date:

06/06/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

68 | P a g e

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T19 Test Case

Number:

19 Summary

Review

Date:

06/13/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


69 | P a g e

Interface



Test Log

Number:

T20 Test Case

Number:

20 Summary

Review

Date:

06/13/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T21 Test Case

Number:

21 Summary

Review

Date:

06/13/11

70 | P a g e

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T22 Test Case

Number:

22 Summary

Review

Date:

06/13/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

71 | P a g e

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T23 Test Case

Number:

23 Summary

Review

Date:

06/20/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

72 | P a g e

<Signature>: .

<Signature>:

GENERAL INFORMATION


Interface



Test Log

Number:

T24 Test Case

Number:

24 Summary

Review

Date:

06/20/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

GENERAL INFORMATION


73 | P a g e

Interface



Test Log

Number:

T25 Test Case

Number:

25 Summary

Review

Date:

06/20/11

TEST SUMMARY

Test Summary:

Variances:

Assessment:

Summary of

Results:

Evaluation: .

Corrective

Action Plan

(CAP):

APPROVALS

<Signature>: .

<Signature>:

74 | P a g e

9- Formal Specification

State Space Model:

The names of the sets are TEACHER, COURSE, ROOM, DESCRIPTION, PASSWORD,

DEPARTMENT, STUDENT.

„known‟ is the set of teachers. „known2‟ is the set of courses, „known3‟ is the set of course

description, „known4‟ is the set of rooms, „known5‟ is the set of passwords, „known6‟ is the set

of department, and „known7‟ is the set of students.

„inRoom‟ is a function that maps courses with room, „teach‟ is a function that maps teacher with

course, „schedule‟ is a function that maps course with teacher, „cdesc‟ is a function that maps

course with its description, „func‟ is a function that maps teacher with password, „dept‟ is a

function that maps course with department, „func2‟ is a function that maps student with course,

„s_course‟ is a function that maps student with course, „s_dept‟ is a function that maps student

with department‟ and „c_student‟ maps course with student.

The part of the schema below the line is called the invariants, which are true in every case.

OPERATIONS:

1

This function states the initial state of the system. All sets are initialized to null. This is done to

include empty set conditions.

75 | P a g e

______________________________________________________________________________

2-

REPORT is a variable that consists of exactly two variables: Success and Failure.

“SuccessR” is a function that reports Success and “FailureR” reports Failure.

______________________________________________________________________________

3-

“AddCourse” is a function that adds a new course and its description in the database and reports

success if done and failure if course is already present. It takes course name as input that should

not belong to the set of courses and course description and outputs report to tell if it‟s a Success

or Failure. If the name of the input course exists then the course description is not added.

______________________________________________________________________________

4-

“Schedule_Teacher_with_Course” is a function that takes teacher‟s name and course‟s name as

input and as a result saves it and reports success and failure accordingly.

______________________________________________________________________________

5-

76 | P a g e

“WhichRoom” is a function that takes course name and room number as an input, if they both

exists then that room is assigned to the course and reports success.

______________________________________________________________________________

6-

“FindCourseDesc” is a function that takes course‟s name as input and gives its description as

output and reports success if the course is present else reports failure.

______________________________________________________________________________

7-

“FindWhichRoom” is a function that takes course‟s name as input and gives the room number

assigned to it as output if course‟s name exists and reports success.

______________________________________________________________________________

8-

In this schema we give teacher‟s name as input and get the courses he/she teach as an output. If

the teacher exists; success else failure is reported.

______________________________________________________________________________

9-

77 | P a g e

In this schema we take course‟s name as input and get the teachers who teach those courses as an

output. If the course name exists then success else failure is reported.

______________________________________________________________________________

10-

In this schema; teacher‟s name and password is taken as an input and if the two exists in the

function: func; then success is reported else failure is reported.

______________________________________________________________________________

11-

In this schema; student‟s name and password is taken as an input and if the two exists in the

function: func2; then success is reported else failure is reported.

______________________________________________________________________________

12-

In this schema; department‟s name is taken as an input and the courses it offers is given as an

output. If the department‟s name exists then success else failure is reported.

78 | P a g e

______________________________________________________________________________

13-

This schema is user to edit description of a course or add the description of the course. It takes

the course‟s name as an input if it exists then description is taken as an input and success is

notified. Else if the course‟s name does not exist then failure is notified.

______________________________________________________________________________

14-

“AutoScheduling” is a combination of “Teacher_Teach_Which_Courses” and

“FindWhichRoom” schemas then success of these two schemas will be reported success of

AutoScheduling else failure is reported.

______________________________________________________________________________

15-

“ManualScheduling” is a combination of “Teacher_Teach_Which_Courses” and

“FindWhichRoom” schemas then success of these two schemas will be reported success of

ManualScheduling else failure is reported.

______________________________________________________________________________

16-

Student‟s name is taken a s input and if it exists then the list of courses he/she takes is given as

an output and is reported success else failure.

______________________________________________________________________________

17-

79 | P a g e

Course‟s name is taken as an input and if it exists then all the students who take the course are

given as an output and is reported as success else failure.

______________________________________________________________________________

18-

In this schema student‟s name is taken as an input and the department he/she belongs to is given

as an output and is reported success else failure.

______________________________________________________________________________

80 | P a g e

10- Functional Category List With System Attributes

BASIC FUNCTIONS:

Ref# Function Category

RQ.1 Login giving correct ID and password Evident

RQ.2 List the Courses Evident

R2.1 List the courses using semester Evident

R2.2 List the courses using department name Evident

RQ.3 Search a course Evident

R3.1 Search a course using course name Evident

R3.2 Search a course using a course ID Evident

RQ.4 Edit the details of the course Evident

RQ.5 Add a new course Evident

RQ.6 Schedule automatically Evident

RQ.7 Schedule manually Evident

RQ.8 Present the schedule Evident

RQ.9 Show the details of a course Evident

RQ.10 Edit auto- scheduling Evident

RQ.11 Save the schedule Hidden

RQ.12 Delete Course Evident

RQ.13 Provide a persistent storage mechanism Hidden

RQ.14 Detect errors Hiddem

System Attributes:

Attribute Details and Boundary Constraints

Response Time [Boundary Constraint]- The system should not take

more than 10 sec for the calculations

Interface Metaphor [Detail]forms-metaphor windows and dialog boxes [Detail] maximize for every keyboard navigation rather than pointer navigation

Fault Tolerance [Boundary Constraint] the user can log-in at anytime of the day and any number of times

81 | P a g e

10- System Attributes in Function Specification:

Ref# Function Cat. Attributes Details and Constraints

Cat.

RQ.1 Login giving correct ID and password

Evident Fault Tolerant

Must log in using username and password

Must

Interface Metaphor

Form based Colorful

Must Want

RQ.2 List the Courses Evident Response Time

System should be able to process the results timely

Must

Fault Tolerant

The user should be logged in to use the functionality

Must

Interface Metaphor

The courses must be chosen from the drop down menu

Must

R2.1 List the courses using semester Evident Response Time


Must

Fault Tolerant


Must

Interface Metaphor

The courses must be chosen from the drop down menu as well as the semester

Must

R2.2 List the courses using department name

Evident Response Time


Must

Fault Tolerant


Must

Interface Metaphor

The courses must be chosen from the drop down menu as well as the department

Must

RQ.3 Search a course Evident Response Time


Must

Fault Tolerant


Must

R3.1 Search a course using course name



Must

82 | P a g e

Fault Tolerant


Must

R3.2 Search a course using a course ID



Must

Fault Tolerant


Must

RQ.4 Edit the details of the course Evident Fault Tolerant


Must

Interface Metaphor

The edit window should open up separately

Must

RQ.5 Add a new course Evident Fault Tolerant


Must

RQ.6 Schedule automatically Evident Response Time


Must

Fault Tolerant


Must

RQ.7 Schedule manually Evident Fault Tolerant


Must

Interface Metaphor

The courses must be placed into the appropriate slots using drag and drop

Must

RQ.8 Present the schedule Evident Fault Tolerant


Must

Interface Metaphor

Colorful Want

RQ.9 Show the details of a course Evident Fault Tolerant


Must

Response Time


Must

RQ.10 Edit auto- scheduling Evident Fault Tolerant


Must

RQ.11 Save the schedule Hidden Fault Tolerant

The user should be logged in to use the

Must

83 | P a g e

functionality

Response Time


Must

RQ.12 Delete Course Evident Fault Tolerant


Must

Response Time


Must

RQ.13 Provide a persistent storage mechanism

Hidden Fault Tolerant


Must

RQ.14 Detect Errors Hidden Fault Tolerant


Must

Response Time


Must

84 | P a g e

11- Use Cases:

Brief use-cases:

1- Login: The user opens the page of the website to enter the correct username and

password. The system logs in the user to the server.

2- Listing the courses: The user chooses the department of his/her choice from a drop down

menu. The system opens up the page of that department. The user clicks the “List all

Courses” on the page. The system displays the list of all courses of that department.

3- Edit Course Content: The user clicks the button “Add information”. The system opens

the required page asking for the name of the course and the course ID. The user selects

the ID from the drop down menu. The system displays the name of the subject

automatically. The user clicks “ok”. The system displays the form of the course having

the previous data. The user clicks “edit” on the area he/she wants editing and clicks “ok”

when finished. The system opens up a new window for the user to edit and it updates the

information when “ok” is pressed by the user.

4- Adding a new Course: The user chooses the department of his/her choice from a drop

down menu. The page for the department opens. The user clicks the “add a course”. The

system displays a form. The user assigns the name and ID of the course. The system

checks if the ID is not already in use. The user enters the information regarding the

course and clicks Ok when done. The system updates.

5- Auto-Scheduling: The user clicks on automatic scheduling tab. The system asks to enter

the semester. The user enters the semester for which he/she wants to schedule. The

system asks to enter courses. The user enters all the courses for that semester. The system

gives a list of teachers to choose from for the entire subjects if there are multiple teachers

for a subject. The user picks the teachers. The system displays the probable schedule.

6- Manual-Scheduling: The user clicks on manual scheduling tab. The system asks to enter

the semester. The user enters the semester for which he/she wants to schedule. The


opens up the table and a drag and drop menu listing the subjects marked by the user. The

user drags the subject and drops it in the table where he/she wants it to be. The system

displays the schedule. The user clicks ok. The system updates.

85 | P a g e

7- View Schedule: The user clicks on “Show Table”. The system opens a drop down menu

asking to present the time table of: semester, teacher or department. The user chooses one

of the options. The system asks to enter semester or teacher‟s id or department‟s name.

The user enters the information. The system displays the schedule.

8- Deleting a course: The user writes the name of the course or course ID on the search bar

and press enter. The system opens the page containing the information of that course. The

user clicks on “delete” button. The system reconfirms. The user clicks “ok”. The course

is deleted from the database.

9- Edit Auto-Scheduling: The user clicks on automatic scheduling tab. The system asks to

enter the semester. The user enters the semester for which he/she wants to schedule. The


gives a list of teachers to choose from for the entire subjects if there are multiple teachers

for a subject. The user picks the teachers. The system displays the probable schedule. The

user clicks “edit”. The system makes the subjects drag-able. The user drags the

subjects/courses from its original place to the place he/she wants it to be. The user clicks

“ok” when done. The system updates.

10- Saving Schedule: The user after scheduling clicks “save”. The system asks the location

to save the schedule. The user browses the location and clicks ok. The system saves the

file in .pdf format.

Expanded Use-Cases:

USE CASE NO 1

USE CASE NAME Login

PRIMARY ACTOR Any Authenticated User.

Purpose Log-in a user to the system server.

Overview When any of the users wants to connect, he/she will provide

his/her username and password.

Type Primary and real

Cross Reference Functions: RQ.1, RQ.14

NORMAL COURSE OF EVENTS

86 | P a g e


Step 1:

The user opens the page of the website to

enter the correct username and password.

Step 2:

The user is connected to the server.

ALTERNATE COURSE

Step 1:

The user is already connected to the server.

USE CASE NO 2

USE CASE NAME Listing the courses


Purpose For listing the courses.

Overview When any of the users wants to list all the courses of a certain

department of his/her choice-the list is displayed.


Cross Reference RQ.2, RQ.14



Step 1:

The user chooses the department of his/her

choice from a drop down menu.

Step 3:

The user clicks the list of all courses on the

page.

Step 2:

The page for the department opens.

Step 4:

The system displays the list of all the

courses.

ALTERNATE COURSE

Step 1:

The user could also choose the department from home directly.

USE CASE NO 3

87 | P a g e

USE CASE NAME Edit Course Content


Purpose To edit the content of the description of courses

Overview The user wants to enter the details of the course and the system

updates the information.


Cross Reference Functions: RQ.4, RQ.13, RQ.14



Step 1:

The user clicks the button “Add

Information”.

Step 3:

The user selects the ID from the drop down

menu.

Step 5:

The user clicks OK.

Step 7:

The user clicks “edit” on the area he/she

wants editing and clicks Ok when done

entering all the desired information.

Step 2:

The system opens the required page asking

for the name of the course and the course ID.

Step 4:

The system displays the name of the course

automatically.

Step 6:

The system displays the form of the course,

having the previous data.

Step 8:

The system updates the information.

ALTERNATE COURSE

Step 3:

The user selects the name from the drop down menu and the system displays the course ID

automatically.

USE CASE NO 4

USE CASE NAME Adding a new Course


Purpose To add new courses in the database.

Overview When any of the users wants to add a new course; the system

generates a form and updates the information.


88 | P a g e




Step 1:

The user chooses the department of his/her

choice from a drop down menu.

Step 3:

The user clicks the “add a course”

Step 5:

The user assigns the name and ID of the

course.

Step 7:

The user enters the information regarding

the course and clicks Ok when done.

Step 2:

The page for the department opens.

Step 4:

The system displays a form.

Step 6:

The system checks if the ID is not already in

use.

Step 8:

The system updates.

ALTERNATE COURSE

Step 1:

The user can click on the icon of the department directly if he/she is on the home page.

USE CASE NO 5

USE CASE NAME Auto-Scheduling


Purpose To schedule the time table automatically.

Overview When the user wants to schedule automatically; the system

generates an automatic schedule.





Step 1:

The user clicks on automatic scheduling tab.

Step 3:

The user enters the semester for which

he/she wants to schedule.

Step 5:

Step 2:

The system asks to enter the semester.

Step 4:

The system asks to enter courses.

89 | P a g e

The user enters all the courses for that

semester.

Step 7:

The user picks the teachers.

Step 6:

The system gives a list of teachers to choose

from for the entire subjects if there are

multiple teachers for a subject.

Step 8:

The system displays the probable schedule.

ALTERNATE COURSE

Step 1:

The user clicks the automatic scheduling button if the user is on the home page.

USE CASE NO 6

USE CASE NAME Manual-Scheduling


Purpose To schedule the time table manually.

Overview When the user wants to schedule manually; the system

generates saves the schedule.





Step 1:

The user clicks on manual scheduling tab.

Step 3:



Step 5:


semester.

Step 7:

The user drags the subject and drops it in

the table where he/she wants it to be.

Step 9:

The user clicks ok.

Step 2:


Step 4:


Step 6:

The opens up the table and a drag and drop

menu listing the subjects marked by the user.

Step 8:

The system displays the schedule.

Step 10:

The system updates.

ALTERNATE COURSE

Step 1:

90 | P a g e

The user clicks the manual scheduling button if the user is on the home page.

USE CASE NO 7

USE CASE NAME View Schedule


Purpose To show the time table

Overview When the user wants to present the schedule; the system

presents it.





Step 1:

The user clicks on “Show Table”.

Step 3:

The user enters the semester.

Step 2:


Step 4:

The system displays the schedule.

ALTERNATE COURSE

Step 2:

The semester chosen by the user isn‟t yet scheduled; the system displays the

corresponding message informing the user.

USE CASE NO 8

USE CASE NAME Deleting a Course


Purpose To delete a specific course

Overview When the user wants delete a course already present in the

database.





Step 1:

The user writes the name of the course or

91 | P a g e

course ID on the search bar and presses

enter.

Step 3:

The user clicks on “delete” button.

Step 5:

The user clicks “ok”.

Step 2:

The system opens the page containing the

information of that course.

Step 4:

The system reconfirms.

Step 6:

The course is deleted from the database.

ALTERNATE COURSE

Step 2:

The course chosen by the user isn‟t present in the database; the system displays the

corresponding error message informing the user.

USE CASE NO 9

USE CASE NAME Edit Auto-Scheduling


Purpose To edit schedule the timetable that was generated

automatically.

Overview When the user wants to schedule automatically; the system

generates an automatic schedule. And the user wants to edit it.





Step 1:

The user clicks on automatic scheduling tab.

Step 3:



Step 5:


semester.

Step 7:

The user picks the teachers.

Step 9:

Step 2:


Step 4:


Step 6:

The system gives a list of teachers to choose

from for the entire subjects if there are

multiple teachers for a subject.

Step 8:

The system displays the probable schedule.

92 | P a g e

The user clicks “edit”.

Step 11:

The user drags the subjects/courses from its

original place to the place he/she wants it to

be and clicks “ok” when done.

Step 10:

The system makes the subjects drag-able.

Step 12:

The system updates.

ALTERNATE COURSE

Step 1:

The user clicks the automatic scheduling button if the user is on the home page.

USE CASE NO 10

USE CASE NAME Saving the schedule


Purpose To save schedule the timetable that was generated

automatically or manually.

Overview When the user wants to schedule automatically or manually; the

system generates an automatic schedule. And the user wants to

save it.





Step 1:

The user after scheduling clicks “save”.

Step 3:

The user browses the location and clicks ok.

Step 2:

The system asks the location to save the

schedule.

Step 4:

The system saves the file in .pdf format.

ALTERNATE COURSE

Step 1:

If the schedule not complete; the system generates an error message.

93 | P a g e

Use Case Model:

94 | P a g e

12- CRC Index Cards

Class Name: Person ID: 1 Type: Abstract, Domain

Description: A teacher who is registered. Associated Use Case: 1,2,3,4,5,6,7,8,9,10,11

Responsibilities

Collaborators

Attributes: FirstName (String) LastName (String) ID (String) Password (String)

Relationships: Generalization: Aggregation: Other: Teacher, Student, Admin

95 | P a g e

Class Name: Teacher ID: 2 Type: Concrete, Domain

Description: A teacher who is registered. Associated Use Case: 1,2,3,4,8,11

Responsibilities

Log in

Add Course Desc

Search Course/s

Show Related Teachers

View Schedule

Save Schedule

Edit Course Content

Collaborators

Connectivity

AddInfo

Search

View

View

Edit

Attributes: Department (String) CoursesTeaching (String[])

Relationships: Generalization: Person Aggregation: Other: Connectivity, AddInfo, Search, List, View, Edit

96 | P a g e

Class Name: Student ID: 3 Type: Concrete, Domain

Description: A student who is registered. Associated Use Case: 1,2,3,8,11

Responsibilities

Log in

Search Course/s

List Courses

View Course Content

Collaborators

Connectivity

Search

List

View

Attributes: Department (String) Semester (String) CoursesTaking (String[])

Relationships: Generalization: Person Aggregation: Other: Connectivity, Search, List, View

97 | P a g e

Class Name: Admin ID: 4 Type: Concrete, Domain

Description: A user from administration Associated Use Case: 1,2,3,4,5,6,7,8,9,10, 11

Responsibilities

Log in

Add a course

Search course/s

Schedule Time Table

List Courses

View Time Table

Remove a Course

Collaborators

Connectivity

AddInfo

Search

Schedule

List

View

Remove

Attributes:

Relationships: Generalization: Person Aggregation: Other: Connectivity, AddInfo, Search, Schedule, List, View, Remove

98 | P a g e

Class Name: Connectivity ID: 5 Type: Concrete, Domain

Description: To log in a user Associated Use Case: 1

Responsibilities

Check ID

Check Pass

Collaborators

Teacher, Student, Admin

Teacher, Student, Admin

Attributes: ID (String) Password (String)

Relationships: Generalization: Aggregation: Other: Teacher, Student, Admin

99 | P a g e

Class Name: AddInfo ID: 6 Type: Concrete, Domain

Description: To add info of a course or add a new one. Associated Use Case: 4, 5

Responsibilities

Add Description of Course

Add a new Course

Save

Collaborators

Course

Course, Search

Attributes: Description (String) CourseName (String)

Relationships: Generalization: Aggregation: Other: Course

100 | P a g e

Class Name: Search ID: 7 Type: Concrete, Domain

Description: To search the registered courses. Associated Use Case: 3, 4, 9

Responsibilities

Search a Course

Course Name exists?

Collaborators

Course

Attributes: CourseName (String) Exists (boolean)

Relationships: Generalization: Aggregation: Other: Course

101 | P a g e

Class Name: Schedule ID: 8 Type: Concrete, Domain

Description: A generate schedule manually or automatically Associated Use Case: 6, 7, 10, 11

Responsibilities

Manual Schedule

Automatic Schedule

Is Slot Free?

Edit Auto Schedule

Save

List all courses

Collaborators

Course, Teacher, Search, Semester

Course, Teacher, Search, Semester

Course

Edit

View

List

Attributes: SlotFree (boolean)

Relationships: Generalization: Aggregation: Other: Course, Teacher, Search, Edit, View, List

102 | P a g e

Class Name: List ID: 9 Type: Concrete, Domain

Description: To generate the list of registered courses Associated Use Case: 2, 6, 7, 10

Responsibilities

Search Department

List all Courses

Collaborators

Department

Course

Attributes: DepartmentName (String) Course (String [])

Relationships: Generalization: Aggregation: Other: Department, Course

103 | P a g e

Class Name: View ID: 10 Type: Concrete, Domain

Description: To view the schedule and/or saving it Associated Use Case: 8,11

Responsibilities

Search Semester

Search Teacher

Search Department

View Schedule

Browse Schedule

Save

Collaborators

Semester

Teacher

Department

Attributes: Name (String)

Relationships: Generalization: Aggregation: Other: Semester, Teacher, Department

104 | P a g e

Class Name: Remove ID: 11 Type: Concrete, Domain

Description: To delete a registered course Associated Use Case: 9

Responsibilities

Search Course

Delete

Collaborators

Search

Attributes: CourseName (String)

Relationships: Generalization: Aggregation: Other: Search

105 | P a g e

Class Name: Edit ID: 12 Type: Concrete, Domain

Description: To edit the content or edit auto-schedule Associated Use Case: 4, 10

Responsibilities

Search Course

Edit Content

Edit Auto Schedule

Save

Collaborators

Search

Schedule

Attributes: Content (String)

Relationships: Generalization: Aggregation: Other: Search, Schedule

106 | P a g e

Class Name: Course ID: 13 Type: Concrete, Domain

Description: A Course which is registered. Associated Use Case: 2,3,4,5,6,7,9, 10

Responsibilities

GetInfo

Exists?

Collaborators

Attributes: CourseName (String) DeptName (String) Teacher (String) Time (String) Details (String)

Relationships: Generalization: Aggregation: Other:

107 | P a g e

Class Name: Department ID: 14 Type: Concrete, Domain

Description: A department which is registered. Associated Use Case: 2, 5

Responsibilities

GetInfo

Exists?

Collaborators

Attributes: DeptName (String) Courses (String[]) RoomsAvailable (String[])


108 | P a g e

Class Name: Semester ID: 15 Type: Concrete, Domain

Description: A semester with all the subjects offered. Associated Use Case: 6, 7, 8, 10, 11

Responsibilities

GetInfo

Exists?

Collaborators

Attributes: SemsterName (String) Department (String)


109 | P a g e

13- Role Play Diagrams (RPD)

Scenario 1:

Dr. Saba wants to log-in. She is a teacher. Her ID is Dr. Saba and her password is 123klm.

Scenario 1:

1. Log in Dr. Saba having password: 123klm

Scenario 1:


2. ID ok?

3. ok

theGUI

Connectivity

Teacher ID: Dr. Saba Password: 123klm

theGUI

Connectivity


110 | P a g e

Scenario 1:


4. Pass ok?

5. ok

2. ID ok?

3. ok

Scenario 1:


6. log in

4. Pass ok?

5. ok

2. ID ok?

3. ok

Scenario 1:

7. Done!


6. log in

4. Pass ok? 5. ok 2. ID ok? 3. ok

theGUI

Connectivity


theGUI

Connectivity


theGUI

Connectivity


111 | P a g e

Scenario 2: Dr. Saba wants to view all courses offered by the Computer Science department. The courses offered by the Computer Science department are: A, B, and C.

Scenario 1:

1. List all courses of Computer Science department

Scenario 1:

1. List all courses of Computer Science department 2. DeptName ok? 3. ok

theGUI

List Courses: A, B, C

Department DeptName: Computer Science

theGUI



112 | P a g e

Scenario 1:

1. List all courses of Computer Science department 4. List: A, B, C 2. DeptName ok? 3. ok

Scenario 1:

5. Done!

1. List all courses of Computer Science department 4. List: A, B, C 2. DeptName ok? 3. ok

theGUI



theGUI



113 | P a g e

Scenario 3: Dr. Saba wants to search the Software Engineering II Course and see the details of this course.

Scenario 1:

1. View Course details of Software Engineering II

Scenario 1:

1. View Course details of Software Engineering II 2. Course Name ok? 3. ok

theGUI

Search

Course CourseName: Software Engineering II

theGUI

Search


114 | P a g e

Scenario 1:

1. View Course details of Software Engineering II 4. Display details 2. Course Name ok? 3. ok

Scenario 1:

5. Done!

1. View Course details of Software Engineering II 4. Display details 2. Course name ok? 3. ok

theGUI

Search


theGUI

Search


115 | P a g e

Scenario 4: Dr.Saba wants to change the book name of the Software Engineering II’s course details. We assume that the already prescribed book “Abc” is no longer in need and the new “Xyz” book should be taught to the students.

Scenario 1:

1. Edit Course details of

Software Engineering II; change book name to “Xyz”

Scenario 1:


Software Engineering II; change book name to “Xyz” 2. Search Software Engineering II

theGUI

Search

Course CourseName: Software Engineering II Details: “Abc”

Edit

theGUI

Search


Edit

116 | P a g e

Scenario 1:



3. Software Engineering II exists? 4. Ok

5.Edit “Abc” to “Xyz”

Scenario 1:



3. Software Engineering II exists? 4. Ok

theGUI

Search


Edit

theGUI

Search


Edit

117 | P a g e


Scenario 1:



6. Save 3. Software Engineering II exists? 4. Ok


Scenario 1: 6. Done!



6. Save 3. Software Engineering II exists? 4. Ok

theGUI

Search


Edit

theGUI

Search


Edit

118 | P a g e

Scenario 5: Add “Discrete Structures” to the database.

Scenario 1:

1. Add “Discrete Structures In the database

Scenario 1:


2. Search Discrete Structures Exists?

AddInfo

AddInfo

theGUI

Search

Course CourseName:

theGUI

Search

Course CourseName:

119 | P a g e

Scenario 1:


2. Search Discrete Structures Exists? 3. Discrete Structure exists? 4. No

5. Add description

Scenario 1:


2. Search Discrete Structures Exists? 3. Discrete Structure exists? 4. No

AddInfo

AddInfo theGUI

Search

Course CourseName: No

theGUI

Search


120 | P a g e

5. Add description

Scenario 1:


2. Search 6. Save Discrete Structures Exists? 3. Discrete Structure exists? 4. No

5. Add description 7. Done!

Scenario 1:


2. Search 6. Save Discrete Structures Exists? 3. Discrete Structure exists? 4. No

AddInfo

theGUI

Search


AddInfo

theGUI

Search

Course CourseName: No Yes

121 | P a g e

Scenario 6: The user wants to auto schedule the time table of the 6th semester using “Maths”, “English” and “P-St”; and Miss Itrat, Mis Sadia and Miss Shela as their teachers respectively. 1. Schedule timetable for 6th sem

1. Schedule timetable for 6th sem

2. Semester 6th

theGUI

Schedule

Semester SemName:

Search

Course

Teacher

theGUI

Schedule

Semester SemName:

Search

Course

Teacher

122 | P a g e


3. Search English, P-St, 2. Semester 6th Maths


3. Search English, P-St , 2. Semester 6th Maths

4. En 4. English, Maths, P-St exists?

5. ok

theGUI

Schedule

Semester SemName: 6th

Search

Course

Teacher

theGUI

Schedule


Search

Course

Teacher

123 | P a g e

1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

8. Schedule 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

theGUI

Schedule


Search

Course

Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela

theGUI

Schedule


Search

Course


124 | P a g e

8. Schedule 9. Save 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

10. Done! 8. Schedule 9. Save 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

theGUI

Schedule


Search

Course


theGUI

Schedule


Search

Course


125 | P a g e

Scenario 7: The user wants to schedule manually the time table of the 6th semester using “Maths”, “English” and “P-St”; and Miss Itrat, Mis Sadia and Miss Shela as their teachers respectively. 1. Schedule timetable for 6th sem


2. Semester 6th

theGUI

Schedule

Semester SemName:

Search

Course

Teacher

theGUI

Schedule

Semester SemName:

Search

Course

Teacher

126 | P a g e






5. ok

theGUI

Schedule


Search

Course

Teacher

theGUI

Schedule


Search

Course

Teacher

127 | P a g e



5. ok

8. MSchedule 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

theGUI

Schedule


Search

Course


theGUI

Schedule


Search

Course


128 | P a g e

8. MSchedule 9. Save 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

10. Done! 8. MSchedule 9. Save 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

theGUI

Schedule


Search

Course


theGUI

Schedule


Search

Course


129 | P a g e

Scenario 8: View the schedule of semester 6th. 1. View Schedule of semester 6th

1. View Schedule of semester 6th

2. Show Schedule

3. Done! 1. View Schedule of semester 6th

2. Show Schedule

theGUI

View

Schedule

Semester

theGUI

View

Schedule

Semester Semester: 6th

theGUI

View

Schedule

Semester

130 | P a g e

Scenario 9: Delete “Math” from database. 1. Delete “Math”

1. Delete “Math”

2. Search Math

1. Delete “Math”

2. Search Math 3. Math exists?

4. Yes

theGUI

Remove

Search

Course

theGUI

Remove

Search

Course

theGUI

Remove

Search

Course Course: Math

131 | P a g e

5. Delete 1. Delete “Math”


4. Yes

6. Done! 5. Delete 1. Delete “Math”


4. Yes

theGUI

Remove

Search

Course Course: Math

theGUI

Remove

Search

Course Course: Math

132 | P a g e

Scenario 10: Mr. Habib wants to auto schedule the time table of semester 6th using “Maths”, “English” and “P-St”; and Miss Itrat, Mis Sadia and Miss Shela as their teachers respectively. Then he wants to edit the schedule. 1. Schedule timetable for 6th sem


2. Semester 6th

theGUI

Schedule

Semester SemName:

Search

Course

Teacher

theGUI

Schedule

Semester SemName:

Search

Course

Teacher

133 | P a g e






5. ok

theGUI

Schedule


Search

Course

Teacher

theGUI

Schedule


Search

Course

Teacher

134 | P a g e



5. ok

8. Schedule 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

theGUI

Schedule


Search

Course


theGUI

Schedule


Search

Course


135 | P a g e

8. Schedule 9. Edit 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

8. Schedule 9. Edit 10. Save 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

theGUI

Schedule


Search

Course


theGUI

Schedule


Search

Course


136 | P a g e

11. Done! 8. Schedule 9. Edit 10. Save 1. Schedule timetable for 6th sem 6. Show Teachers 7. Mis Itrat, Mis Sadia, Mis Shela 3. Search English, P-St , 2. Semester 6th Maths


5. ok

Scenario 11: After viewing the time table of semester 6th; Mr. Habib wants to save it on his system. 1. View Schedule of semester 6th

theGUI

Schedule


Search

Course


theGUI

View

Schedule

Semester

137 | P a g e

1. View Schedule of semester 6th

2. Show Schedule

3. save 1. View Schedule of semester 6th

2. Show Schedule

3. save 4. Browse location 1. View Schedule of semester 6th

2. Show Schedule

theGUI

View

Schedule

Semester Semester: 6th

theGUI

View

Schedule

Semester

theGUI

View

Schedule

Semester

138 | P a g e

5. Done! 3. save 4. Browse location 1. View Schedule of semester 6th

2. Show Schedule

theGUI

View

Schedule

Semester

139 | P a g e

14- System Glossary

Term Definition Format Aliases Username An ID given to the user by

the university

Alphanumeric Given by the

university

Password A code assigned to every

user for privacy

Alphanumeric(max 8

characters)

Server Database where all the

information is stored

Course ID An ID given to the course by

the admin

Alphabets

Automatic scheduling Scheduling done by the

system itself by running an

algorithm

Manual scheduling Scheduling done by the user

manualy

Schedule Time table generated for

every semester of each

department

Search bar A toolbar in GUI

Drag and drop menu A kind of GUI due to which a

user can drag and drop

objects with the mouse

Edit A function that is used to

change the already present

content

Save A function which saves the

content in the database

Browse location A function which is used to

locate files in the user‟s

system

140 | P a g e

15- Conceptual Model Concept Category List

Conceptual Class Category Conceptual Class

Physical or tangible objects keyboard

Specifications, deigns or descriptions of

things

SRS

Places University

Transactions Schedule

Transaction line items Courses, Teachers

Roles of people Student, Teacher, Admin

Containers of other things Database

Things in a container Teacher, Student, Admin

Other computer or electro-mechanical

systems external to the system

Comsis

Organizations University

Events AutomaticScheduling

ManualScheduling

EditCourseDescription

SavingSchedule

Rules and policies SchedulingPolicy

Catalogs CourseCatalog

Records of work, contracts, legal matters Comsis, Syllabus

Manuals, documents, reference papers,

books

Syllabus, CourseSpecification

141 | P a g e

Concept Association List:

Category Association between Conceptual Classes

A is a physical part of B Keyboard System

A is a logical part of B Courses Schedule

Teachers Schedule

A is physically contained in/on B System University

A is logically contained in B CourseSpecification Syllabus

A is a description for B CourseSpecification Courses

A is a line item of a transaction or report

B

Courses Schedule

Teacher Schedule

A is known/ logged/

recorded/reported/captured in B

AutomaticScheduling MyCourses

ManualScheduling MyCourses

EditCourseDescription MyCourses

SavingSchedule MyCourses

A is a member of B Teacher University

Student University

Admin University

A is an organization subunit of B Department University

A use or manages B Teacher MyCourses

Student MyCourses

Admin MyCourse

A communicates with B Teacher Student

Admin Teacher

A is related to a transaction B Admin Schedule

142 | P a g e

A is a transaction related to another

transaction B

AutomaticSchedule ManualSchedule

A is next to B MyCourses MyCourses

A is owned by B MyCourses University

143 | P a g e

16- System Operations 1- log-in

2- Listing the courses

3- Edit Course Description

4- Adding a new Course

5- Auto-Scheduling

System1

login()

System2

search() action()

System3

action() edit() editContent() save()

System4

search() event() create() new()

System5

event() semester() enterC() enterT()

144 | P a g e

6- Manual Scheduling

7- View Schedule

8- Deleting a Course

9- Edit Auto-Scheduling

10- Saving the schedule

System6

event() semester() enterC() enterT() DragNDrop()

System7

event() search() semester()

System8

searchCourse() event()

System9

event() semester() enterC() enterT() DragNDrop()

System10

event() search() semester() browse()

145 | P a g e

17- Operation Contracts

Name: login (username : String, password : String)

Number: 1

Responsibilities: Checks that the entered username and password are correct; if they are

correct then successfully login the user to the system otherwise display an

error message.

Type: System

Cross

References:

SSD: sd log-in Use-Case: 1

Notes: Uses database

Exceptions: If username and/or password is not valid indicate error

Output: The user is successfully logged in

Pre-conditions: Username and password are known to the system

Post-

Conditions:

- If a teacher logged in; a new Teacher is created (instance created)

- If a student logged in; a new Student is created (instance created)

- If an admin logged in; a new Admin is created (instance created)

Name: Search (deptName : String)

Number: 2

Responsibilities: Checks that the entered department name exists in the database or not and if

it does opens up that department page

Type: System

Cross

References:

SSD: sd listing the courses, sd adding a new Course , sd saving the schedule

Use-Case: 2,4, 10


Exceptions: If department name does not exist indicate error

Output: The department‟s page opens up

Pre-conditions: Department name is known to the system

Post-

Conditions:

- Department is created (instance created)

- Courses is created (instance created)

- Teacher is created (instance created)

- Department is associated with Courses (association)

- Department is associated with Teachers (association)

Name: Event (ActionName : String)

Number: 3

Responsibilities: Does appropriate function with reference to „ActionName‟

Type: System

Cross References: SSD: sd listing the courses, sd edit course description, sd adding a new

Course , sd auto scheduling, manual scheduling, sd view schedule, sd

deleting a course, sd edit auto scheduling, sd saving the schedule

Use-Case: 2, 3, 4, 5, 6, 7, 8, 9, 10

Notes: Has many function

146 | P a g e

Exceptions: If the action cannot be performed indicate error

Output: The action is done and returns true

Pre-conditions: ActionName is known to the system

Post-Conditions: - actionPerformed is set to true (attribute modification)

Name: Edit (courseID : String)

Number: 4

Responsibilities: Determines which course description is to be edited

Type: System

Cross

References:

SSD: sd edit course description Use-Case: 3


Exceptions: If courseID does not exist indicate error

Output: Ready to edit

Pre-conditions: courseID is known to the system

Post-

Conditions:


- Courses is associated with CourseSpecification (association)

- CourseSpecification is created (Instance created)

Name: EditContent (content : String)

Number: 5

Responsibilities: Performs edit functionality.

Type: System

Cross

References:



Exceptions: If content is null indicate error

Output: The edit functionality is achieved

Pre-conditions: courseID is known to the system

Post-

Conditions:




- CourseSpecification.description is changed (attribute modification)

Name: Save ()

Number: 6

Responsibilities: Saves the content in the database

Type: System

Cross

References:



Exceptions: If content cannot be saved indicate an error

147 | P a g e

Output: Content is saved and returns true if done

Pre-conditions:

Post-

Conditions:

- Saved variable is set to true (attribute modification)

Name: Create (CName : String; CID : String)

Number: 7

Responsibilities: Adds a new Course with name: CName and ID: CID

Type: System

Cross

References:

SSD: sd adding a new course Use-Case: 4


Exceptions: If CName and/or CID exists indicate an error

Output: A new course is created and added in database and returns true if done

Pre-conditions: CName and CID are new to the system

Post-

Conditions:





- Schedule is created (instance created)

- Courses is associated with Department (association)

- Courses is associated with Schedule (association)

- Set Done variable to true (attribute modification)

Name: New (courseContent : String)

Number: 8

Responsibilities: Adds Course content to the newly created course

Type: System

Cross

References:

SSD: sd adding a new course Use-Case: 4


Exceptions: If courseContent is null; indicate an error

Output: The new course is saved with its course content and saved

Pre-conditions: CName and CID are created

Post-

Conditions:








- Content variable is modified( attribute modification)

148 | P a g e

Name: Semester (SemesterName : String)

Number: 9

Responsibilities: Search if the entered semester is correct or not

Type: System

Cross

References:

SSD: sd auto-scheduling, sd view schedule, sd edit auto scheduling, sd saving the

schedule Use-Case: 5, 7, 9, 10


Exceptions: If semsterName doesn‟t exist; indicate an error

Output: Returns true if semester exists

Pre-conditions: SemesterName should be known to the system

Post-

Conditions:

- Done variable is set to true (attribute modification)

Name: EnterC (AllCourses : String[])

Number: 10

Responsibilities: Checks if the entered lists of courses exists or not

Type: System

Cross

References:

SSD: sd auto-scheduling, sd manual scheduling, sd edit auto scheduling Use-

Case: 5, 6, 9


Exceptions: If any course doesn‟t exist; indicate an error

Output: Returns true if all the courses exists

Pre-conditions: All the courses should be known to the system

Post-

Conditions:

- Schedule is created (Instance created)

- If automatic scheduling; auto_schedule is created (instance created)

- If manual scheduling; manual_scheduling is created (instance created)

- Schedule_Desc is created (instance created)

- Schedule is associated with Schedule_Desc (association)


Name: EnterT (AllTeachers : String[])

Number: 11

Responsibilities: Checks if the entered lists of teachers exists or not

Type: System

Cross

References:

SSD: sd auto-scheduling, sd manual scheduling, sd edit auto scheduling Use-

Case: 5,6, 9


Exceptions: If any teacher name doesn‟t exist; indicate an error

Output: Returns true if all the teacher name exists

Pre-conditions: All the teacher names should be known to the system

Post-

Conditions:





149 | P a g e



Name: DragNDrop (Courses : String[])

Number: 12

Responsibilities: Changes the behavior of course to drag-and-drop

Type: System

Cross

References:

SSD: sd manual-scheduling, sd edit auto scheduling Use-Case: 6, 9

Notes: Change the behavior of courses selected

Exceptions: If any courses can not be placed at a place; indicate an error

Output: Returns true if the placing of course is possible

Pre-conditions: Atleast one course must be selected

Post-

Conditions:






- Done is set to true if done (attribute is modified)

Name: SearchCourse (CourseName : String)

Number: 13

Responsibilities: Checks if the course exists or not

Type: System

Cross

References:

SSD: sd deleting a course Use-Case: 8


Exceptions: If course name does not exist indicate error

Output: Returns true if it exists

Pre-conditions: Course name is known to the system

Post-

Conditions:


- CourseSpecification is created (instance created)






150 | P a g e

Name: Browse (location : String)

Number: 14

Responsibilities: Checks if location exists or not

Type: System

Cross

References:

SSD: sd deleting a course, sd saving the schedule Use-Case: 8, 10

Notes: Uses user‟s system

Exceptions: If it can not be saved; indicate an error

Output: Returns true if location is ok and it can be saved in that location

Pre-conditions: Location must exist

Post-

Conditions:

- SaveSch is created (instance created)

- SaveSch is associated with ViewSch (association)

- ViewSch is created (instance created)

151 | P a g e

18- System Sequence Diagrams:

152 | P a g e

153 | P a g e

154 | P a g e

155 | P a g e

156 | P a g e

19- UML Diagrams

1- Class Diagram

157 | P a g e

2- Component Diagram

158 | P a g e

3- Deployment Diagram

159 | P a g e

4- Package Diagram

160 | P a g e

5- Activity Diagram

Listing the courses:

Edit Course Content:

161 | P a g e

Adding New Course:

Schedule:

162 | P a g e

Deleting a Course:

163 | P a g e

6- Sequence Diagram

Add Course:

Auto-Schedule:

164 | P a g e

Manual Scheduling:

View Schedule:

165 | P a g e

20- Appendixes

Glossary

Term Definition Username An ID given to the user by the university

Password A code assigned to every user for privacy

Server Database where all the information is stored

Course ID An ID given to the course by the admin

Automatic scheduling Scheduling done by the system itself by running an algorithm

Manual scheduling Scheduling done by the user manualy

Schedule Time table generated for every semester of each department

Search bar A toolbar in GUI

Drag and drop menu A kind of GUI due to which a user can drag and drop objects

with the mouse

Edit A function that is used to change the already present content

Save A function which saves the content in the database

Browse location A function which is used to locate files in the user‟s system

Documents

MyCourses a UML Docoment With Usecase and Class Diagrams