Gui
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Gui as PDF for free.
More details
- Words: 1,185
- Pages: 8
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
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
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
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
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
1.7Design and Implementation Constraints
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
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
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
Page 6
Appendix B: Analysis Models
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
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
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
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
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
1.7Design and Implementation Constraints
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
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
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
Page 6
Appendix B: Analysis Models
