THE UNIVERSITY ACCOMODATION OFFICE DATABASE
1. ENTITY TYPES
The following are the entity types to be represented in the database:
Student, Advisor, Lease, Room, Course, NextOfKin, Staff, Invoice, Residence
2. RELATIONSHIP TYPES:
The following are the relationship types exist between the data items:
Advises: The relationship type associates Student and Advisor
Enroll: The relationship type associates Student and Course
Agree: The relationship type associates Student and Lease
Receives: The relationship type associates Student and Invoice
Has: The relationship type associates Student and NextOfKin
Rents: The relationship type associates Student and Room
Contains: The relationship type associates Residence and Room
Inspects: The relationship type associates Staff and Residence
3. DATA QUERIES
The following are some the queries which are required:
Identify the total number of the accommodated students
Identify the number of female students accommodated
Identify the number of male students accommodated
List the students and their next of kin
List students and their entering and leaving date
List students who live in halls
List students who live in flats
Identify the number of foreign students
Identify the number of Tanzanian students
List the residence and comments given in various inspections
Monday, February 28, 2011
SRS OF accomodation db system
Contents
2.INTRODUCTION 2
a.Purpose 2
b.Intended audience 2
c.Project scope 2
d.References 2
3.OVERVIEW DESCRIPTION 2
i.Product perspective 2
ii.Operating environment 3
iii.Design and the implementation constraints 3
i. ENTITY TYPES 3
ii. RELATIONSHIP TYPES: 3
e.Assumptions and the dependencies 4
4.SYSTEM FEATURES 5
f.System features overview 5
I.Functional requirements 5
II.Non functional requirements 5
III.User interface 5
5.OTHER NONFUNCTIONAL REQUIREMENTS 6
g.Performance requirements 6
h.Safety requirements 6
i. Security requirements 6
j. System quality attributes 6
k.System documentation 6
l. User documentation 6
6.OTHER REQUIREMENTS 7
m.Glossary 7
n. Appendices 7
1.INTRODUCTION
a.Purpose
The purpose of this system is to assist the accommodation office to simplify the issue of registering the students who needs the accommodation facilities, to process the request for the rooms, to validate payments and finally to distribute rooms for the qualified students.
b.Intended audience
The intended user of this system will be the accommodation staff and the students. And before they use this system they must read the documentation for this system very careful and they are advised to read in the sequence as it is indicated in the table of content.
c.Project scope
Our system will deal only with accommodation issues, other issues apart from accommodation will not be considered currently because of the time factors, human labor and budget constraints’. The system is expected to assist the accommodation staff to register the students for accommodation online. Also the system is expected to give the students leases where by the students will be required to fill the lease form and the system will process the lease and the request for rooms from the students where by the qualified students will be given the rooms.
d.References
For more information about our system please contact the bench of participants as it is indicated in the participants file appendices.
2.OVERVIEW DESCRIPTION
i.Product perspective
The accommodation system will replace the existing system that is not computerized. Therefore it is expected:-
To be very efficient
To have a good interface which can be easily learnable
Good usability
Low time for the system to be learnt and adopted
Good user time retention for the system
To have high performance
User classes and characteristics
Since the system is expected to be simple, the users of the system are expected to the adequate skills in computer which will enable him/her to use the system effectively. For the students users, they are required to have the skills of accommodation for the students so as they could be able to run the system properly. Also the system is expected to have the administrator who will be responsible for monitoring the system and making sure that the system is well running. The system administrator is required to have knowledge of computer. In general, the privilege will be given to the system administrator who will be able to access any thing and modify it where deemed necessary. The second privilege will be given to the accommodation staff where by they will have the access to the student’s records about the accommodation issue. But for the students, they will only interact with the system when they just want to request the rooms.
So generally the users of the system should have the following characteristics;
Computer skills
Database skills which will help them to access data from this system like writing queries to retrieve data from the database system
ii.Operating environment
The designed system is expected to run under various platforms including the window and the Linux. But it is expected to be more efficient to the environments which are free from the viruses. It is expected to be compatible with the computers of the RAM size of 256 and above, the processor speed of 1.5 and above. It will not be specific for the certain type of vendors only.
iii.Design and the implementation constraints
The database is expected to be designed by using MS Access where by the ER diagrams will be used to model the entities into the database. And the data flow diagrams is expected to show the functionality of the system as it is indicate in file appendices named DFD AND CONTEXT DIAGRAMS and also ER DIAGRAM. To link the data base with the system the PHP will be used.
i. ENTITY TYPES
The following are the entity types to be represented in the database:
Student, Advisor, Lease, Room, Course, NextOfKin, Staff, Invoice, Residence
ii. RELATIONSHIP TYPES:
The following are the relationship types exist between the data items:
Advises: The relationship type associates Student and Advisor
Enroll: The relationship type associates Student and Course
Agree: The relationship type associates Student and Lease
Receives: The relationship type associates Student and Invoice
Has: The relationship type associates Student and NextOfKin
Rents: The relationship type associates Student and Room
Contains: The relationship type associates Residence and Room
Inspects: The relationship type associates Staff and Residence
e.Assumptions and the dependencies
We have assumed that there might the availability of the viruses that is why we have suggested using the Linux.
We assume that the budget allocated to in the establishment of the system is enough
It is assumed that the human experts like programmers and the designers are present and adequate
Also it is assumed that the user will follow the guidance on how to use the system in order to avoid to delete some useful information
In order for the system to work properly, we depend on the maintainability of the system from the users.
3.SYSTEM FEATURES
f.System features overview
The system is expected;
To help the accommodation staff to prepare the lease and process it.
To help the staff to send the accommodation details.
To prepare the inspection report
To help the students to send lease information
To help the students to pay the accommodation fees
To help the students to request the rooms
To help the staffs allocate the rooms for the students
I.Functional requirements
These are features which supports the functionality of the system, if one of the feature is not available means the system will not work. The functional requirements which must be present at the system include; the login button, the validate button, reports, database, forms, computer and other associated hardware.
II.Non functional requirements
These are requirements which are not necessary for the functionality of the system, which means even if they are not available the system will still work. For example the colors in forms, speed of performance.
III.User interface
The designed system must be usable to meet the users’ characteristics and if the user enters the incorrect data, the system will tell him/her what to do.
4.OTHER NONFUNCTIONAL REQUIREMENTS
g.Performance requirements
It is expected that the accommodation system to have a very good performance. This is because the database will help the students and the accommodation staff to have the access of the accommodations information details from the database. It is also expected that the database and the system as well to have a very minimal errors.
h.Safety requirements
The system will work under the open source software. This is because in open source software has no viruses. For the case of windows it is expected that the machine involved will be scanned regularly.
i. Security requirements
The combination of the password and the user name will be used to control the access to database. Where by the system will authenticate the users according to their priorities. Only the database administrator will have the permission to be able to change, delete or add data to the system.
j. System quality attributes
The following quality attributes are expected from the university accommodation system;
Accessibility
Maintainability
Availability
Reliability
Efficiency
Good usability
k.System documentation
It is expected after the completion of the system, to be documented so as to help other system developers to expand the existing system or to come up with a new prototype of the system. But this will depend on the users’ requirements at that particular time.
l. User documentation
The guides on how to use the system will be generated to direct the students and the accommodation staff on how to use the accommodation system.
5.OTHER REQUIREMENTS
m.Glossary
PHP - This is the abbreviation of the word Hypertext Preprocessor which allows web developers to create dynamic content that interacts with databases.
CONTEXT DIAGRAM – It is the top-level diagram which shows the scope of the system and it also shows the boundary being defined by the data flows to and from external entities.
DATA FLOW DIAGRAMS (DFD) – These are diagrams which decompose the Process into high level processes.
ENTITY RELATION DIAGRAM – This the graphical representation of the data model which shows entities, relationships, and attributes
n. Appendices
The DFD AND CONTEXT DIAGRAMS, ER DIAGRAM and PARTICIPANTS are appended on the other files.
2.INTRODUCTION 2
a.Purpose 2
b.Intended audience 2
c.Project scope 2
d.References 2
3.OVERVIEW DESCRIPTION 2
i.Product perspective 2
ii.Operating environment 3
iii.Design and the implementation constraints 3
i. ENTITY TYPES 3
ii. RELATIONSHIP TYPES: 3
e.Assumptions and the dependencies 4
4.SYSTEM FEATURES 5
f.System features overview 5
I.Functional requirements 5
II.Non functional requirements 5
III.User interface 5
5.OTHER NONFUNCTIONAL REQUIREMENTS 6
g.Performance requirements 6
h.Safety requirements 6
i. Security requirements 6
j. System quality attributes 6
k.System documentation 6
l. User documentation 6
6.OTHER REQUIREMENTS 7
m.Glossary 7
n. Appendices 7
1.INTRODUCTION
a.Purpose
The purpose of this system is to assist the accommodation office to simplify the issue of registering the students who needs the accommodation facilities, to process the request for the rooms, to validate payments and finally to distribute rooms for the qualified students.
b.Intended audience
The intended user of this system will be the accommodation staff and the students. And before they use this system they must read the documentation for this system very careful and they are advised to read in the sequence as it is indicated in the table of content.
c.Project scope
Our system will deal only with accommodation issues, other issues apart from accommodation will not be considered currently because of the time factors, human labor and budget constraints’. The system is expected to assist the accommodation staff to register the students for accommodation online. Also the system is expected to give the students leases where by the students will be required to fill the lease form and the system will process the lease and the request for rooms from the students where by the qualified students will be given the rooms.
d.References
For more information about our system please contact the bench of participants as it is indicated in the participants file appendices.
2.OVERVIEW DESCRIPTION
i.Product perspective
The accommodation system will replace the existing system that is not computerized. Therefore it is expected:-
To be very efficient
To have a good interface which can be easily learnable
Good usability
Low time for the system to be learnt and adopted
Good user time retention for the system
To have high performance
User classes and characteristics
Since the system is expected to be simple, the users of the system are expected to the adequate skills in computer which will enable him/her to use the system effectively. For the students users, they are required to have the skills of accommodation for the students so as they could be able to run the system properly. Also the system is expected to have the administrator who will be responsible for monitoring the system and making sure that the system is well running. The system administrator is required to have knowledge of computer. In general, the privilege will be given to the system administrator who will be able to access any thing and modify it where deemed necessary. The second privilege will be given to the accommodation staff where by they will have the access to the student’s records about the accommodation issue. But for the students, they will only interact with the system when they just want to request the rooms.
So generally the users of the system should have the following characteristics;
Computer skills
Database skills which will help them to access data from this system like writing queries to retrieve data from the database system
ii.Operating environment
The designed system is expected to run under various platforms including the window and the Linux. But it is expected to be more efficient to the environments which are free from the viruses. It is expected to be compatible with the computers of the RAM size of 256 and above, the processor speed of 1.5 and above. It will not be specific for the certain type of vendors only.
iii.Design and the implementation constraints
The database is expected to be designed by using MS Access where by the ER diagrams will be used to model the entities into the database. And the data flow diagrams is expected to show the functionality of the system as it is indicate in file appendices named DFD AND CONTEXT DIAGRAMS and also ER DIAGRAM. To link the data base with the system the PHP will be used.
i. ENTITY TYPES
The following are the entity types to be represented in the database:
Student, Advisor, Lease, Room, Course, NextOfKin, Staff, Invoice, Residence
ii. RELATIONSHIP TYPES:
The following are the relationship types exist between the data items:
Advises: The relationship type associates Student and Advisor
Enroll: The relationship type associates Student and Course
Agree: The relationship type associates Student and Lease
Receives: The relationship type associates Student and Invoice
Has: The relationship type associates Student and NextOfKin
Rents: The relationship type associates Student and Room
Contains: The relationship type associates Residence and Room
Inspects: The relationship type associates Staff and Residence
e.Assumptions and the dependencies
We have assumed that there might the availability of the viruses that is why we have suggested using the Linux.
We assume that the budget allocated to in the establishment of the system is enough
It is assumed that the human experts like programmers and the designers are present and adequate
Also it is assumed that the user will follow the guidance on how to use the system in order to avoid to delete some useful information
In order for the system to work properly, we depend on the maintainability of the system from the users.
3.SYSTEM FEATURES
f.System features overview
The system is expected;
To help the accommodation staff to prepare the lease and process it.
To help the staff to send the accommodation details.
To prepare the inspection report
To help the students to send lease information
To help the students to pay the accommodation fees
To help the students to request the rooms
To help the staffs allocate the rooms for the students
I.Functional requirements
These are features which supports the functionality of the system, if one of the feature is not available means the system will not work. The functional requirements which must be present at the system include; the login button, the validate button, reports, database, forms, computer and other associated hardware.
II.Non functional requirements
These are requirements which are not necessary for the functionality of the system, which means even if they are not available the system will still work. For example the colors in forms, speed of performance.
III.User interface
The designed system must be usable to meet the users’ characteristics and if the user enters the incorrect data, the system will tell him/her what to do.
4.OTHER NONFUNCTIONAL REQUIREMENTS
g.Performance requirements
It is expected that the accommodation system to have a very good performance. This is because the database will help the students and the accommodation staff to have the access of the accommodations information details from the database. It is also expected that the database and the system as well to have a very minimal errors.
h.Safety requirements
The system will work under the open source software. This is because in open source software has no viruses. For the case of windows it is expected that the machine involved will be scanned regularly.
i. Security requirements
The combination of the password and the user name will be used to control the access to database. Where by the system will authenticate the users according to their priorities. Only the database administrator will have the permission to be able to change, delete or add data to the system.
j. System quality attributes
The following quality attributes are expected from the university accommodation system;
Accessibility
Maintainability
Availability
Reliability
Efficiency
Good usability
k.System documentation
It is expected after the completion of the system, to be documented so as to help other system developers to expand the existing system or to come up with a new prototype of the system. But this will depend on the users’ requirements at that particular time.
l. User documentation
The guides on how to use the system will be generated to direct the students and the accommodation staff on how to use the accommodation system.
5.OTHER REQUIREMENTS
m.Glossary
PHP - This is the abbreviation of the word Hypertext Preprocessor which allows web developers to create dynamic content that interacts with databases.
CONTEXT DIAGRAM – It is the top-level diagram which shows the scope of the system and it also shows the boundary being defined by the data flows to and from external entities.
DATA FLOW DIAGRAMS (DFD) – These are diagrams which decompose the Process into high level processes.
ENTITY RELATION DIAGRAM – This the graphical representation of the data model which shows entities, relationships, and attributes
n. Appendices
The DFD AND CONTEXT DIAGRAMS, ER DIAGRAM and PARTICIPANTS are appended on the other files.
participants
PARTICIPANTS
SHADRACK, OBADIA……………………………………………………………………………………CIM/D/08/T.9998
FIRMIN, AGNESS……………………………………………………………………………………CIM/D/08/T.11689
TARIMO, FRANK ……………………………………………………………………………………CIM/D/08/T.9958
FRANCIS, WILLIAM ……………………………………………………………………………………CIM/D/08/T.9976
LIGAYA, RASHID ……………………………………………………………………………………CIM/E/08/T. 11118
KANTUKA, ANZURUNI ……………………………………………………………………………………CIM/D/08/T. 9347
MISOTTI, MKUDE……………………………………………………………………………………ED/E/08/T.11248
GEORGE, GODFRAY……………………………………………………………………………………ED/D/08/T.10040
MOLLEL, NAGALALI SIMEL……………………………………………………………………………………CIM/D/08/T.10011
JACKSON, EVODIUS…………………………………………………………………………………….………ED/D/08/T.10065
SHADRACK, OBADIA……………………………………………………………………………………CIM/D/08/T.9998
FIRMIN, AGNESS……………………………………………………………………………………CIM/D/08/T.11689
TARIMO, FRANK ……………………………………………………………………………………CIM/D/08/T.9958
FRANCIS, WILLIAM ……………………………………………………………………………………CIM/D/08/T.9976
LIGAYA, RASHID ……………………………………………………………………………………CIM/E/08/T. 11118
KANTUKA, ANZURUNI ……………………………………………………………………………………CIM/D/08/T. 9347
MISOTTI, MKUDE……………………………………………………………………………………ED/E/08/T.11248
GEORGE, GODFRAY……………………………………………………………………………………ED/D/08/T.10040
MOLLEL, NAGALALI SIMEL……………………………………………………………………………………CIM/D/08/T.10011
JACKSON, EVODIUS…………………………………………………………………………………….………ED/D/08/T.10065
Subscribe to:
Posts (Atom)