Project Proposal€¦ · Web view02/04/2010 · System Requirements Specification. Project Proposal. King Saud University. College of Computer and Information Sciences

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


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


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


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


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


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


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


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


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


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


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


Figure.2 Data Flow Diagram (DFD)

5.3. ER DIAGRAM

Page 14


Figure.3 ER Diagram

5.3.1. DATA DICTIONARY

Page 15

Figure.4 Entities Dictionary


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


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


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

http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html


Accessed [March 2008].

Page 19

Documents

Project Proposal€¦ · Web view02/04/2010 · System Requirements Specification. Project Proposal. King Saud University. College of Computer and Information Sciences