Software Requirements

Specification
For
“Designing a GUI for graph based data-model”

prepared by :
 Rohit maloo(Exam Roll:110508048)

 Sandip Barnwal(Exam Roll:110508051)

 Shahnawaz Azmi(Exam Roll:110508049)

 Ruchika Dakalia(Exam Roll:110508022)

Bengal Engineering and Science University, Shibpur

21/06/2009

Copyright © 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for <Project> Page ii

Table of Contents
1. Introduction................................................................................................................................1
1.1 Purpose ......................................................................................................................................... ....1
 The software will provide the user with a GUI that will work as an  interface for implementation of 
the graph based data model of a specific database system.......................................................... ............1
1.2 Intended Audience ................................................................................................. ..........................1
1.3 Project Scope.......................................................................................................... ..........................1
1.4 Product Features.......................................................................................................................... ......2
1.5 User Classes and Characteristics.............................................................................................. .........2
1.6 Operating Environment....................................................................................................... ..............3
1.7 Design and Implementation Constraints............................................................... ............................3
2. System Features..........................................................................................................................3
2.1 VALIDATE USER......................................................................................................... ...................3
2.1.1 Description ................................................................................................................................. 3
2.1.2 Functional Requirements.......................................................................................... ..................3
2.2 UPDATE USER DETAILS............................................................................................................ ...3
2.2.1 Description.................................................................................................................. ...............3
2.2.2 Functional Requirements
4
2.3 VIEW LOG TABLE ENTRIES............................................................................................ ............4
2.3.1 Description.................................................................................................................. ...............4
2.3.2 Functional Requirements
4
2.4 ADD NEW USER................................................................................................... .........................4
2.4.1 Description.................................................................................................................. ...............4
2.4.2 Functional Requirements
4
2.5 DELETE USER.................................................................................................................. ..............5
2.5.1 Description.................................................................................................................. ...............5
2.5.2 Functional Requirements
5
2.6 CHANGE CATEGORY PRIVILEGE.................................................................... ..........................5
2.6.1 Description.................................................................................................................. ...............5
2.6.2 Functional Requirements
5
3. Other Nonfunctional Requirements.........................................................................................5
3.1 Performance Requirements..................................................................................... ..........................5

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for <Project> Page 1

1.Introduction

1.1Purpose 
   

The software will provide the user with a GUI that will work as an
interface for implementation of the graph based data model of a
specific database system.

1.2Intended Audience 
   

The document is intended for clients, developers, project managers

etc. Since the software has an enormous scope of further
development in various aspects, this document will be especially
useful to software developers who want to add new features and
further enhance the usability of the software in future.

1.3Project Scope
   

There are two goals of the project:-

 To enable the user to create a graphical database.
 To implement the data structure of the data model for effective
storing of data.
 To write queries.
Although the user creates a graphical database the software
internally creates a relational database for its own reference
using the same datas entered by the user.
Thus the benefits we get are:-
 Modular structuring of data.
 Encapsulation of semantically similar data.
 Inheriting properties from similar semantic groups,etc
Software Requirements Specification for <Project> Page 2

\
2. Overall Description..............................................................................................
product Perspective
DBMS’s system environments have changed rapidly over the past
few years.Relational model ,though,has made prominent
contributions ,yet recent database applications are outgrowing
this model.Complex and intelligent database applications like
CAD,CASE,Multimedia database,etc are not supported by the
relational model. Modular structuring of data,Encapsulation of
semantically similar data.Inheriting properties from similar
semantic groups,etc are the few features supported by graphical
model making the logical structure within the data-model more
comprehensible.

1.4Product Features

Our application software will represent the entire database as a graph in a layered organization.The 
basic instances of entity is indiacated by the vertex and the relationship among them by the edges.
    The data elements termed as Primary Semantic Group(PSG) are represented by a “Circle” and a 
few PSGs are aggregated to form higher level of nodes termed as Secondary Semantic Group(SSG) 
represented by a “Rectangle”.
    Hence the graph model contains:­
 PSG
 SSG
 Determinant
 Edges

1.5User Classes and Characteristics

Users of this software include:
1. University libraries, laboratories etc.
2. Server rooms, laboratories in different organizations
3. Pathological laboratories and other testing laboratories in hospitals etc.
Over all, any resource that is to be protected against unauthorized and unsupervised usages and 
damage, theft etc. can be secured using this software.
Software Requirements Specification for <Project> Page 3

In any implementation of the software there will be two user groups:
1. The users who want to access the resource.
2. The administrator who is responsible for the overall security issue. 
The administrators, in true sense are also users but with the additional ability to update the database 
which includes both the user details and the user allowances.

1.6Operating Environment

<Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist.>

1.7Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might
include: corporate or regulatory policies; hardware limitations (timing requirements, memory
requirements); interfaces to other applications; specific technologies, tools, and databases to be
used; parallel operations; language requirements; communications protocols; security
considerations; design conventions or programming standards (for example, if the customer’s
organization will be responsible for maintaining the delivered software).>

2.System Features

2.1VALIDATE USER

2.1.1Description 

The user’s identity is validated by consulting the user details table from the central database. This is 
done by matching the password with the user identity number.

2.1.2Functional Requirements

Input: user’s identity number and password.

Output: whether the user is valid/ invalid. 

2.2UPDATE USER DETAILS

2.2.1Description
Software Requirements Specification for <Project> Page 4

User details table is updated according to inputs of the user or the administrator. The user can 
update only the fields like address, phone no., password etc whereas the administrator has the right 
to update the designation and userid field.

2.2.2Functional Requirements

Input: details that are to be updated
Output: updated details

2.3VIEW LOG TABLE ENTRIES

2.3.1Description

The log table entries that are maintained in the central database can be viewed by the administrator 
or the user on entering a combination of the time, date, gate name etc. for which they want to see the 
user whereabouts. A particular user can see only his own whereabouts whereas the administrator has 
the right to view the whereabouts of any user.

2.3.2Functional Requirements

Input: specific queries regarding the details of the whereabouts needed
Output: the required details, if any.

2.4ADD NEW USER

2.4.1Description

The administrator adds the details of any new user of the resources under the scope of the security 
system. The value of a field that indicates the current users is also set.

2.4.2Functional Requirements

Input: new user details
Output: the updated user details
Software Requirements Specification for <Project> Page 5

2.5DELETE USER

2.5.1Description

The administrator virtually deletes a user from the database. Actually a field is kept whose value 
indicates whether the user is a current user or had been a user once but is not so anymore. The value 
of this field is set while deleting any user.

2.5.2Functional Requirements

Input: query to set value of the current user field
Output: the updated details

2.6CHANGE CATEGORY PRIVILEGE

2.6.1Description

The administrator has the right to change the entry/ exit time restrictions as well as the allowance of 
a group of user to cross a gate.

2.6.2Functional Requirements

Input: new values of allowance
Output: the updated allowance values

3.Other Nonfunctional Requirements

3.1Performance Requirements

Since the system has to be developed as an interactive system, it has to work in real time
Software Requirements Specification for <Project> Page 6

Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>