COMSATS University Islamabad,

COMSATS Road, off GT Road, Sahiwal, Pakistan

SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS DOCUMENT)

For

CUI Timetable (iOS)

Version 1.0
by

Muhammad Bilal CIIT/FA19-BSE-001/SWL

Ahmad Tariq CIIT/FA19-BSE-003/SWL
Syed M. Nawaz Shah CIIT/FA19-BSE-040/SWL

Supervisor
Mr. Muhammad Umar

Bachelor of Science in Computer Science (2019-2023)

Table of Contents
1. Introduction
1.1 Purpose........................................................................................................................................1
1.2 Scope...........................................................................................................................................1
2. Overall description
2.1 Product perspective......................................................................................................................1
2.2 Operating environment................................................................................................................1
2.3 Design and implementation constraints.......................................................................................1
3. Requirement identifying technique
3.1 Use case 1....................................................................................................................................2
3.1.1 Use case 1 description...........................................................................................................2
3.2 Use case 2....................................................................................................................................3
3.2.1 Use Case 2 Description.........................................................................................................3
3.3 Use case 3....................................................................................................................................4
3.3.1 Use Case Description 3.........................................................................................................4
4. Requirements
4.1 Functional requirements..............................................................................................................5
4.1.1 Student Module.....................................................................................................................5
4.1.2 Teacher Module....................................................................................................................5
4.1.3 Admin Module......................................................................................................................6
5. Non-functional requirements
5.1 Usability......................................................................................................................................7
5.2 Performance.................................................................................................................................7
5.3 Responsiveness............................................................................................................................7
5.4 Accessibility................................................................................................................................7
6. Project Gantt chart
References

i
List of Tables
Table 1 Use case description for searching timetable............................................................................2
Table 2 Use case description for booking room for makeup..................................................................3
Table 3 Use case description for set reminder.......................................................................................4
Table 4 Student FR................................................................................................................................6
Table 5 Teacher FR...............................................................................................................................6
Table 6 Admin FR.................................................................................................................................6

ii
List of Figures
Figure 1 Use Case Search Timetable.....................................................................................................2
Figure 2 Use Case Book Free Room......................................................................................................3
Figure 3 Use Case Set Reminder...........................................................................................................4
Figure 4 Gantt chart...............................................................................................................................7

iii
 Revision History
Name Date Reason for changes Version

iv
 Application Evaluation History
Comments (by committee) Presentation

Supervised by

Mr. Muhammad Umar

Signature______________

v
1. Introduction
The purpose of this document is to present a detailed description of the CUI Timetable iOS
Application. It will explain the purpose and features of the application, what the system will
do, the constraints under which it must operate, and what the functional and non-functional
requirements of the system are. This document is intended for both the stakeholders and the
developers of the system.

1.1 Purpose
CUI Timetable iOS application will provide a facility to the students and teachers of Comsat
University Sahiwal. It will provide an updated timetable, date sheet, and free room
information in some clicks. User doesn’t need to search their routine manually. Students can
find their timetable, date sheet with their section name and teacher can also find their
timetable and date sheet duty with their name. The user can see the latest news on their phone
easily. User see the latest news on screen every time. The timetable and date sheet will be
updated by the admin if any change occurs. It will also provide a booking module for
arranging makeup classes.

1.2 Scope
This application will simplify the management timetable distribution process and also
provides other facilities that will help the students and teachers to simplify their work.
Students will get benefits by searching their routine timetable, and exam timetable, getting
reminders and seeing the latest news. Besides, teachers will also get benefits by searching
their routine lectures, and exam duties, getting reminders, seeing the latest news, and will also
be able to reserve free rooms for makeup classes. This application will help them to reduce
their time cost and provide an effective way to see their information using their mobile
devices.

2. Overall description
2.1 Product perspective
This product has been initiated to develop a new timetable application for iOS users that are
designed for Comsat university students to update their timetable, datasheet, and free room
information. Students and teachers will see their timetable, datasheets, and free room
information. And, admin will update the timetable files. The beneficiaries of this product will
be Comsat Sahiwal alumni and admin. [1]

2.2 Operating environment

The primary stakeholders in this project are students and teachers of the CUI Sahiwal. The
proposed system will work on the iOS platform. This system requires normal OS and
hardware specifications. It does not require an expensive or very advance hardware. This app
shall operate with a minimum iPhone 7 to run.

2.3 Design and implementation constraints

This application is targeting the iOS users of our university so, this system will be accessible
only to all the iOS users of our campus at its release. Teachers and students will be able to see
their respective functionalities but few functionalities will be hidden from students and
teachers. Admin will have their view in which they will update the timetable files. Most of
the functionalities are accessible after authentication. University email will be used in the
authentication process. [1]

vi
3. Requirement identifying technique
3.1 Use case 1

Figure 1 Use Case Search Timetable

3.1.1 Use case 1 description

The table below indicates a comprehensive use case template filled in with an example drawn
from use case 1 [2].
Table 1 Use case description for searching timetable

Use Case ID: CUIT-1

Use Case Name: Searching timetable
Actors: Student, teacher
A user searches for the timetable by entering a section or teacher
name. Then this will be matched with the database and if any match
Description:
is found then it will be displayed but if the user makes a wrong entry
then it will show a respective error.
A user selects the timetable module and then selects the student or
Trigger:
teacher tab.
PRE-1. The user has opened the app and selected the timetable
Preconditions: module from the home page.
PRE-2. The section or teacher field is not empty
POST-1. The user will go back to the main page.
Post conditions:
POST-2. The user will not enter the section name or teacher name.
The user opens the app then opens the timetable module and then
Normal Flow: searches for the section or teacher name. The relative information is
provided to the user and then the user can select the day.
Alternative Flows: The history of each section searched by the users will be kept so, they
can directly go to the searched sections by opening the app, going to
the timetable module, and then opening the history tab and clicking

vii
 on any one of the searches.
Users enter the wrong section or teacher name and tap the find now
Exceptions:
button.
The user has the necessary operating environment specifications, and
Assumptions:
he/she knows the basis and flow of using the app.

3.2 Use case 2

Figure 2 Use Case Book Free Room

3.2.1 Use Case 2 Description

The table below indicates a comprehensive use case template filled in with an example drawn
from the use case 2. [2]
Table 2 Use case description for booking room for makeup

Use Case ID: CUIT-2

Use Case Name: Booking room for a makeup
Actors: Teacher
The first teacher must sign in and then open the booking module
from the home page then the user will select a time slot and day on
which he/she wants to arrange a makeup class and he will also enter
Description:
the section name. Then according to the given date, time, and section
name, free rooms will be shown to the user from which he/she can
select the room and then confirm the booking.
Trigger: The teacher selects the booking module and selects the date and time
Post conditions: POST-1. The user will go back to the main page.
POST-2. The user will not select a date and time slot.
POST-3. The user will cancel the booking

viii
 POST-4. Users may sign out
The user will sign in and then go to the booking module where he/she
will enter the section name, day, and time slot. Then from the list of
Normal Flow:
free rooms on that day and slot, he/she will select any room and then
confirm the booking.

Users may enter a section name that he/she is not currently teaching
Alternative Flows: and if there is no record found about that section against the user then
it will give an error.
More than one users make an appointment at the same time and day
Exceptions:
with the same section.
The user has the necessary operating environment specifications, and
Assumptions:
he/she knows the basis and flow of using the app.

3.3 Use case 3

Figure 3 Use Case Set Reminder

3.3.1 Use Case Description 3

The table below indicates a comprehensive use case template filled in with an example drawn
from the use case 3. [2]
Table 3 Use case description for set reminder

Use Case ID: CUIT-3

Use Case Name: Setting reminder
Actors: Teacher, Student

ix
 A user opens the reminder module and then selects the tab student or
teacher. The user enters the section name or teacher name then all the
Description: related courses to that section or teacher will be displayed and the
user can set a reminder for only one or more courses at a time or can
set it for all.
The user opens the reminder module and searches for the
Trigger:
section/teacher
PRE-1. The user has opened the app and selected the reminder
Preconditions: module from the home page.
PRE-2. The user has entered the section/teacher name
POST-1. The user will go back to the main page.
Post conditions:
POST-2. The user will not enter a valid section or teacher name.
The user will sign in and then go to the booking module where he/she
will enter the section name, day, and time slot. Then from the list of
Normal Flow:
free rooms on that day and slot, he/she will select any room and then
confirm the booking.
Users may enter a section name that he/she is not currently teaching
Alternative Flows: and if there is no record found about that section against the user then
it will give an error.
More than one users make an appointment at the same time and day
Exceptions:
with the same section.
The user has the necessary operating environment specifications, and
Assumptions:
he/she knows the basis and flow of using the app.

4. Requirements
4.1 Functional requirements
This system will have the following modules:
● Module 1: Student module
● Module 2: Teacher module
● Module 2: Admin module
All modules will work in the application.

4.1.1 Student Module

1. Student search their section
2. Student search for free rooms
3. Student search for their date sheet
4. Students set a reminder for lectures
5. Students see the latest news
6. Student creates a new account
7. Student sign in
8. Student signup
4.1.2 Teacher Module
1. Teachers search their section
2. Teacher search for free rooms.
3. Teacher search for their exam duties.
4. Teachers set a reminder for their lectures
5. Teachers see the latest news

x
 6. Teacher sign in
7. Teacher signup
4.1.3 Admin Module
1. Admin uploads the timetable file
2. Admin uploads the date sheet file
3. Admin uploads the file of the free room.
4. Admin sees the booking logs of every teacher
5. Admin reply the reported issues/feedback

Table 4 Student FR

Identifier Student
Title Student Routine
Requirement Student must put their correct section to see their routine.
Rationale The algorithm works with the section name.
Dependencies The routine depends on the teacher's name
Priority High

Table 5 Teacher FR

Identifier Teacher
Title Teacher routine
Requirement The teacher must put their correct name to see their routine.
Rationale The algorithm works with the teacher's name.
Dependencies The routine depends on the teacher's name
Priority High

Table 6 Admin FR

Identifier Admin
Title Database Control
Requirement Admin must do any type of changes in the database and backend.
The admin will change the database and, the system if the system
Rationale shows any type of error.
Dependencies There is no dependency.
Priority High

5. Non-functional requirements
This section of the SRS describes the non-functional requirements for the software system.
Usability, Performance, Responsiveness, and accessibility requirements are included.

xi
5.1 Usability
The app User Interface is easy to use and users can easily access all the modules. The app
will reduce the time cost of users by making it easy to view the timetable, date sheet, etc.
without going through the CSV file which is quite complex to understand for new students.
Also, management time costs will be reduced as they only have to upload/update the files of
the timetable and they don’t have to distribute it in the form of a CSV file.

5.2 Performance
This app must provide updated data to teachers and students. The response to the requests
should be minimized using best practices. All other performances related to storage, memory,
and processing should follow good practices.

5.3 Responsiveness
o This app must be fully responsive on different screen sizes.
o This app instantly gives a response whenever a user searches for the timetable, or date
sheet by entering the section name or teacher name.
o This app will provide a proper response to the users if there is any wrong search done
by the user i.e. wrong section name/teacher name.
o If the admin uploaded a new version of the timetable, then users will be immediately
notified if they are using the older version of the timetable as soon they open the
application.

5.4 Accessibility
Any student or teacher on our campus who has an iPhone will be able to access this app. If
their phone has no internet, their timetable, date sheet, and free rooms must be accessible to
them.

6. PROJECT GANTT CHART

Figure 4 Gantt chart

xii
REFERENCES

[1] T. H. Jr, "1," 2017. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.300-

2.pdf.
[2] J. Teamleader, 2014. [Online]. Available:
https://www.cse.msu.edu/~cse435/Handouts/SRSExample-webapp.doc.

13