1.1.

SOFTWARE REQUIREMENT SPECIFICATION

Overview of SRS A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It is the first phase of the SDLC. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). 1 INTRODUCTION 1.1 Purpose 1.2 Scope 1.3 Definition, Acronyms and Abbreviations 1.4 Reference 1.5 Overview OVERALL DESCRIPTIONS 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions & Dependencies SPECIFIC REQUIREMENTS 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interface 3.1.3 Software Interface 3.1.4 Communication Interface 3.2 Functional Requirements 3.2.1 Functional Requirements Mode 1 3.2.2 Functional Requirements Mode 2 3.2.3 n Functional Requirements Mode n 3.3 3.4 3.5 3.6 Performance Requirements Design Constraints Attributes Other Requirements

INTRODUCTION Intelligent Health Information System is a semantic web based application prepared for health sector medical practitioners and patients. Using this system/application both doctors and patients can prepare and easily manage their health and fitness schedule. This application will provide the way to give updates about Chronic Diseases to aware the patients. 4.1 Purpose This application system should respond to the requests of standard user and guest user. This system enables doctors or professors to give reply or messages to patients according to patients or standard user condition. The system provides messaging or queries for preventive care, treatment, modifying and deleting an existing messages & treatments plans or diet plans. This system should facilitate adding & deleting and updating messages seamlessly. Moreover, it should be user-friendly and understandable. The aim of the project is to develop a system which can give updates about actual or relevant information to the desired patients, which arranges the most appropriate time for patients, their doctors and recommendations. The system should have a high usability level with its user-friendly interface (as GUI), simplicity in usage and success in practice. 4.2 Scope The scope of the project is used to capture personal medical history. This application will be designed to provide a simple ,relevant and reliable way to have communication about chronic diseases and treatments. Upon the event of an emergency, medical information would have to be acquired from the patients blog and safe procedure. This application would alleviate the need to track down this medical history because it would be readily available. Doctors would be able to add information to the patients account at anytime with the patients consent. More specifically, this application will contain extensive documentation of the medical records, which can be authored by the owner or standard user representative. This includes diagnoses, treatments, medications, allergies, and medical procedures. This application would allow for uniform communication of information between the patient and their respective doctor(s). The software would label and organize information authored by health care providers separately from information authored by the patient to maintain authenticity.

4.3 Definition, Acronyms and Abbreviations Define all terms, acronyms, and abbreviations need to understand the SRS. SRS - Software Requirements Specification Operating System - Interface between hardware and applications and is responsible for managing, sharing and coordination of resources User or Standard User - The person who uses the software/application by registering. Guest The person who visits the page and intended to gain the full access. Healthcare Provider - An instance of the User class, specifically a healthcare professional (e.g., doctor) Doctor A medical practitioner Administrator A person who manages the system, billing standard user etc. Secure account - A web based account in which some form of encryption is in place Medical Record - An instance of one persons medical record. Semantic Web - The Semantic Web aims at converting the current web dominated by unstructured and semi-structured documents into a "web of data". Ontology - Ontology is a description (like a formal specification of a

program) of the concepts and relationships that can exist for an agent or a community of agents.
4.4 Reference 1. T. Berners-Lee, J. Hendler and O. Lassila, The Semantic Web: A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities, Scientific American, May 2001. 2. U.S. Securities and Exchange Commission. Protal for information about eXtensible Business Reporting Language, 2012, http://xbrl.sec.gov/ 3. Tim Berners-Lee. Linked Data Design Issues, 2006, http://www.w3.org/DesignIssues/LinkedData.html 4. GeoNames, 2012, http://www.geonames.org/ 5. American Diabetes Association. Diabetes Basics Common Terms, 2012, http://www.diabetes.org/diabetes-basics/common-terms/ 6. M. Horridge, A Practical Guide To Building OWL Ontologies Using Protege 4 and COODE Tools Edition 1.3, The University Of Manchester, March 2011. 7. M. Horridge, and S. Bechhofer, "The OWL API: A Java API for Working with OWL 2 Ontologies" OWL Experiences and Directions (OWLED 2009), Washington D.C., USA. 8. H. Mcwilliam, F. Valentin, M. Goujon, W. Li, M. Narayanasamy, J. Martin, T. Miyar, and R. Lopez, Web services at the European Bioinformatics Institute-2009, Nucleic Acids Res. 2009 July 1; 37(Web Server issue): W6W10. Published online 2009 July 1. 9. H. Marmanis, and D. Babenko, Algorithms of the Intelligent Web, Manning publications Co, 2009. 10. FAU Semantic Web Course, 2012, http://semanticweb.fau.edu/

Overview The Software Requirement Specification will define and illustrate the overall project and its requirements- both functional and non-functional. In addition the SRS will define the users and their respective characteristics as well as any constraints to development that the team has identified. The format of the SRS document will address the overall project first- including functions and objectives in an overview. This section will also address how this software interfaces with other legacy systems and/or diagnostic equipment connected to it. Then the subsequent sections will specifically addresses the components of the larger software system. These sections delineate specifications for every facet of the components design. 1 OVERALL DESCRIPTIONS The purpose of this section is to present a detailed description of the products perspective giving information about the context and interface constraints. The product functions section outlines major functionality of this application will perform. The user characteristics section explains the expectations about the user. The constraints section contains detailed descriptions of constraints and safety critical properties pertaining to this application. The assumptions and dependencies section summarizes any assumptions or dependencies the application has about the hardware, software, environment and user interactions associated with it. 1.1 Product Perspective This application is developed to help the people to have knowledge about the health being and treatments. Integrating the experience doctors, medical practitioner and the other standard user helps to gain the knowledge. User can gain the different health related issue knowledge by accessing this application. This application tries to covers all the sections or braches of medical. This application is intended to be a stand-alone product and not depend on the availability of other software. 1.2 Product Functions

1.3 User Characteristics The Web Users are expected to be Internet literate, understand how to navigate around a web page and perform conceptual tasks such as logging into a secure account and inputting data into specified fields. 2.3.1 System Administrators have full access to the application to manage the all users including standard, guest and medical.

The medical user will be a healthcare professional like a physician, a nurse, a researcher and emergency medical technician. Note. This is a Medical Information System therefore to limit access and ensure integrity of the data only licensed medical personnel have access to input, search, and update functions. Standard user is a registered user who can access the application for his purpose. Standard user can access the desired information and maintain their personal profile about their diseses. Guest user is a user who visits this application intentionally or unintentionally. Guest user does not have full access to the application.

1.4 General Constraints Internet connection requires for full functionality of the application. If a connection is lost during an active session the outcome may result in viewing only the data the application has currently downloaded on the physical device. Full functionality of the application will resume upon reconnection. 1.5 Assumptions and Dependencies This application assumes that there will be a database for messages hosted by a server. The server assumes it will be installed with a high-speed Internet connection to communicate with the users. The software being developed assumes that the users have computer or laptop with access to the Internet from either a LAN or Wi-Fi connection to establish a connection between the application and the server. The web application assumes that the user has a computer with an Internet connection and a web browser to access the online application.

SPECIFIC REQUIREMENTS Specific requirement section gives the detailed description about the requirements needed to design and develop the system by the software developer. 2.1 External Interface Requirements The external interface requirements describe all the interfaces of the software that includes to people, hardware and other software. 2.1.1 User Interfaces User interface, GUI etc, describe the logical characteristics of each interface between the software product and the users. This may include

sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g. help) that will appear on every screen, keyboard shortcuts, error message display standards and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.

2.1.2

Hardware Interfaces 2.1.2.1

o o o o o

Hardware Specification for Server: CPU Hard Disk Ram Monitor Mouse : : : : : Pentium Dual Core 1.6 GHz. 80 GB. 1 GB. 15 VGA Color. Logitech.

2.1.2.2
o o o o o

Hardware Specification for Client: CPU Hard Disk Ram Monitor Mouse : : : : : Pentium Dual Core 1.6 GHz. 80 GB. 1 GB. 15 VGA Color. Logitech

2.1.3

Software Interfaces 2.1.3.1

o o o o

Software Specification for Server: Operating system Front End Back End Development Tool : : : : Windows XP Professional ASP.NET SQL Sever Visual Studio 2010

2.1.3.2
o o

Software Specification for Server: Operating system Web Browser

: Any Operating System with .NET 4.0 : Microsoft Internet Explorer 7 or above Firefox or Chrome

2.1.4

Communications interfaces Backend to be used is SQL Server 2003 Hardware platform consists of Processor P4 with 512MB RAM and Windows Version XP with .Net framework 4.0

2.2 Functional Requirements Our programs functions: The system allows medical users to see all the message and information of the patients. The system allows medical user to give, cancel or update messages. The system allows doctors to see their patients profiles. The system allows user to determine the status of the treatment and can take notes about the treatment. The system allows patients to search and view doctors profiles. 2.3 Performance Requirements Average response time of a page on server should not be more than 5 seconds.

2.4 Design Constraints RAM : Hard Disk : Protocols : 256 MB 40 GB HTTP

2.5 Safety Requirement Database back up must be done every day, so that in case the system is crashed because of some unexpected reasons like power failure or virus infections then the backup can be used to restore the data of the application. 2.6 Other Requirements The users using the Learning Management System are required to be authenticated by gaining their own user-ids and passwords. The database and also the application must be protected access to only valid users having access privileges like admin and Registered Users.