Software Requirement Specifications

Student Reminder Service

M. Al-Wabel 10110039
Siddeq Yousef Siddeq 10110029
Document History
Version Name of Person Date Description of change
1.0 Wabel & Siddeq 12/01/2014 Rough work
1.2 Wabel 12/09/2014 Part 2 + 3
1.3 Siddeq 12/13/2014 Part 4
2.0 Wabel & Siddeq 12/15/2014 Final Documentaion

2
Work distribution

Name Role
Wabel Documenting
Siddeq Documenting + Drawing diagrams

3
 Table of Contents

1. INTRODUCTION ......................................................................5
1.1 PURPOSE................................................................................................... 5
1.2 SCOPE ...................................................................................................... 5
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS. ....................................... 5
1.4 REFERENCES ............................................................................................ 5
1.5 OVERVIEW................................................................................................ 5
2. THE OVERALL DESCRIPTION ............................................... 6
2.1 PRODUCT PERSPECTIVE............................................................................. 6
2.2 PRODUCT FUNCTIONS............................................................................... 6
2.3 USER CHARACTERISTICS ........................................................................... 6
2.4 CONSTRAINTS........................................................................................... 7
2.5 ASSUMPTIONS AND DEPENDENCIES............................................................ 7
2.6 APPORTIONING OF REQUIREMENTS ................................................................ 7

3. SPECIFIC REQUIREMENTS ...................................................................... 7

3.1 USER INTERFACES ..................................................................................... 8

3.2 FUNCTIONS ............................................................................................... 8
3.3 PERFORMANCE REQUIREMENTS ................................................................ 8
3.4 DESIGN CONSTRAINTS............................................................................... 8
3.5 SOFTWARE SYSTEM ATTRIBUTES................................................................ 9
3.5.1 Reliability ......................................................................................... 9
3.5.2 Availability ...................................................................................... 9
3.5.3 Security ............................................................................................ 9
3.5.4 Maintainability................................................................................ 9
3.5.5 Portability ........................................................................................ 9
4. DIAGRAMS ........................................................................... 10
4.1Use Case Diagram ............................................................................. 10
4.2Data flow Diagram ............................................................................ 11
4.3 Sequence Diagram ........................................................................... 12

4.4Class Diagram ................................................................................... 14

5. CONCLUSION :..................................................................... 15

4
1. Introduction

1.1 Purpose

The purpose of this software requirement specification is to describe in

details about our project ‘Student Reminder Service’ for CS370.

1.2 Scop

The SRS 'Student Reminder Service' is desinged as a mobile application.

The system will send reminder E-mails to the students of YUC. The E-
mails will remind the students about their exams dates, project &
assignment submission date, And DN warnings. The exams dates will be
entered by the administrator.

1.3 Definitions, Acronyms, and Abbreviations

SRS Student Reminder Service

YUC Yanbu University College

1.4 References

[1] IEEE, IEEE Std 830-1998 IEEE Recommended Practice for Software
Requirements Specifications, IEEE Computer Society, 1998.

1.5 Overview

This document is organized as follows:

Section 2 provides an overall description of the Student Reminder Service. It

lists the system functionality for each class of users, defines system interfaces,
and specifies the constraints on its operation. It is intended to be read by
everyone interested in the system.

Section 3 presents a detailed description of each system functionality and is

primarly written for the system developers, designers, and maintainers.

Section 4 Concerned about diagrams.The included diagrams are:

Class diagram, Data flow diagram, Use case, and Sequence diagram.

5
 Finally section 5, Conclusion.

2. The Overall Description

2.1 Product Perspective

The application will send E-mails to the students who are

registered in the courses. This will help the students to keep
tracking the dates of their assignment, exams, projects, and DN
warnings.

2.1.2 Software Interfaces:

The system will communicate with it's users through a web

browser.

2.1.3 Memory Constraints:

Since the software is a mobile application, it'll require 39 KB on

the memory.

2.1.4 Operations:

The system will send E-mails automatically at the beginning of the

week (Sunday).

2.2 Product Functions:

The system will be meant to use only be the students of

YUC, and the admin. Registration is required, the user will
be asked to register their E-mail and ID number. Then the
students will choose the courses that they want to follow.
The application can be used whenever there was a wi-fi
connection.

2.3 User Characteristic:

From the Requirements that we have it’s stated that all user
must meet at least all the followings:
1- Having an android mobile.

6
 2- Internet access.
3- Having an Email.
2.3.1 System Administrator:

Since the system does not allow multiple access, there will be
one user who is authorized to insert the data into the system,
the admin.
2.3.2 Students:
Register their E-mails and courses .

2.4 General Constrants :

The listed constrains might effect the implementation of the

system:
- Lack of staff.
- Due date moved ahead.

2.5 Assumption and dependencies:

- The code is expected to be error free.

- The interface will be self explanatory.
- The system will send 150 E-mails per minute.
- The system will work on any android version.

2.6 Apportioning of Requirements:

In the future, the system will be integrated with SIS, so that

the E-mails will be sent to each student automatically.

7
3. Specific Requirements:

3.1 User Interface:

- The user interface will be written in PHP.

- The interface will be very friendly user interface.
- The interface will be - as aforementioned - eslf explanatory.

3.2 Finctions:

3.2.1 Functional Requirments :

- The admin can edit dates at any time.

- The students shall be able to choose which course to register
in.
- The system will send E-mails to remind students about their
quizzes , majors, assignments, projects, and DN warning.
The E-mails will be sent on Sunday @ 07:00 AM to all
students who are registered in the course.
- student can update/ assignment submission date.
- Admin shall be able to send newsletter of collage to all
users.

3.2.2 Non-Functioal:

- The system will always be available.

- The system will never miss or delay any email.

3.3 Performance Requirements:

Since the application can not work unless there is a Wi-Fi

connection, the performance of the application depends on
the performance of the Wi-Fi that is connected to.

3.4 Design Constraints:

8
 The design will be simple and neat, and it will be written in
PHP.

3.5 Software System Attributes

3.5.1 Reliability:

The system will be available at all times.

3.5.2 Availability:

The system shall be available all the time.

3.5.3 Security:

Due to security constraints, solely the admin will enter the

data.

3.5.4 Maintainability:

3.6.4.1 Back up:

The system shall provide the capability to back up the data.

3.6.4.2 Errors:

The system shall keep a log of all the errors.

3.5.5 Portability:

The appliation will work on any device as long as the user

using an android deivce.

9
4. Diagrams

1. Use Case

10
2. Data Flow Diagram:

11
3. Sequence Diagram:

12
4. Context Diagram:

13
5. Class Diagram:

14
5. Conclusion

15
The Project is concerned about sending reminder E-mails to remind
student about their exams dates, project submission and DN
warnings.
The methodology that we are using is water fall and proto type.
There are tow stockholders, student and admin.
There some constrains in our project witch they are: Lack of staff,
Due date moved ahead.
We assume that the system will do the followings: The system will
send 150 E-mails per minute, The system will work on any android
version.
We also expect that in the future the system will be integrated with
SIS, so that the E-mails will be sent to each student automatically.
For the functional requirements: The admin can edit dates at any
time, The students shall be able to choose which course to register
in, The system will send E-mails to remind students about their
quizzes , majors, assignments, projects, and DN warning. The E-
mails will be sent on Sunday @ 07:00 AM to all students who are
registered in the course.
For the non-functional requirements: The system will always be
available, The system will never miss or delay any email.
The system design will be simple and neat, and it will be written in
PHP.

16