SREC Hostel Management Hostel Management

Version <1.0>

Hostel Management <document identifier>

Version: <1.0> Date: <01/11/2011>

Revision History
Date <01/11/2011> Version <1.0> Description Hostel Management Author S.RanjithKumar M.E

Confidential

SREC, 2011

ii

Hostel Management <document identifier>

Version: <1.0> Date: <01/11/2011>

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview 2. Functionality 2.1 PIN Validation 2.2 Mess bill enquiry 2.3 Library 2.4 Games 3. Usability 4. Reliability 4.1.1 Availability 4.1.2 Mean Time between Failures (MTBF) 4.1.3 Mean Time to Repair (MTTR) 4.1.4 Accuracy 5. Performance 5.1.1 Response time 5.1.2 Throughput 6. Supportability 6.1.1 Information Security Requirement 6.1.2 Maintenance 7. Design Constraints 8. Purchased Components 9. Interfaces 9.1 User Interfaces 9.2 Hardware Interfaces 9.3 Software Interfaces 10. Licensing Requirements 11. Legal, Copyright and Other Notices 12. Applicable Standards 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3

Confidential

SREC, 2011

iii

Hostel Management <document identifier>

Version: <1.0> Date: <01/11/2011>

Hostel Management
1. Introduction
The purpose of this document is to define the requirements of the Hostel Management System. The Supplementary Specifications capture the system requirements that are not readily capturable in the use cases of the use-case model. Such requirements include: 1.1 Legal and regulatory requirements and application standards. Quality attributes of the system to be built, including usability, reliability, performance and supportability requirements. Other requirements such as operating systems and environments, compatibility requirements, and design constraints.]

Purpose The purpose of Supplementary Specification (SS) document is to describe the external behavior of the HMS. Requirements Specification defines and describes the operations, interfaces, performance, and quality assurance requirements of the HMS. The document also describes the nonfunctional requirements such as the user interfaces. The Supplementary Specification (SS) captures the complete software requirements for the system, or a portion of the system. Requirements described in this document are derived from the Vision Document prepared for the HMS. 1.2 Scope This Supplementary Specification applies to the HMS. This specification defines the nonfunctional requirements of the system; such as reliability, usability, performance, and supportability as well as functional requirements that are common across a number of use cases. (The functional requirements are defined in the Use Case Specifications.). 1.3 Definitions, Acronyms and Abbreviations HMS: Hostel Management System. HA: Hostel Administrator PIN: Personal Identification Number. References www.google.com Object oriented analysis and system concepts -Ali Bharami

1.4

1.5

Overview The SS will provide a detailed description of the HMS. This document will provide the outline of the requirements, overview of the characteristics and constraints of the system. This section will provide the general factors that affect the product and its requirements.

2.

Functionality
2.1 PIN Validation This function checks the validity of the pin number. If the user enters the pin number means it will check the pin number with already stored pin number. If it matches means the system allows the user to login. 2.2 Mess bill enquiry If the user wants to know the mess bill means this module provides this facility. The system refers the corresponding ID and provides the Bill amount.

Confidential

<SREC>, 2011

Hostel Management <document identifier> 2.3

Version: <1.0> Date: <01/11/2011>

Library HMS maintains the information about both the technical books and magazines in the hostel library. HA can add, delete, modify and maintain book details. Other users can view the information. 2.4 Games HMS maintains the information about the games and kits available for the students to play. HA can add, delete, modify and maintain game details. Other users can view the information

3.

Usability
The system shall allow the users to access the system for mess bill amount from the machine. Since all users are familiar with the general usage no specific training is required. The system is user friendly.

4.

Reliability
The system has to be very reliable due to the importance of data and the damages incorrect or incomplete data can do. 4.1.1 Availability The system is available 100% for the user and is used 24 hrs a day and 365 days a year. The system shall be operational 24 hours a day and 7 days a week. 4.1.2 4.1.3 4.1.4 Mean Time between Failures (MTBF) The system will be developed in such a way that it may fail once in a year. Mean Time to Repair (MTTR) Even if the system fails, the system will be recovered back up within one day or less. Accuracy The accuracy of the system is limited because the transaction process is an important one.

5.

Performance
5.1.1 Response time The response will be an immediate one. If the user enters means it will verify the Pin number and allow to access. After validation of pin we can get the response immediately. 5.1.2 System. Throughput The number of transactions is directly dependent on the number of users; all users may access the

6.

Supportability
The system designers shall take in to considerations the following supportability and technical limitations. 6.1.1 Information Security Requirement The system shall support information security requirements and use the some standard as information security requirements. 6.1.2 Maintenance The maintenance of the system shall be done as per the maintenance contract.

Confidential

<SREC>, 2011

Hostel Management <document identifier>

Version: <1.0> Date: <01/11/2011>

7.
1.1.1 1.1.2

Design Constraints
Software Language Used The languages that shall be used for coding the HMS are DOTNET and SQL. Class Libraries Will make use of the existing class libraries available for DOTNET and also will develop new programs using ASP and scripting languages.

8. 9.

Purchased Components
The system need to purchase licensed DOTNET and SQL.

Interfaces
9.1 User Interfaces User makes use of the Monitor and keyboard to interact with the system. The user-interface of the system shall be designed as the user-interface prototypes. 9.2 Hardware Interfaces The HMS machine with some enhanced features. 9.3 Software Interfaces A firewall will be used with the server to prevent unauthorized access to the system.

10. 11.

Licensing Requirements
The usage is restricted to only the particular Hostel and signs the maintenance contract.

Legal, Copyright and Other Notices

The Hostel Management system is a trademark of particular Hostel and cannot be used without its consent.

12.

Applicable Standards
Communication standards TCP/IP Platform compliance standards Windows Safety standards - ISO

Confidential

<SREC>, 2011