UNIT I

Introduction to Software Engineering and Requirement Engineering

Syllabus

Introduction to Software Engineering, Software Process, SDLC: Waterfall, prototyping,

spiral, incremental model - Software Requirements: Functional and Non-Functional, User
requirements, System requirements, Software Requirements Document – case study.

1.1 Introduction to Software Engineering

The term software engineering is composed of two words, software and engineering.
Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be a collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product. Engineering on the other hand, is all about
developing products, using well-defined, scientific principles and methods.

IEEE defines software engineering as: The application of a systematic, disciplined,

quantifiable approach to the development, operation and maintenance of software.

Software engineering principles use two important techniques to reduce problem complexity:
abstraction and decomposition. The principle of abstraction implies that a problem can be
simplified by omitting irrelevant details. The decomposition, a complex problem is divided
into several smaller problems and then the smaller problems are solved one by one.

Defining Software

Software is nothing but a collection of computer programs and related documents that are
intended to provide desired features, functionalities and better performance. Software
products may be:

[1] Generic - That means developed to be sold to a range of different customers.

[2] Custom - That means developed for a single customer according to their specification.

Software Characteristics:

Software development is a logical activity and therefore it is important to understand basic

characteristics of software. Some important characteristics of software are:

Software is engineered, not manufactured Software development and hardware

development are two different activities. A good design is a backbone for both the activities.
Quality problems that occur in hardware manufacturing phase cannot be removed easily. On
the other hand, during software development process such problems can be rectified. In both
the activities, developers are responsible for producing qualitative product.
Software does not ware out In early stage of hardware development process the failure rate
is very high because of manufacturing defects. But after correcting such defects the failure
rate gets reduced. The failure rate remains constant for some period of time and again it starts
increasing because of environmental maladies (extreme temperature, dusts, and vibrations).
On the other hand software does not get affected from such environmental maladies. Hence
ideally it should have an "idealized curve". But due to some undiscovered errors the failure
rate is high and drops down as soon as the errors get corrected.

Another issue with software is that there are no spare parts for software. If hardware
component wears out it can be replaced by another component but it is not possible in case of
software. Therefore software maintenance is more difficult than the hardware maintenance.

Most software is custom built rather than being assembled from components While
developing any hardware product firstly the circuit design with desired functioning properties
is created. Then required hardware components such as ICs, capacitors and registers are
assembled according to the design, but this is not done while developing software product.
Most of the software is custom built.

Categories of Software

Software can be applied in a situation for which a predefined set of procedural steps
(algorithm) exists. Based on a complex growth of software it can be classified into following
categories.

System software It is collection of programs written to service other programs. Typical

programs in this category are compiler, editors, and assemblers. The purpose of the system
software is to establish a communication with the hardware.

Application software It consists of standalone programs that are developed for specific
business need. This software may be supported by database systems.

Engineering/scientific software This software category has a wide range of programs from
astronomy to volcanology, from automative stress analysis to space shuttle orbital dynamics
and from molecular biology to automated manufacturing. This software is based on complex
numeric computations.
Embedded software This category consists of program that can reside within a product or
system. Such software can be used to implement and control features and functions for the
end-user and for the system itself.

Web application software consists of various web pages that can be retrieved by a browser.
The web pages can be developed using programming languages like JAVA, PERL, CGI,
HTML, DHTML.

Artificial intelligence software This kind of software is based on knowledge based expert
systems. Typically, this software is useful in robotics, expert systems, image and voice
recognition, artificial neural networks, theorem proving and game playing.

1.2 Software Process

1.2.1 Layered Technology
Software engineering is a layered technology. Any software can be developed using
these layered approaches. Various layers on which the technology is based are quality
focus layer, process layer, methods layer, tools layer.

A quality focus: It defines the continuous process improvement principles of software. It

provides integrity that means providing security to the software so that data can be
accessed by only an authorized person, no outsider can access the data. It also focuses on
maintainability and usability.
Process: It is the foundation or base layer of software engineering. It is key that binds all
the layers together which enables the development of software before the deadline or on
time. Process defines a framework that must be established for the effective delivery of
software engineering technology. The software process covers all the activities, actions,
and tasks required to be carried out for software development.
 Process activities are listed below:-
• Communication: It is the first and foremost thing for the development of software.
Communication is necessary to know the actual demand of the client.
• Planning: It basically means drawing a map for reduced the complication of
development.
• Modeling: In this process, a model is created according to the client for better
understanding.
• Construction: It includes the coding and testing of the problem.
• Deployment:- It includes the delivery of software to the client for evaluation and
feedback.
Method: During the process of software development, the answers to all “how-to-do”
questions are given by method. It has the information of all the tasks which includes
communication, requirement analysis, design modelling, program construction, testing,
and support.
Tools: Software engineering tools provide a self-operating system for processes and
methods. Tools are integrated which means information created by one tool can be used
by another.
1.3 Software Process Model
The process model can be defined as the abstract representation of process. The
appropriate process model can be chosen based on abstract representation of process.
• The software process model is also known as software development life cycle (SDLC)
model or software paradigm.
• These models are called perspective process models because they are following some
rules for correct usage.

Various perspective models are as follows

1. Waterfall Model
2. Incremental Process Model
3. RAD Model
4. Evolutionary Process model
a. Spiral Model
b. Prototyping model
1.3.1 Waterfall Model
The software development starts with requirements gathering phase. Then progresses
through analysis, design, coding, testing and maintenance.
In REQUIREMENT ANALYSIS AND SPECIFICATION phase the basic
requirements of the system must be understood by software engineer, who is also
called Analyst. The information domain, function, behavioural requirements of the
system are understood. All these requirements are then well documented and
discussed further with the customer, for reviewing.
The DESIGN is an intermediate step between requirements analysis and coding. Design
focuses on program attributes such as –

▪ Data structure
▪ Software architecture
▪ Interface representation
▪ Algorithmic details.

The requirements are translated in some easy to represent form using which coding can be
done effectively and efficiently. The design needs to be documented for further use.

CODING is a step in which design is translated into machine-readable form. If design is

done in sufficient detail then coding can be done effectively. Programs are created in this
phase.

TESTING begins when coding is done. While performing testing the major focus is on
logical internals of the software. The testing ensures execution of all the paths, functional
behaviours. The purpose of testing is to uncover errors, fix the bugs and meet the customer
requirements.

MAINTENANCE is the longest life cycle phase. When the system is installed and put in
practical use then error may get introduced, correcting such errors and putting it in use is the
major purpose of maintenance activity. Similarly, enhancing system’s services as new
requirements are discovered is again maintenance of the system.

Waterfall Model - Application

• Requirements are very well documented, clear and fixed.

• Product definition is stable.
• Technology is understood and is not dynamic.
 • There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
Merits:

• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Demerits:

• No working software is produced until late during the life cycle.

• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
1.3.2 Incremental Model
The incremental model has same phases that are in waterfall model. But it is iterative
in nature. The incremental model has following phases.
1) Analysis 2) Design 3) Code 4) Test

When to choose it?

1) When requirements are reasonably well-defined.

2) When overall scope of the development effort suggests a purely linear effort.
3) When limited set of software functionality needed quickly.
Merits of incremental model

1) The incremental model can be adopted when there are a smaller number of people
involved in the project.
2) Technical risks can be managed with each increment.
3) For a very small-time span, at least core product can be delivered to the customer.

1.3.3 RAD Model(Rapid Application Development Model)

▪ The RAD Model is a type of incremental process model in which there is
EXTREMELY SHORT DEVELOPMENT CYCLE.
▪ When the requirements are fully understood and the COMPONENT BASED
CONSTRUCTION approach is adopted then the RAD model is used.
▪ Using the RAD model the fully functional system can be developed WITHIN 60 TO
90 DAYS.
▪ Various phases in RAD are Requirements Gathering, Analysis and Planning, Design,
Build or Construction and finally Deployment.
▪ Multiple teams work on developing the software system using RAD model parallel.
▪ In the REQUIREMENTS GATHERING phase the developers communicate with the
users of the system and understand the business process and requirements of the
software system.
▪ During ANALYSIS AND PLANNING phase, the analysis on the gathered
requirements is made and a planning for various software development activities is
done.
▪ During the design phase various models are created. Those models are Business
model, data model and process model.
▪ The build is an activity in which using the existing software components and
automatic code generation tool the implementation code is created for the software
system. This code is well tested by its team. The functionalities developed by all the
teams are integrated to form a whole.
▪ Finally the deployment of all the software components (created by various teams
working on the project) is carried out.
Drawbacks of rapid application development
▪ It requires multiple teams or large number of people to work on the scalable projects.
▪ This model requires heavily committed developer and customers. If commitment is
lacking then RAD projects will fail.
▪ The projects using RAD model requires heavy resources.
▪ If there is no appropriate modularization then RAD projects fail. Performance can be
problem to such projects.
▪ The projects using RAD model find it difficult to adopt new technologies.
1.3.4 Evolutionary Process model
Spiral Model
This model possess the iterative nature of prototyping model and controlled and systematic
approaches of the linear sequential model.
▪ This model gives efficient development of incremental versions of software. In this
model, the software is developed in series of increments.
▪ The spiral model is divided into a number of framework activities. These framework
activities are denoted by task regions.
▪ Usually there are six tasks regions. The spiral model is as shown in the figure below

▪ Spiral model is realistic approach to development of large-scale systems and software.

Because customer and developer better understand the problem statement at each
evolutionary level. Also risks can be identified or rectified at each such level.
The task regions can be described as :
1) Customer communication - In this region, it is suggested to establish customer
communication.
2) Planning - All planning activities are carried out in order to define resources time line and
other project related activities.
3) Risk analysis - The tasks required to calculate technical and management risks are carried
out.
4) Engineering - In this task region, tasks required to build one or more representations of
applications are carried out.
5) Construct and release - All the necessary tasks required to construct, test, install the
application are conducted. Some tasks that are required to provide user support are also
carried out in this task region.
6) Customer evaluation - Customer's feedback is obtained and based on customer evaluation
required tasks are performed and implemented at installation stage.

Advantages of spiral model

 • Requirement changes can be made at every stage.
• Risks can be identified and rectified before they get problematic.
Drawbacks of spiral model
• It is based on customer communication. If the communication is not proper then
the software product that gets developed will not be up to the mark.
• It demands considerable risk assessment. If the risk assessment is done properly
then only the successful product can be obtained.
Prototyping Model
Prototype methodology is defined as a Software Development model in which a
prototype is built, test, and then reworked when needed until an acceptable prototype is
achieved. It also creates a base to produce the final system. Software prototyping model
works best in scenarios where the project's requirements are not known. It is an iterative,
trial, and error method which take place between the developer and the client Often, a
customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
• In this case Prototyping is best suited
• Prototyping can be used together with other models for elicitation
requirements
• The prototype can serve as “the first system.” Some prototypes are “Throw
Away” while others also evolve become part of the actual system.
• Both customers and developers like the prototyping paradigm.
o Customer/End user gets a feel for the actual system
o Developer gets to build something immediately

Prototyping Drawbacks
• Customer may want to hang onto first version, may want a few fixes rather than
rebuild. First version will have compromises
• Developer may make implementation compromises to get prototype working quickly.
Later on developer may become comfortable with compromises and forget why they
are inappropriate
2.1 Requirement Engineering
Requirement: A function, constraint or other property that the system must provide to fill the
needs of the system’s intended user(s)
Engineering: implies that systematic and repeatable techniques should be used
Requirement Engineering means that requirements for a product are defined, managed and
tested systematically
• It is essential that the software engineering team understand the requirements of a
problem before the team tries to solve the problem.
• In some cases, requirements engineering may be abbreviated, but it is never
abandoned.
• RE is software engineering actions that start with communication activity and
continues into the modelling activity.
• RE establishes a solid base for design and construction. Without it, resulting software
has a high probability of not meeting customer needs.
Characteristics of Good Requirement
• Clear and Unambiguous
▪ standard structure
▪ has only one possible interpretation
▪ Not more than one requirement in one sentence
• Correct
▪ A requirement contributes to a real need
• Understandable
▪ A reader can easily understand the meaning of the requirement
• Verifiable
▪ A requirement can be tested
• Complete
• Consistent
• Traceable
2.2 Requirement Engineering Tasks
▪ Inception —Establish a basic understanding of the problem and the nature of the
solution.
▪ Elicitation —Draw out the requirements from stakeholders.
▪ Elaboration (Highly structured)—Create an analysis model that represents
information, functional, and behavioral aspects of the requirements.
▪ Negotiation—Agree on a deliverable system that is realistic for developers and
customers.
▪ Specification—Describe the requirements formally or informally.
▪ Validation —Review the requirement specification for errors, ambiguities, omissions,
and conflicts.
▪ Requirements management —Manage changing requirements.
 Some of the problems that arise during the requirements engineering process are a result of
failing to make a clear separation between these different levels of description. The
requirements are termed as User level and System Level Requirements.
• User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users and the constraints under
which it must operate.
• System requirements are more detailed descriptions of the software system’s
functions, services, and operational constraints. The system requirements document
(sometimes called a functional specification) should define exactly what is to be
implemented. It may be part of the contract between the system buyer and the
software developers.
Case Study:
Scenario:
Healthcare patient information systems is a software product is about to be developed for the
XYZ organization with the name XYZHcare

1. The XYZHCare system shall generate monthly management

User Requirement reports showing the cost of drugs prescribed by each clinic
during that month

1.1 On the last working day of each month, a summary of the drugs
prescribed, their cost and the prescribing clinics shall be
generated.
1.2 The system shall generate the report for printing after 17.30 on
the last working day of the month.
System 1.3 A report shall be created for each clinic and shall list the
Requirement individual drug names, the total number of prescriptions, the
number of doses prescribed and the total cost of the prescribed
drugs.
1.4 If drugs are available in different dose units (e.g. 10mg, 20mg,
etc.) separate reports shall be created for each dose unit.
1.5 Access to drug cost reports shall be restricted to authorized users
as listed on a management access control list.

2.3 Functional and Non-Functional Requirements

Software system requirements are often classified as functional or non-functional
requirements:
Functional requirements These are statements of services the system should provide, how
the system should react to particular inputs, and how the system should behave in particular
situations. In some cases, the functional requirements may also explicitly state what the
system should not do.
Non-functional requirements These are constraints on the services or functions offered by
the system. They include timing constraints, constraints on the development process, and
constraints imposed by standards. Non-functional requirements often apply to the system as a
whole rather than individual system features or services.
Functional Requirements
• Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
• Describe functionality or system services
• Depend on the type of software, expected users and the type of system where the
software is used
• Functional user requirements may be high-level statements of what the system should
do but functional system requirements should describe the system services in detail.
Examples for Functional Requirements:
• A user shall be able to search the appointments lists for all clinics.
• The system shall generate each day, for each clinic, a list of patients who are expected
to attend appointments that day.
• Each staff member using the system shall be uniquely identified by his or her eight-
digit employee number.
Non-Functional Requirements
Non-functional requirements may affect the overall architecture of a system rather
than the individual components. For example, to ensure that performance requirements are
met in an embedded system, you may have to organize the system to minimize
communications between components.

Figure 1Types of Non - Functional Requirement

Product requirements These requirements specify or constrain the runtime behavior of the
software. Examples include performance requirements for how fast the system must execute
and how much memory it requires; reliability requirements that set out the acceptable failure
rate; security requirements; and usability requirements.
The XYZHCare system shall be available to all clinics during normal working hours
(Mon–Fri, 08:30–17:30). Downtime within normal working hours shall not exceed 5
seconds in any one day.
Organizational requirements These requirements are broad system requirements derived
from policies and procedures in the customer’s and developer’s organizations. Examples
include operational process requirements that define how the system will be used;
development process requirements that specify the programming language
Users of the XYZHCare system shall identify themselves using their health authority
identity card.
External requirements This broad heading covers all requirements that are derived from
factors external to the system and its development process.
The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.
Software Requirement Document
If specification incomplete, inconsistent, or misleading specifications have
experienced the frustration and confusion that invariably results. The specification principles
are as follows:
1. Separate functionality from implementation.
2. Develop a model of the desired behavior of a system.
3. Establish the context in which software operates by specifying the manner.
4. Define the environment in which the system operates and indicate how.
5. Create a cognitive model rather than a design or implementation model. The cognitive
model describes a system as perceived by its user community.
6. The specifications must be tolerant of incompleteness and augmentable.
7. Establish the content and structure of a specification in a way that will enable it to be
amenable to change.
SRS Document:
• It contains a complete information description, a detailed functional description, a
representation of system behavior, an indication of performance requirements and
design constraints, appropriate validation criteria, and other information pertinent to
requirements.
Format of SRS:
Introduction of the software requirements specification states the goals and objectives of the
software, describing it in the context of the computer-based system.
Information content, flow, and structure are documented. Hardware, software, and human
interfaces are described for external system elements and internal software functions.
Functional Description A processing narrative is provided for each function, design
constraints are stated and justified & performance characteristics are stated
Behavioral Description operation of the software as a consequence of external events and
internally generated control characteristics.
Validation Criteria is probably the most important and, ironically, the most often neglected
section of the Software Requirements Specification (SRS). Testing or validating each user-
scenario.

Finally, the specification includes a Bibliography and Appendix. The bibliography contains
references to all documents that relate to the software. The appendix contains information
that supplements the specifications
Case Study – Hospital Patient Information System
This is a SRS document for Hospital Patient Information Management System. Where the
hospital department people will store the info of the patient who has admitted and would
retrieve the info whenever required.

TABLE OF CONTENTS

1. INTRODUCTION
1.1. Purpose
1.2 Scope
1.3. Definitions, Acronyms, and Abbreviations
1.4. References
1.5 Overview
2. GENERAL DESCRIPTION
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3. SPECIFIC REQUIREMENTS
3.1 Functional Requirements
3.2 Design Constraints
3.3 Non-Functional Requirements
3.3.1 Security
3.3.2 Performance Requirements
3.3.3 Maintainability
3.3.4 Reliability
4.CONCLUSION

1. Introduction

1.1 Purpose

The purpose of this document is to describe the requirements for the Hospital Patient Info
Management System (HPIMS). The intended audience includes all stakeholders in the
potential system. These include, but are not necessarily limited to, the following:
Administrative Staff, patients and developers.

Developers should consult this document and its revisions as the only source of requirements
for the project. They should not consider any requirements statements, written or verbal as
valid until they appear in this document or its revision.

1.2 Scope
The proposed software product is the Hospital Patient Info Management System (HPIMS).
The system will be used to get the information from the patients and then storing that data for
future usage. The current system in use is a paper-based system. It is too slow and cannot
provide updated lists of patients within a reasonable timeframe. The intentions of the system
are to reduce over-time pay and increase the number of patients that can be treated accurately.
Requirements statements in this document are both functional and non-functional.
1.3 - Definitions, Acronyms, and Abbreviations

HPIMS - Hospital Patient Info Management System

PHN - Personal Health Number on health card
Report - an account of patients
Front-desk staff - administrative staff that work at reception desk
Logon ID - a user identification number to enter the system
Password - a word that enables one to gain admission into the system

Web-based application - an application that runs on the Internet

MySQL - a query language to interrogate the system
GUI - Graphical User Interface

SRS - Software Requirements Speficification

1.4 References
No formal documents have been referenced in this document
1.5 Overview

This Software Requirements Specification (SRS) is the requirements work product that
formally specifies Hospital Patient Info Management System (HPIMS). It includes the results
of both business analysis and systems analysis efforts. Various techniques were used to elicit
the requirements and we have identified your needs, analyzed and refined them. The
objective of this document therefore is to formally describe the system’s high level
requirements including functional requirements, non-functional requirements and business
rules and constraints. The detail structure of this document is organized as follows:

Section 2 of this document provides an overview of the business domain that the proposed
Hospital Patient Info Management System (HPIMS) will support. These include a general
description of the product, user characteristics, general constraints, and any assumptions for
this system. This model demonstrates the development team's understanding of the business
domain and serves to maximize the team's ability to build a system that truly does support the
business.
Section 3 presents the detail requirements, which comprise the domain model.
2. General Description
2.1 Product Perspective

This Hospital Patient Info Management System is a self-contained system that manages
activities of the hospital as Patient Info. Various stakeholders are involved in the hospital
patient info system.
2.2 Product Functions
The system functions can be described as follows:
Registration: When a patient is admitted, the front-desk staff checks to see if the patient is
already registered with the hospital. If he is, his/her Personal Health Number (PHN) is
entered into the computer. Otherwise a new Personal Health Number is given to this patient.
The patient’s information such as date of birth, address and telephone number is also entered
into computer system.
Patient check out. If a patient checks out, the administrative staff shall delete his PHN from
the system and the just evacuated bed is included in available-beds list.
Report Generation: The system generates reports on the following information: List of
detailed information regarding the patient who ha admitted in the hospital

2.3 User Characteristics

The system will be used in the hospital. The administrators,front-desk staff will be the main
users. Given the condition that not all the users are computer-literate. Some users may have to
be trained on using the system. The system is also designed to be user-friendly. It uses a
Graphical User Interface (GUI).

Front-desk staff:
They all have general reception and secretarial duties. Every staff has some basic computer
training. They are responsible for patient’s check-in or notification of appropriate people .

Administrators:
They all have post-secondary education relating to general business administration practices.
Every administrator has basic computer training. They are responsible for all of the
scheduling and updating day/night employee shifts.

. 2.4 General Constraints

The system must be delivered by January 1st 2011.
The existing Telecommunication infrastructure is based on IEEE100802.3 standards and the
system must conform to this standard using category 5 cables for networking
The system must be user-friendly
2.5 Assumptions and Dependencies
· It is assumed that one hundred IBM compatible computers will be available before the
system is installed and tested.
· It is assumed that the Hospital will have enough trained staff to take care of the system
3. Specific Requirements
3.1 Functional Requirements
Registration
SRS001 Add patients
The HPIMS shall allow front-desk staff to add new patients to the system.
SRS002 Assign ID
The HPIMS shall allow front-desk staff to give each patient a ID and add it to the patient’s
record. This ID shall be used by the patient throughout his/her stay in hospital.

Check Out

SRS003 Delete Patient ID

The administrative staff in the ward shall be allowed to delete the ID of the patient from the
system when the patient checks out.
SRS004 Add to beds-available list
The administrative staff in the ward shall be allowed to put the beds just evacuated in beds-
available list.

Report Generation
SRS005 Patient information
The HPIMS shall generate reports on patients about the following information: patient’s
PHN, patient’s name, ward name, bed number and the doctor’s name which was assigned.
SRS006 Bed Aavailability
The HPIMS shall generate reports on bed availability about the following information: ward
name, bed number, occupied/unoccupied.

Database
SRS007 Patient Mandatory Information
Each patient shall have the following mandatory information: first name, last name, phone
number, personal health number, address, postal code, city, country, patient identification
number.
SRS008 Update Patient Information
The HPIMS shall allow the user to update any of the patient’s information as described in
SRS007.

3.2 Design Constraints

SRS009 Database
The system shall use the MySQL Database, which is open source and free.
SRS010 Operating System
The Development environment shall be Windows 2000.
SRS011 Web-Based
The system shall be a Web-based application.
3.3 Non-Functional Requirements
3.3.1 Security
SRS012 Patient Identification
The system requires the patient to identify himself /herself using PHN
SRS013 Logon ID
Any user who uses the system shall have a Logon ID and Password.
SRS014 Modification
Any modification (insert, delete, update) for the Database shall be synchronized and done
only by the administrator in the ward.
SRS015 Front Desk staff Rights
Front Desk staff shall be able to view all information in HPIMS, add new patients to HPIMS
but shall not be able to modify any information in it.
SRS016 Administrators' Rights
Administrators shall be able to view and modify all information in HPIMS.
3.3.2 Performance Requirements
SRS017 Response Time
The system shall give responses in 1 second after checking the patient’s
information.
SRS018 Capacity
The System must support 1000 people at a time.
SRS019 User-interface
The user-interface screen shall respond within 5 seconds.
SRS020 Conformity
The systems must conform to the Microsoft Accessibility guidelines

3.3.3 Maintainability

SRS021 Back Up
The system shall provide the capability to back-up the Data
SRS022 Errors
The system shall keep a log of all the errors.

3.3.4 Reliability

SRS023 Availability
The system shall be available all the time

4.CONCLUSION

This SRS document is used to give details regarding Hospital Patient Info Management
System. In this all the functional and non-functional requirements are specified inorder to get
a clear cut idea to develop a project.