Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
King Saud UniversityCollege of Computer and Information Sciences
Information Technology Department
CAP312 Project - Phase2Software Requirements Specification-SRS-
E-Transaction Unit
Prepared by
Abrar Jaboor 427204437Hadeel Al-Hamid 427202999Jawaher Al-Firm 425200813
Manar Al-Ghonaim 427200923 Mariam Al-Hazmi 426200663 Mazyonah Al-Fogham 426203132
Supervised byI. Nora Al-Twairesh
Second Semester 1430/1431Spring 2010
Project Proposal
TABLE OF CONTENTS
1. Introduction...........................................................................................................................................3
2. Scope.....................................................................................................................................................4
3. User Characteristics...............................................................................................................................5
4. Specific Requirements............................................................................................................................6
4.1. User and System Requirements....................................................................................................7
4.2. Non Functional Requirements....................................................................................................11
5. System Models.....................................................................................................................................13
5.1 Context Diagram..................................................................................................................13
5.1. DFD Diagram ..............................................................................................................................14
5.2. ER Diagram ................................................................................................................................15
5.2.1. Data Dictionary..................................................................................................................16
6. Team management..............................................................................................................................18
7. Refrances ………………………………………………………………………………………….………………………………………………19
Page 2
System Requirements Specification
1. INTRODUCTION
An SRS is basically an organization's understanding (in writing) of a customer's or a
potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance policy
that assures that both the client and the organization understand the other's requirements
from that perspective at a given point in time.
The SRS document itself states in precise and explicit language those functions and the
capabilities a software system must provide, as well as states any required constraints by
which the system must abide. The SRS also functions as a blueprint for completing a
project with as little cost growth as possible. The SRS is often referred to as the "parent"
document because all subsequent project management documents, such as design
specifications, statements of work, software architecture specifications, testing and
validation plans, and documentation plans, are related to it.[1]
It's important to note that an SRS contains functional and nonfunctional requirements.
Page 3
System Requirements Specification
2. SCOPE
Create website using PHP language and JavaScript.
Create a data base for Hardware numbers and all reports by using PHP admin tools
Two interfaces view one for the admin and the other is for the technicians.
The admin can logon using his/her email and password to perform a lot of tasks
Access the database to retrieve data.
Delete , update , search , Add reports , Hardware number , user email ,building
(number – name ) ,branch (number – name )
Moreover he can add new table in the database.
The technicians also can access the data base and perform all the tasks that have been assigned
to the admin except the deletion.
The system should collect all the reports of the hardware number and display it, after that the
average will be calculated whenever it exceeded the threshold required it will display an alert.
Finally if we have a time we will integration with client system and our system.
Page 4
System Requirements Specification
3. USER CHARACTERISTICS
Users for this system are: admin, technicians, users (KSU employees).
The system responsibilities are to give permissions to the admin to add, remove and update
users, tables, and devices in KSU University.
The main purpose is to inform the users who are concerned (admin, technicians) about
any hardware failure in the campus, the system will have a database filled by the
information of the hardware devices and their reports.
Page 5
System Requirements Specification
4. SPECIFIC REQUIREMENTS
When the user starts the program, the web page will show 2 options the 1st for logging the
other for reporting a problem , when logging on will show 2 fields one for the admin o the
other for the technician.
But when choosing reporting problem a form will display so the user will be shown and
the user will write a report on the device that is having a problem with and click submit to
send it to the database.
Admin : the admin will fill the fields to login , after validation he will be able to search on
device by any key word and then display the results on the screen , also he can insert data
of devices , devices , editing a device or even deleting a device by using an XLS sheet .
Technician: the technicians can search after login and also can do everything that the
admin can do except deleting a device or user.
User: the web interface has a form with the appropriate fields to be filled by the user, if the
user is not very familiar with using this system he can click on the help button to guide
him.
Page 6
System Requirements Specification
4.1. USER AND SYSTEM REQUIREMENTS
Log in This system shall include two fields for user name and password either its
related to the admin or to the technician.
Input User name and password (for admin and technician only)
Output No output
Operation The system should validate the user and his password and confirm.
Redirect the user if he was validated to another page that provides his function (later )
Work order form
This system should include a form that contains a text box and two text
fields
The text box for write his work order and the problem he is facing on his computer .
The two additional fields is for write the employee user name and the title of it
And a button to submit the report
Input Work order , user name and title
Output No output
Operation The system should send the work order to who is concerned (admin and technician ).
Search This system should include a search field for the users only
Page 7
System Requirements Specification
Input Keyword
Output Search results in the output box
Operation The system should send the keyword to the database and then the database return the devices related in the output box
Add This system should provide an add button to the users to add devices and
their details .
Input Device name , device manufacturer , purchase date , work orders if there is any on this device , device type , username of device , and the network point connected to .
Output No output
Operation The system should send these details to the database and to be assigned to a serial number in the database.
Add user This system should provide an add user button to the admin only
Input Username , user location , user first name , user last name , campus .
Output No output .
Operation The system should send these user details to the database and relate it by foreign key (user name ) to the device .
Add technician
This system should provide an add technician button to the admin only
Page 8
System Requirements Specification
Input Username ,password , user first name , user last name , campus , work orders assigned .
Output No output .
Operation The system should send these technician details to the database and relate it by foreign key (campus) to the work orders that he have to work on .
Edit This system should provide an edit button to the users to edit devices and
their details .
Input Edit device’s details (Device name , device manufacturer , purchase date , work orders if there is any on this device , device type , username of device , and the network point connected to .)
Output No output
Operation The system should send these edited details to the database and ask the user to confirm .
Delete This system should provide a delete button to the admin only to delete
devices and their details .
Input No input
Output No output
Operation The system should ask the admin to confirm the deleting process and then remove the device from the database .
Page 9
System Requirements Specification
Add in XLS sheet
This system should provide an add in XLS button to the users to add
devices and their details (can add many devices at once ).
Input Add devices’ details (Device name , device manufacturer , purchase date , work orders if there is any on this device , device type , username of device , and the network point connected to .)
Output No output
Operation The system should send these devices details to the database and relate them a serial number .
Logout This system shall include a logout button and offer it to the user , and ask
them to confirm.
Input No input
Output Redirecting to the home page.
Operation The system should ask the user to save the work and redirect the technician or admin to the home page after asking for conformation.
4.2. NON FUNCTIONAL REQUIREMENTS
Page 10
System Requirements Specification
o Compatibility:
This system shall be developed to be suitable with computer platform and different
operating systems.
o Usability:
The system web interface shall be easy to use
The system should be installed by someone trained on it .
o Robustness:
If the system get failure it should recovered and fixed in short time 2 days maximum .
System should make a backup from the database frequently.
o Security:
The security of this system should be implemented in a good quality to ensure the access
to the system.
o Performance:
Speed of this system shall be good and fast enough to serve the needs of the users.
Page 11
System Requirements Specification
o Size
This system shall consist of a large amount of data
System shall need to occupy a large space about 100 MB initially.
o Ease of use
This system shall perform well with 1 day trained users.
o Reliability
This system should work throughout the work hours of KSU campus i.e. (6:00 am – 7:00
pm).
o Survivability
This system should be supervised by the admin and the staff who implemented the
software.
5. SYSTEM MODELS
Page 12
System Requirements Specification
Here we will illustrate data flow context, (DFD), ER diagrams and data dictionary.
5.1. CONTEXT DIAGRAM
Figure.1 Context Diagram
5.2. DFD DIAGRAM
Page 13
System Requirements Specification
Figure.2 Data Flow Diagram (DFD)
5.3. ER DIAGRAM
Page 14
System Requirements Specification
Figure.3 ER Diagram
5.3.1. DATA DICTIONARY
Page 15
Figure.4 Entities Dictionary
System Requirements Specification
Entities dictionary
Entity Name Description Occurrence
Hardware device General item describes all the
hardwares that are places in the
campus.
Hardware placed in only one
campus.
Workorder General item describes all the
operations that are done including the
reports.
Every workorder has one
hardware.
User General item that describes the admin
and technicians.
System users works-on many
transactions.
Place General item that describes the place
of the hardwares.
Place have many hardwares and
deals with many users.
Technician General item that describes the
technicians.
Person who do all the operations
except deletion and also fixes the
devices that have been reported.
Admin General item that describes the admin. Person who do all the operations.
Relationships dictionary
Page 16
System Requirements Specification
Entity Name Multiplicity Relationship Entity Name Multiplicity
Hardware (0..*) has Workorder (0..1)
Hardware
device
(0..*) Located in Place (1..*)
Figure.5 Relationships dictionary
Attributes dictionary
Figure.6 Attributes Dictionary
6. Team management
Page 17
System Requirements Specification
Tasks Distribution:
Member Responsibilities
Mariam Al-Hazmi The following: User Characteristics. Specific Requirements. User and system requirements. Non functional requirements.
Abrar Jaboor The "System Models", including:
DFD. Context Diagram.
Hadeel Al-Hamid The following: ER Diagram.
Jawaher Al-Firm The following: Introduction. Scope. Data Dictionary.
Manar Al-Ghonaim The revision of the SRS document.
Figure.7 Tasks Distribution
Revision:
Reviewer Name Comment Type
Section Description
Manar Al-Ghonaim Missing Content
-DFD Manar have checked the figure of the DFD completeness. She have noticed that there is some missing content (user).
She notified Abrar to adjust her work.
Figure.8 Overview
7. References
[1] Donn Le Vie, Jr.., “Writing Software Requirements Specifications”, 2008. [Online]. Available: http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html.
Page 18
System Requirements Specification
Accessed [March 2008].
Page 19