Automatic Insulin Pump

Software Requirements Specification Version 1.1 2-4-2014 Usama Azhar CEO

Prepared for The University of Faisalabad

Automatic Insulin Pump

Revision History
Date 1/8/13 3/9/13 11/10/13 15/2/14 Description Version 1.1.1 Version 1.2 Version 1.2.1 Version 1.3 Author Afnan Ishaq Danial Amir Umer Ayub Hammad Malik Comments Changing in product perspective Changing in specific requirements Changing in design constraints Changing in logical database requirements

Document Approval
The following Software Requirements Specification has been accepted and approved by the following: Signature Printed Name Title Date Usama Azhar Kamran Akram Usama Azhar CEO CIO CEO

1/8/13 3/9/13 15/2/14

Software Requirements Specification HI-TECH Software House

Page ii

Automatic Insulin Pump

Table of Contents 1.Introduction------------------------------------------------------------------1

1.1 Purpose----------------------------------------------------------------------------------------------1 1.2 Scope------------------------------------------------------------------------------------------------ 1 1.3 Definitions, acronyms and abbreviation------------------------------------------------------1,2 1.4 References------------------------------------------------------------------------------------------3 1.5 Overview--------------------------------------------------------------------------------------------3

2.Overall Description----------------------------------------------------------3
2.1 Insulin Pump-------------------------------------------------------------------------------------3,4 2.1.1 System Interface----------------------------------------------------------------------------4 2.1.2 Interface--------------------------------------------------------------------------------------5 2.1.3 Hardware Interface-------------------------------------------------------------------------5 2.1.4 Memory Constraints------------------------------------------------------------------------6 2.2 Product Functions----------------------------------------------------------------------------------6 2.3 User Characteristics--------------------------------------------------------------------------------6 2.4 General Constraints------------------------------------------------------------------------------6,7 2.5 Assumptions and dependencies------------------------------------------------------------------7 2.6 Apportioning of Requirements-------------------------------------------------------------------7

3.Specific Requirement of Insulin Pump-----------------------------------7

3.1 Specification Requirement-------------------------------------------------------------------7,8,9 3.1.1 Hardware Interface------------------------------------------------------------------------9 3.1.2 Software Interface-------------------------------------------------------------------------9 3.1.3 Communication Interface---------------------------------------------------------------10 3.2 Functional Requirement-------------------------------------------------------------------------10 3.2.1 Safety constraints--------------------------------------------------------------------10,11 3.2.2 Insulin dose computation requirements-----------------------------------------------11 3.2.3 Error and warning requirements---------------------------------------------------11,12 3.2.4 Insulin pump status requirements--------------------------------------------------12,13 3.2.5 Graphical user interface requirements--------------------------------------------13,14 3.3 Design and implementation requirements----------------------------------------------------14 3.4 Design Constraints-------------------------------------------------------------------------------14 3.4.1 Limitations-------------------------------------------------------------------------------15 3.4.2 Standards ---------------------------------------------------------------------------------15 3.5 Software system attribute ------------------------------------------------------------------15,16

Software Requirements Specification HI-TECH Software House

Page iii

Automatic Insulin Pump

1. Introduction
The introduction to the SRS document provide an overview of the complete project. This document contain all the information needed by a software engineer to design and implement the software product described by the requirements listed in this document. (Note: the following subsection annotates are largely taken from the IEEE Guide to SRS).

1.1 Purpose
The purpose of this document is to present a detailed description of the Automatic Insulin Pump system. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system.

1.2 Scope
This SW system will be an automatic insulin pump designed for the patients which are suffering from diabetes. This system will be designed to check the level of glucose in the patient's body automatically through embedded sensors and if glucose level is low or high ' performs the corresponding functions which are designed to level the amount of glucose in the body (methods are described below). The project is required to construct an insulin pump simulator that can be used for diabetes patients, insulin pump developers and physicians.

1.3 Definitions, Acronyms, and Abbreviations

Diabetes Basal A medical disorder that causes the body to produce excessive amounts of urine. Insulin infusion given as low regular flow throughout the day. This is done in AUTORUN mode of the insulin pump. Insulin infusion given as a one time delivery in addition to any basal delivery. A bolus is given, for example, when eating a high carbohydrate meal. This is done in
Page 1

Bolus

Software Requirements Specification HI-TECH Software House

Automatic Insulin Pump

Unsafe

Safe

Undesirable

Insulin

Pancreases

MANUAL mode of the insulin pump. A very low level of sugar (less than 3 units) is dangerous and can result in hypoglaecemia which can result in a diabetic coma and ultimately death. Between 3 units and 7 units, the levels of sugar are safe and are comparable to those in people without diabetes. This is the ideal band. Above 7 units to 35 units is undesirable but high levels are not dangerous in the shortterm. Continuous highlevels however can result in longterm side effects. A hormone produced in the pancreas that regulates the level of glucose in the blood. A large elongated glandular organ lying near the stomach. It secrets juices into the small intestine and the hormones insulin, glucagons and somatostatin into the bloodstream. Level of glucose in the blood. Levels rise after meals and are usually lowest in the morning, before the first meal of the day. Software requirement specification Software Insulin Pump Insulin pump therapy is the term used to describe the use of insulin pumps in managing blood glucose levels in people with insulin-dependent diabetes
Page 2

Sugar level

SRS SW IP Insulin pump therapy

Software Requirements Specification HI-TECH Software House

Automatic Insulin Pump

1.4 References
IEEE-2004 version of SWEBOK. Editors : Pierre Bourque, cole de technologie suprieure Robert Dupuis, Universit du Qubec Montral

1.5 Overview
Overall Description section of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next sections. After Overall Description section, Requirements Specification section of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.

2. Overall Description
This section of the SRS describe the general factors that affect the product and its requirements.

2.1 Insulin Pump :The basic components of an insulin pump includes: a user interface The user interface includes the capability to input data and also to choose actions. In addition, the pump is able to display information to the user. In our case, the input and output are kept very simple and not specific as to hether they are te!tual or audible. the controller The controller is the di"ital control unit that e are able to pro"ram. #"ain, this is assumed to be as "eneral as feasible. $e are not interested in the different
Software Requirements Specification HI-TECH Software House Page 3

Automatic Insulin Pump

faults that are introduced by digital computers compared with field programmable gate arrays, e.g., The (pump) controller can be programmed to administer basal (periodic) or bolus (extra) insulin according to a patients request. the pumping mechanism The pumping mechanism the hardware pump that moves the insulin from the reservoir into the users body (through the infusion set). It is also generic in that we do not distinguish between the different types of pumps. the insulin reservoir The insulin reservoir holds the insulin cartridges. The reservoir needs to have the capability of signaling when the remaining amount of insulin is low (below a threshold), or empty. wireless input/output This insulin pump can communicate wirelessly with a remote computer, a continuous glucose monitor (CSM), or even the cloud.

2.1.1 System Interface

iCloud system. Database mangement system
Software Requirements Specification HI-TECH Software House Page 4

Automatic Insulin Pump

2.1.2 Interface Input :The system input hardware is modelled as follows: A blood sugar sensor which measures the current blood sugar reading in micrograms/millilitre. This is updated every 10 minutes. It is modelled in the Z specification as Reading?. The value of Reading? is normally between 1 and 35. A hardware test unit which runs a self-test on the hardware every 30 seconds. Problems detected by this unit are modelled in the Z specification as Hardware Test #. A three position switch which can be set to off, manual or auto mode. This is modelled in the Z specification as switch. A button to specify the amount of insulin to be delivered when in manual mode. The number of button presses within a 5 second period specifies the number of units of insulin to be injected. The system must be in manual mode for this to be operational and you may assume that after the first press is detected, the number of presses is counted automatically by the hardware. This is modelled in the Z specification as Manual Delivery Button. Presence sensors for the insulin reservoir and the needle assembly. These switch status when the insulin reservoir/needle is attached or removed. They are modelled in the Z specification as Insulin Reservoir and Needle. A hardware clock which is factory set and which maintains the current time. This is represented by the state variable clock.

Output:The output hardware is as follows: Three displays that provide information to the user about the state of the system. These are modelled as display1!, display2! and clock!. The operation of these displays is described in requirement 3.8 above and in the following schema. A pump unit that delivers a specified dose of insulin. This is modelled in the Z specification as dose. An alarm which gives an audible signal to the user if a problem has arisen. This is modelled as alarm!. The hardware examines this value every 10 seconds and either sets off or cancels the audible alarm.

2.1.3 Hardware Interface

Software Requirements Specification HI-TECH Software House Page 5

Automatic Insulin Pump

Hard disk

2.1.4 Memory Constraints

RAM Cache

2.2 Product Functions

Sugar level check. Quantity of insulin in the pump. Time interval. Digital meter reader. Memory set-up. Method of purification of apparatus Cost effective. Blood pressure and body temperature. Battery recharging (back-up battery). User friendly. Automatic and manual operations. Data storage in computer when device connected to a computer. Online doctor consultant and GPS based system.

2.3 User Characteristics

The user is expected to be Internet literate and be able to use an automatic machine. The main screen of the IP will have the search function and a link to Help. The user is expected to be used of using touch screen.

2.4 General Constraints

These include: (1) (2) (3) (4) (5) (6) Regulatory policies Hardware limitations Interface to other applications Parallel operation Audit functions Control functions
Page 6

Software Requirements Specification HI-TECH Software House

Automatic Insulin Pump

(7) Higher-order language requirements (8) Signal handshake protocols (9) Reliability requirements (10) Criticality of the application (11) Safety and security considerations

2.5 Assumptions and Dependencies

One assumption is that it will always be used on the software installed in it by default. Users might have allocated with other applications, there may be scenarios where the application does not work as intended or even at all.

2.6 Apportioning of Requirements

In the case that the project is delayed, there are some requirements that could be transferred to the next version of the application. Those requirements are to be developed in the third release.

3. Specific Requirements of Insulin Pump

3.1 Specification Requirements
1. The dose of insulin to be delivered shall be computed by measuring the current level of blood sugar, comparing this to a previous measured level and computing the required dose as described below. 2. The system shall measure the level of blood sugar and deliver insulin if required every 10 minutes. 3. The amount of insulin to be delivered shall be computed according to the current sugar reading as measured by the sensor: 3.1 If the reading is below the safe minimum, no insulin shall be delivered. See schema SUGAR_LOW. 3.2 If the reading is within the safe zone, then insulin is only delivered if the
Software Requirements Specification HI-TECH Software House Page 7

Automatic Insulin Pump

level of sugar is rising and the rate of increase of sugar level is increasing. The amount of insulin required is defined in the schema SUGAR_OK. 3.3 If the reading is above the recommended level, insulin is delivered unless the level of blood sugar is falling and the rate of decrease of the blood sugar level is increasing. The amount of insulin required in this case is defined in the schema SUGAR_HIGH. 3.4 The amount of insulin actually delivered may be different from the computed dose as various safety constraints are included in the system as defined in the schema RUN. There is a limit on the maximum dose to be delivered in a single injection and a limit on the total cumulative dose in a single day. 4. Under normal operating conditions, the system is defined by the schema RUN. 5. When operating in manual mode, the system is defined by the schema MANUAL. 6. The controller shall run a self-test program every 30 seconds. This shall test for the conditions shown in Table 1 below. The self-testing of the system is defined by the schema TEST. 7. When switched on, the system is initialized as defined in the schema STARTUP. 8. The system shall maintain three displays: display1 is a text display that shows system messages. It has an associated hardware buffer that can hold several messages. When there is more than 1 message in this buffer, each message is displayed for 5 seconds until all messages have been displayed. The display sequence then restarts with the first message. Hence, several messages may be specified for display on display1!. display2 shows the last dose of insulin that was computed. clock! displays the current clock time. 9. The user may replace the insulin reservoir with a new reservoir at any time. The design of the reservoir compartment is such that only full reservoirs holding 100 ml of insulin
Software Requirements Specification HI-TECH Software House Page 8

Automatic Insulin Pump

may be inserted. When a new insulin reservoir has been inserted, the system is reset according the RESET schema. 10. At the beginning of each 24 hour period (indicated by clock =00:00:00), the cumulative dose of insulin delivered is reset to 0. 11. The error conditions that should be detected and indicated by the system are shown in Table . Alarm Condition Explanation Battery low The voltage of the battery has fallen to less than !"# $ensor failure The self%test of the sugar sensor has resulted in an error &elivery failure 't has not been possible to deliver the specified a(ount of insulin )e!g! the needle (ay be bloc*ed or incorrectly inserted+ ,eedle asse(bly re(oved The user has re(oved the needle asse(bly 'nsulin reservoir re(oved The user has re(oved the insulin reservoir -ow insulin level The level of insulin is low )indicating that the reservoir should be changed+ 3.1.1Hardware interfaces: %ince neither the IP nor the eb portal have any desi"nated hard are, it does not have any direct hard are interfaces. The physical &P% is mana"ed by the &P% application in the IP and the hard are connection to the database server is mana"ed by the underlyin" operatin" system on the mobile phone and the eb server. 3.1.2 Software interfaces: The IP communicates ith the &P% application in order to "et "eo"raphical information

Software Requirements Specification HI-TECH Software House

Page 9

Automatic Insulin Pump

about here the user is located and the visual representation of it, and ith the database in order to "et the information about the restaurants. The communication bet een the database and the eb portal consists of operation concernin" both readin" and modifyin" the data, hile the communication bet een the database and the IP consists of only readin" operations. 3.1.3 Communications interfaces: The communication between the different parts of the system is important since they depend on each other. However, in what way the communication is achieved is not important for the system and is therefore handled by the underlying operating systems for both the mobile application and the web portal.

3.2 Functional Requirements

The functional requirements of IP are : 3.2.1 Safety Constraints 1) The initial capacity of the insulin reservoir is set to 100. Maximum daily dose, maximum single dose and minimum dose are set to 35, 5, and 1, respectively. Maximum daily dose is defined the maximum dose that can be delivered in 12 minutes that is scaled down from a day. Maximum single dose is the maximum dose of insulin that can be delivered in a single injection. Minimum dose is the dose that may be delivered to maintain an existing trend in blood sugar levels. 2) Once the dose has been computed the simulator then must determine whether the dose calculated is safe. It is essential due to the critical nature of the simulator. There are two scenarios about safety requirements depending on simulator mode AUTORUN Mode and MANUAL Mode. 3) AUTORUN Mode: If maximum daily dose will be exceeded by the sum of the dose calculated and the cumulative doze, the dose to be injected should be calculated by subtracting the sum of the calculated doze and cumulative dose of insulin from maximum daily dose. If the sum of the dose calculated and cumulative doze is less than or equal to maximum daily doze, there are two possibilities: 1) If the dose calculated is less than or equal to maximum single dose, deliver the insulin calculated; 2) If the single dose computed is too high, deliver the maximum single dose. Alert the user and set the status to warning, if the safe constraints (maximum single doze and/or maximum daily doze) broken.
Software Requirements Specification HI-TECH Software House Page 10

Automatic Insulin Pump

4) MANUAL Mode: If maximum daily dose is exceeded and/or maximum single dose is exceeded, alert the user and set the status to warning. The maximum daily and maximum single dose safety constraints will be overridden. In other words, amount of insulin units calculated will be injected as it is. 5) All safety requirements are reset every 12 minutes. 3.2.2 Insulin Dose Computation Requirements 1) The dose of insulin to be delivered shall be computed by measuring the current level of blood sugar, comparing this to previous measured levels and computing the required dose as described below. 2) The possible blood sugar level is between 1 and 35 and the simulator shall measure the blood sugar level and deliver insulin if required every 10 seconds. 3) The amount of insulin to be delivered shall be computed according to the current sugar reading as read by the simulator: a. If the reading is below the safe minimum, no insulin shall be delivered. Alarm is on and a warning message must be displayed. b. If the reading is within the safe zone, then insulin is only delivered if the level of sugar is rising and the rate of increase of sugar level is increasing. The amount of insulin required must be defined based on the algorithm. c. If the reading is above the safe zone, insulin is delivered unless the level of blood sugar is falling and the rate of decrease of the blood sugar level is increasing. The amount of insulin required must be defined based on the algorithm. d. The amount of insulin actually delivered may be different from the computed dose as various safety constraints specified at . There is a limit on the maximum dose to be delivered in a single injection and a limit on the total cumulative dose in 12 minutes. If maximum daily dose will be exceeded by the dose calculated, the dose to be injected should be calculated by subtracting cumulative dose of insulin from maximum daily dose. In the mean time the warning message shall be issued. This message can be reset by the user within the 12 minute time window. 3.2.3 Error and Warning Requirement Whenever errors and/or warnings occur, the simulator displays the corresponding messages immediately. Since there is no insulin pump hardware for the simulator, the error messages such as No Needle Unit, Sensor Failure, Insulin Reservoir Removed, and Pump
Software Requirements Specification HI-TECH Software House Page 11

Automatic Insulin Pump

Failure are activated and deactivated by the user. The error message, No Insulin, and the warning messages such as Maximum Daily Dose, Maximum Single Dose, Low Insulin Level, Low Battery, and Low Blood Sugar Level shall be activated and deactivated by the simulator. These messages can be also reset every 12 minute. Note that these messages reflect the status of the insulin simulator. For example, Low Battery shall be issued if the status of the battery has fallen to onethird of the full charge after the simulator starts. Note that the level of battery shall decrease by 4 units every 30 second. Note that when the battery is completely empty, the simulator shall stop. The table below specifies the error and warning messages and their descriptions. When at least one error occurs, AUTORUN and MANUAL modes are suspended until the errors are removed; simulation timer and battery keep going. 3.2.4 Insulin Pump Status Requirements 1) The possible status of the insulin pump simulator includes SWITCHON, AUTORUN, MANUAL and SWITCHOFF. 2) When the simulator is loaded, it goes to SWITCHOFF mode. 3) The SWITCHON mode simulates the behaviour of the pump when the user pushes the switchonbutton. When the user switches on the simulator, it goes to AUTORUN mode. It is assumed that the users blood sugar is at SAFE stage (for example, the blood sugar level is five. 4) Under normal operating conditions, the simulator is defined by the AUTORUN. If the user increases the blood sugar level, the simulator should respond properly based on. Unless the user increases the blood sugar level, the simulator does not take any insulin injections and the blood sugar level remains SAFE. Note that cumulative dose is reset to zero at the beginning of the each 12 minutes period. The AUTORUN can be further defined in three statuses: normal, warning, and error. In normal operation, the status is running; if a state exists which is potentially hazardous such as low battery and low insulin level, then the status is warning and The simulator keep functioning with displaying warning messages; if a state exists such as pump fail, sensor fail, delivery fail and insulin empty, the status is error. In the error state, normal operation (AUTORUN mode and MANUAL mode) are suspended until the errors are removed. 5) As soon as the user clicks a manual mode button, the simulator goes to MANULA mode. The user is able to specify the amount of insulin to be delivered
Software Requirements Specification HI-TECH Software House Page 12

Automatic Insulin Pump

by pressing the button within 5 second period. The number of clicks specifies the number of units of insulin to be injected. Insulin injection occurs when the five second time window is expired. Note that safety checks, specified at Requirement V.1, are overruled. If maximum daily dose and maximum single dose are exceeded, the amount of insulin is injected while the simulator displays the corresponding warning messages. Cumulative dose and the last dose of insulin are still updated. After insulin injection, the simulator automatically goes to the AUTORUN mode. Note that the blood sugar level will be updated when the simulator goes back to the AUTORUN mode. 6) When switch off, the simulator goes to the SWITCHOFF mode that clear all information. When the user switches on, the simulator starts new.

3.2.5Graphical User Interface Requirements 1) A power on/off switch shall be displayed. 2) A MANNUAL button is used to inject insulin manually. The number of clicks within five second is the amount of insulin injected. 3) Display the current mode (AUTORUN, MANNUAL). 4) All values are reset every 12 minutes. 5) A current blood sugar level and at least two previous levels should be displayed. Implementing a graphical representation (with numerical values) to a current sugar level and previous sugar levels is required. 6) The amount of the last dose of insulin to be administered shall be displayed.
Software Requirements Specification HI-TECH Software House Page 13

Automatic Insulin Pump

7) The amount of the cumulative of insulin injected shall be displayed. 8) The amount of time the simulator run shall be displayed. 9) Current realtime shall be displayed. 10) The status of battery shall be displayed with a numeric value and progress bar. 11) The status of the insulin reservoir shall be displayed. 12) Warning and error messages shall be displayed in the single line text box. If there is one message, keep displaying that message. When there is more than one message, each message is displayed for 3 seconds until all messages have been displayed. The display sequence then restarts with the first message unless warnings and errors are clear. Also an audio alarm for each message shall be given. 13) Users are allowed to change the current blood sugar level in order to test the insulin pump simulators reaction to varying blood sugar readings. 14) If users decide that they require insulin immediately they can manually override the automatically delivering system. Users specify how much insulin to be injected by pressing a button. The number of button presses within 5 second period specifies the number of units of SWITCH-ON AUTORUN MANUAL SWITCH-OFF. insulin to be injected, The system must be in manual mode for this to be operational and you may assume that after the first press is detected, the number of presses is counted automatically.

3.3 DESIGN AND IMPLEMENTATION REQUIREMENTS

1. ObjectOriented Analysis (OOA) 2.ObjectOriented Design (OOD) 3.ObjectOriented Programming (OOP) 4.Java 5.C++ 6.Visual Basic 7.Microsoft Visual and UML Diagrammer 8.Eclipse 9. Net Beans 10.Microsoft Visual Studio

3.4 Design Constraints

In design constraints we tell about limitations of our system and software For
Software Requirements Specification HI-TECH Software House Page 14

Automatic Insulin Pump

example, this could specify the requirement for software to trace processing activity And we also tell about our system requirements For this type of software we require following type of system hardware Memory Ram Graphics Processor 512MB 128 MB 512MB Atom

3.4.1Limitations

Hardware limitations : Our system's memory is too low so we can't store too much data. We can't increase our memory because our system can't support too much memory and slow. We use battery which need charging. Insulin tank needs refill after 12 hours. Software limitations : In our software design we restricted our system to connect with other system. Hardware standards : Hardware memory is maximum it can be increased by user requirement. We use battery but if battery low there is no backup for system Software standards : Our system must be compatible with other systems but it not it is only compatible with our system

3.4.2 Standards

3.5 Software System Attributes

There are a number of attributes of software that can serve as requirements. Reliability : Our system is reliable because we use best type of hardware to make our system reliable we use : Compact design Flexible handling Rich features Errors can occurs with warning also gives the tips to repair High testing of this software we done so we say that is this system is reliable This software have high fault tolerance Security: We secure data and resources Analysis and design of this is secure
Software Requirements Specification HI-TECH Software House Page 15

Automatic Insulin Pump

Security design of this software is best Confidentiality is great application data base on the critically Access privilege controls in place Identifying the mode of data transmitted or processed within the application Design application related infrastructure and designing the technical requirements Replication and redundancy in data base system Maintainability: To make higher maintainability higher the bug fixing speed Modular design Un needed complexity We also make a portion for duplicate code if system crash we use duplicate code

4. Change Management Process 5. Document Approvals 6. Supporting Information

Software Requirements Specification HI-TECH Software House

Page 16