Upload
muhammad-mubasher
View
59
Download
4
Embed Size (px)
Citation preview
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.
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:
Actor Action System Response
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.
4.2.3- Functional Requirements:
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
Actor Action System Response
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.
4.3.3- Functional Requirements:
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:
Actor Action System Response
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
4.4.3- Functional Requirements:
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
Asma Kaleem 4 9th May, 2011 13th May, 2011
20 | P a g e
Interaction
Diagrams
Fareeha Amjad
Asma Kaleem 3 13th May, 2011 16th May, 2011
Development Fareeha Amjad
Asma Kaleem 4 16th May, 2011 20th May, 2011
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
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.
37 | P a g e
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
CANCEL.
Confirms if it must be
canceled.(no change)
Edit_
Description
Test Case: Enter description of the course, T3
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
38 | P a g e
{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 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:
{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) 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:
{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) 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:
{username} username must be unique and valid
{password} password must be valid
{departmentName} must be unique name for each department
Step
Number
Step Description Expected Result Transaction
Name
User
Think
Time
40 | P a g e
1) Enter the website’s URL and
press enter. And log-in with
{username} and {password}.
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:
{username} username must be unique and valid
{password} password must be valid
{departmentName} must be unique name for each department
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) 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
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:
{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) Choose the department from
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:
{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
42 | P a g e
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) Choose the department from
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:
{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 “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
Test Case: Auto-Scheduling, T11
Description: The user wants to schedule automatically; the system generates an automatic schedule.
Data Requirements:
{username} username must be unique and valid
{password} password must be valid
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 “Auto Schedule’ Page opens that asks for
the semester
Semester_
identification
3) Enter the semester and
department along with the
courses(drop down menu)
offered for that semester
Page opens to choose
teachers (if multiple
teachers are available
for a particular course)
Assign_courses
4) Click Schedule. Conforms the schedule Auto_Schedule
5) Click Cancel Returns to the previous
page
Assign_courses
Test Case: Auto-Scheduling, T12
Description: The user wants to schedule automatically; the system generates an automatic schedule.
Data Requirements:
{username} username must be unique and valid
44 | P a g e
{password} password must be valid
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 “Auto Schedule’ Page opens that asks for
the semester
Semester_
identification
3) Enter the semester and
department along with the
courses(drop down menu)
offered for that semester
Page opens to choose
teachers (if multiple
teachers are available
for a particular course)
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:
{username} username must be unique and valid
{password} password must be valid
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 “Manual Schedule’ Page opens that asks for
the semester
Semester_
identification
3) Enter the semester and
department along with the
Page opens to choose
teachers (if multiple
Assign_courses
45 | P a g e
courses(drop down menu)
offered for that semester
teachers are available
for a particular course)
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
Test Case: Manual-Scheduling, T14
Description: The user wants to schedule manually.
Data Requirements:
{username} username must be unique and valid
{password} password must be valid
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 “Manual Schedule’ Page opens that asks
for the semester
Semester_
identification
3) Enter the semester and
department along with the
courses(drop down menu)
offered for that semester
Page opens to choose
teachers (if multiple
teachers are available
for a particular course)
Assign_courses
4) Drag the course and drop it
in the table at the wrong
place.
Shows up a warning and
does not save the move
Manual_Schedule
Test Case: Manual-Scheduling, T15
46 | P a g e
Description: The user wants to schedule manually.
Data Requirements:
{username} username must be unique and valid
{password} password must be valid
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 “Manual Schedule’ Page opens that asks
for the semester
Semester_
identification
3) Enter the semester and
department along with the
courses(drop down menu)
offered for that semester
Page opens to choose
teachers (if multiple
teachers are available
for a particular course)
Assign_courses
4) Drag the course and drop it
in the table at the place that
creates a clash
Shows up a warning and
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:
{username} username must be unique and valid
{password} password must be valid
Step
Number
Step Description Expected Result Transaction
Name
User
Think
Time
47 | P a g e
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 “Auto Schedule’ Page opens that asks for
the semester
Semester_
identification
3) Enter the semester and
department along with the
courses offered for that
semester
Page opens to choose
teachers (if multiple
teachers are available
for a particular course)
Assign_course
4) Click Schedule. Conforms the schedule Auto_Schedule
5) Click edit and move courses
manually.
Confirms the move. Edit_Schedule
Test Case: Edit Auto-Scheduling, T17
Description: The user wants to schedule automatically; the system generates an automatic schedule but
edits it and schedule manually.
Data Requirements:
{username} username must be unique and valid
{password} password must be valid
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 “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
48 | P a g e
semester for a particular course)
4) Click Schedule. Conforms the schedule Auto_Schedule
5) Click edit and move courses
at a wrong place.
Shows up a warning and
does not save the move.
Edit_Schedule
Test Case: Edit Auto-Scheduling, T18
Description: The user wants to schedule automatically; the system generates an automatic schedule but
edits it and schedule manually.
Data Requirements:
{username} username must be unique and valid
{password} password must be valid
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 “Auto Schedule’ Page opens that asks for
the semester
Semester_
identification
3) Enter the semester and
department along with the
courses offered for that
semester
Page opens to choose
teachers (if multiple
teachers are available
for a particular course)
Assign_course
4) Click Schedule. Conforms the schedule Auto_Schedule
5) Click edit and move courses
at a place that creates a
clash.
Shows up a warning and
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:
{username} username must be unique and valid
{password} password must be valid
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 “Show Table’ Page opens that asks for
the semester and
department.
Semester_
identification
3) Enter the semester and
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:
{username} username must be unique and valid
{password} password must be valid
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
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:
{username} username must be unique and valid
{password} password must be valid
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 “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:
{username} username must be unique and valid
{password} password must be valid
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 “Show Table’ Page opens that asks for
the semester and
department.
Semester_
identification
3) Enter the semester and
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:
{username} username must be unique and valid
{password} password must be valid
Step
Number Step Description Expected Result
Transaction
Name
User
Think
Time
1) Enter the website’s URL and
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
Test Case: Log-in, T25
Description: The user will log-in to his/her account to go to the main menu.
Data Requirements:
{username} username must be unique and valid
{password} password must be valid
Step
Number Step Description Expected Result
Transaction
Name
User
Think
Time
1) Enter the website’s URL and
press enter
Page is displayed asking
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
Test Case: Log-in, T26
Description: The user will log-in to his/her account to go to the main menu.
Data Requirements:
53 | P a g e
{username} username must be unique and valid
{password} password must be valid
Step
Number Step Description Expected Result
Transaction
Name
User
Think
Time
1) Enter the website’s URL and
press enter
Page is displayed asking
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
57 | P a g e
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
61 | P a g e
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
65 | P a g e
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
69 | P a g e
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
Test Stage: Unit Functionality Integration System
73 | P a g e
Interface
Performance Regression Acceptance Pilot
Specify the testing stage for this Test Summary Report.
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
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 as well as the semester
Must
R2.2 List the courses using department name
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 as well as the department
Must
RQ.3 Search a course 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
R3.1 Search a course using course name
Evident Response Time
System should be able to process the results timely
Must
82 | P a g e
Fault Tolerant
The user should be logged in to use the functionality
Must
R3.2 Search a course using a course ID
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
RQ.4 Edit the details of the course Evident Fault Tolerant
The user should be logged in to use the functionality
Must
Interface Metaphor
The edit window should open up separately
Must
RQ.5 Add a new course Evident Fault Tolerant
The user should be logged in to use the functionality
Must
RQ.6 Schedule automatically 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
RQ.7 Schedule manually Evident Fault Tolerant
The user should be logged in to use the functionality
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
The user should be logged in to use the functionality
Must
Interface Metaphor
Colorful Want
RQ.9 Show the details of a course Evident Fault Tolerant
The user should be logged in to use the functionality
Must
Response Time
System should be able to process the results timely
Must
RQ.10 Edit auto- scheduling Evident Fault Tolerant
The user should be logged in to use the functionality
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
System should be able to process the results timely
Must
RQ.12 Delete Course Evident Fault Tolerant
The user should be logged in to use the functionality
Must
Response Time
System should be able to process the results timely
Must
RQ.13 Provide a persistent storage mechanism
Hidden Fault Tolerant
The user should be logged in to use the functionality
Must
RQ.14 Detect Errors Hidden Fault Tolerant
The user should be logged in to use the functionality
Must
Response Time
System should be able to process the results timely
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
system asks to enter courses. The user enters all the courses for that semester. The system
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
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. 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
Actor Action System Response
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
PRIMARY ACTOR Any Authenticated User.
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.
Type Primary and real
Cross Reference RQ.2, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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
PRIMARY ACTOR Any Authenticated User.
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.
Type Primary and real
Cross Reference Functions: RQ.4, RQ.13, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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
PRIMARY ACTOR Any Authenticated User.
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.
Type Primary and real
88 | P a g e
Cross Reference Functions: RQ.5, RQ.13, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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
PRIMARY ACTOR Any Authenticated User.
Purpose To schedule the time table automatically.
Overview When the user wants to schedule automatically; the system
generates an automatic schedule.
Type Primary and real
Cross Reference Functions: RQ.6, RQ.13, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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
PRIMARY ACTOR Any Authenticated User.
Purpose To schedule the time table manually.
Overview When the user wants to schedule manually; the system
generates saves the schedule.
Type Primary and real
Cross Reference Functions: RQ.7, RQ.13, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
Step 1:
The user clicks on manual scheduling tab.
Step 3:
The user enters the semester for which
he/she wants to schedule.
Step 5:
The user enters all the courses for that
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:
The system asks to enter the semester.
Step 4:
The system asks to enter courses.
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
PRIMARY ACTOR Any Authenticated User.
Purpose To show the time table
Overview When the user wants to present the schedule; the system
presents it.
Type Primary and real
Cross Reference Functions: RQ.8, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
Step 1:
The user clicks on “Show Table”.
Step 3:
The user enters the semester.
Step 2:
The system asks to enter the semester.
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
PRIMARY ACTOR Any Authenticated User.
Purpose To delete a specific course
Overview When the user wants delete a course already present in the
database.
Type Primary and real
Cross Reference Functions: RQ.12, RQ.13, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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
PRIMARY ACTOR Any Authenticated User.
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.
Type Primary and real
Cross Reference Functions: RQ.10, RQ.13, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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:
The user enters all the courses for that
semester.
Step 7:
The user picks the teachers.
Step 9:
Step 2:
The system asks to enter the semester.
Step 4:
The system asks to enter courses.
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
PRIMARY ACTOR Any Authenticated User.
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.
Type Primary and real
Cross Reference Functions: RQ.11, RQ.14
NORMAL COURSE OF EVENTS
Actor Action System Response
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[])
Relationships: Generalization: Aggregation: Other:
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)
Relationships: Generalization: Aggregation: Other:
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:
1. Log in Dr. Saba having password: 123klm
2. ID ok?
3. ok
theGUI
Connectivity
Teacher ID: Dr. Saba Password: 123klm
theGUI
Connectivity
Teacher ID: Dr. Saba Password: 123klm
110 | P a g e
Scenario 1:
1. Log in Dr. Saba having password: 123klm
4. Pass ok?
5. ok
2. ID ok?
3. ok
Scenario 1:
1. Log in Dr. Saba having password: 123klm
6. log in
4. Pass ok?
5. ok
2. ID ok?
3. ok
Scenario 1:
7. Done!
1. Log in Dr. Saba having password: 123klm
6. log in
4. Pass ok? 5. ok 2. ID ok? 3. ok
theGUI
Connectivity
Teacher ID: Dr. Saba Password: 123klm
theGUI
Connectivity
Teacher ID: Dr. Saba Password: 123klm
theGUI
Connectivity
Teacher ID: Dr. Saba Password: 123klm
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
List Courses: A, B, C
Department DeptName: Computer Science
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
List Courses: A, B, C
Department DeptName: Computer Science
theGUI
List Courses: A, B, C
Department DeptName: Computer Science
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
Course CourseName: Software Engineering II
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
Course CourseName: Software Engineering II
theGUI
Search
Course CourseName: Software Engineering II
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:
1. Edit Course details of
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
Course CourseName: Software Engineering II Details: “Abc”
Edit
116 | P a g e
Scenario 1:
1. Edit Course details of
Software Engineering II; change book name to “Xyz” 2. Search Software Engineering II
3. Software Engineering II exists? 4. Ok
5.Edit “Abc” to “Xyz”
Scenario 1:
1. Edit Course details of
Software Engineering II; change book name to “Xyz” 2. Search Software Engineering II
3. Software Engineering II exists? 4. Ok
theGUI
Search
Course CourseName: Software Engineering II Details: “Abc”
Edit
theGUI
Search
Course CourseName: Software Engineering II Details: “Abc”
Edit
117 | P a g e
5.Edit “Abc” to “Xyz”
Scenario 1:
1. Edit Course details of
Software Engineering II; change book name to “Xyz” 2. Search Software Engineering II
6. Save 3. Software Engineering II exists? 4. Ok
5.Edit “Abc” to “Xyz”
Scenario 1: 6. Done!
1. Edit Course details of
Software Engineering II; change book name to “Xyz” 2. Search Software Engineering II
6. Save 3. Software Engineering II exists? 4. Ok
theGUI
Search
Course CourseName: Software Engineering II Details: “Abc”
Edit
theGUI
Search
Course CourseName: Software Engineering II Details: “Abc”
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:
1. Add “Discrete Structures In the database
2. Search Discrete Structures Exists?
AddInfo
AddInfo
theGUI
Search
Course CourseName:
theGUI
Search
Course CourseName:
119 | P a g e
Scenario 1:
1. Add “Discrete Structures In the database
2. Search Discrete Structures Exists? 3. Discrete Structure exists? 4. No
5. Add description
Scenario 1:
1. Add “Discrete Structures In the database
2. Search Discrete Structures Exists? 3. Discrete Structure exists? 4. No
AddInfo
AddInfo theGUI
Search
Course CourseName: No
theGUI
Search
Course CourseName: No
120 | P a g e
5. Add description
Scenario 1:
1. Add “Discrete Structures In the database
2. Search 6. Save Discrete Structures Exists? 3. Discrete Structure exists? 4. No
5. Add description 7. Done!
Scenario 1:
1. Add “Discrete Structures In the database
2. Search 6. Save Discrete Structures Exists? 3. Discrete Structure exists? 4. No
AddInfo
theGUI
Search
Course CourseName: No
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
1. Schedule timetable for 6th sem
3. Search English, P-St, 2. Semester 6th Maths
1. Schedule timetable for 6th sem
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
Semester SemName: 6th
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
4. En 4. English, Maths, P-St exists?
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
4. En 4. English, Maths, P-St exists?
5. ok
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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
4. En 4. English, Maths, P-St exists?
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
4. En 4. English, Maths, P-St exists?
5. ok
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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
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
1. Schedule timetable for 6th sem
3. Search English, P-St, 2. Semester 6th Maths
1. Schedule timetable for 6th sem
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
Semester SemName: 6th
Search
Course
Teacher
127 | 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
4. En 4. English, Maths, P-St exists?
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
4. En 4. English, Maths, P-St exists?
5. ok
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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
4. En 4. English, Maths, P-St exists?
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
4. En 4. English, Maths, P-St exists?
5. ok
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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”
2. Search Math 3. Math exists?
4. Yes
6. Done! 5. Delete 1. Delete “Math”
2. Search Math 3. Math exists?
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
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
1. Schedule timetable for 6th sem
3. Search English, P-St, 2. Semester 6th Maths
1. Schedule timetable for 6th sem
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
Semester SemName: 6th
Search
Course
Teacher
134 | 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
4. En 4. English, Maths, P-St exists?
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
4. En 4. English, Maths, P-St exists?
5. ok
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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
4. En 4. English, Maths, P-St exists?
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
4. En 4. English, Maths, P-St exists?
5. ok
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
theGUI
Schedule
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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
4. En 4. English, Maths, P-St exists?
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
Semester SemName: 6th
Search
Course
Teacher Teachers: Miss Itrat, Mis Sadia and Miss Shela
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
Notes: Uses database
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
Notes: Uses database
Exceptions: If courseID does not exist indicate error
Output: Ready to edit
Pre-conditions: courseID is known to the system
Post-
Conditions:
- Courses is created (instance created)
- 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:
SSD: sd edit course description Use-Case: 3
Notes: Uses database
Exceptions: If content is null indicate error
Output: The edit functionality is achieved
Pre-conditions: courseID is known to the system
Post-
Conditions:
- Courses is created (instance created)
- Courses is associated with CourseSpecification (association)
- CourseSpecification is created (Instance created)
- CourseSpecification.description is changed (attribute modification)
Name: Save ()
Number: 6
Responsibilities: Saves the content in the database
Type: System
Cross
References:
SSD: sd edit course description Use-Case: 3
Notes: Uses database
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
Notes: Uses database
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:
- Courses is created (instance created)
- Courses is associated with CourseSpecification (association)
- CourseSpecification is created (Instance created)
- Department is created (instance created)
- 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
Notes: Uses database
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:
- Courses is created (instance created)
- Courses is associated with CourseSpecification (association)
- CourseSpecification is created (Instance created)
- Department is created (instance created)
- Courses is associated with Department (association)
- Schedule is created (instance created)
- Courses is associated with Schedule (association)
- 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
Notes: Uses database
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
Notes: Uses database
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)
- Done variable is set to true (attribute modification)
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
Notes: Uses database
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:
- 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)
149 | P a g e
- Schedule is associated with Schedule_Desc (association)
- Done variable is set to true (attribute modification)
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:
- 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)
- 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
Notes: Uses database
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:
- Courses is created (instance created)
- CourseSpecification is created (instance created)
- Schedule is created (instance created)
- Department is created (instance created)
- Courses is associated with CourseSpecification (association)
- Courses is associated with Schedule (association)
- Courses is associated with Department (association)
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