Software Requirement Specifications
Software Requirement Specifications
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
4
1. Introduction
1.1 Purpose
1.2 Scop
1.4 References
[1] IEEE, IEEE Std 830-1998 IEEE Recommended Practice for Software
Requirements Specifications, IEEE Computer Society, 1998.
1.5 Overview
5
Finally section 5, Conclusion.
2.1.4 Operations:
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 .
7
3. Specific Requirements:
3.2 Finctions:
3.2.2 Non-Functioal:
8
The design will be simple and neat, and it will be written in
PHP.
3.5.1 Reliability:
3.5.2 Availability:
3.5.3 Security:
3.5.4 Maintainability:
3.6.4.2 Errors:
3.5.5 Portability:
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