2007

PHASE TWO – SOFTWARE REQUIREMENTS SPECIFICATION

A proposed software solution for a Badge Tracking system by LB Systems Integration

10

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

PHASE TWO – SOFTWARE REQUIREMENTS SPECIFICATION

Table of Contents

Table of ContentsINTRODUCTION AND SCOPE 2ASSUMPTIONS 2CONSTRAINTS 2

PHYSIOLOGICAL CONSIDERATIONS 2ENVIRONMENTAL CONSIDERATIONS 3TECHNICAL CONSIDERATIONS 3

SOFTWARE ARCHITECTURE BLOCK DIAGRAM 4SENSOR 4BUILDING HUB 5CENTRAL SERVER 5WEB ADMIN MODULE 6LOGGING SERVER 6

FLEXIBILITY 6RISKS 7DEVELOPMENTAL CHANGES PROCESS 8CROSS REFERENCE LISTING 9INTEGRATION THREAD 10SRS SECURITY POLICY AND NON-DISCLOSURE AGREEMENT 11

Non-Disclosure Agreement and General Terms of Use 11

1

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Introduction and ScopeThe engineers at LB Systems Integration have compiled this Software Requirements Specification (SRS) for the use of customer validation and internal use. The contents of the SRS are delivered with the understanding that the customer, The Center for Handicapped Children, will review our design proposal and decide whether or not to continue with this project.

We expect and require that the information contained herein remain confidential between both parties and would not be shared with competitors building similar systems. Please read and sign the Non-Disclosure Agreement provided with this document.

AssumptionsLB Systems Integration is primarily a software design company. In order to solve the tasks presented to us, we use third party equipment to facilitate the operation of our designs. The design we are submitting will assume that The Center for Handicapped Children has the following infrastructure:

An existing broadband connection to the internet An existing broadband network within the campus

o We will provide any servers and switches necessaryo We do assume that the customer has an existing network that can be

used to transfer data Equipment that will not interfere with 433.92MHz and 802.11b

communicationo If 802.11b communication is unacceptable – we will be forced to wire

each sensor manually A suitable web-hosting environment for external users

We plan on using standard third party computers (or customer provided computers with suitable specifications) for this project. We have also determined that RFID tags would be the best hardware method to solve this problem at this time. This RFID equipment will operate at 433.92MHz – a frequency that is strictly controlled by FCC mandate. We assume that medical equipment will not be susceptible to this communication.

ConstraintsLB Systems Integration appreciates the detailed constraints that were suggested by the customer. We have worked with these constraints through our attention to detail and design.

Physiological Considerations

10

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Several user-specific conditions must be taken into account during system development. The RFID tags that will be used do not pose any known threat to humans or equipment. Interference will be non-existent, even with equipment that may use the same frequencies.

The packaging in which the tracking object is administered to users must be flexible due to physical, social, and mental factors. The RFID tag would be comparable to the size of a credit card and exude the same characteristics as well. It could easily be held on the person or in a pouch with the person.

The RFID tag could be easily removed, replaced and transferred due to its small size and lightweight design. A user would experience no discomfort if they needed to carry the tag with them for extended periods of time.

Environmental ConsiderationsCertain environmental factors further constrain the system. To accurately track a person, a specific minimum amount of environmental construction will be required. The receivers we will work with are Savi® Fixed Reader SR-650 by Lockheed Martin. These receivers can communicate with hubs through a number of different methods – most notably 802.11b and Ethernet interfaces. If need be, these readers can communicate through RS232 lines as well.

The distance in which the user is being tracked must also be restricted to a specific range. The receivers can read tags from 100 meters away during typical operation. This range should be large enough to integrate an encompassing network without high equipment costs. The units themselves are small – 12 inches in diameter by 5.5 inches in height and would be easily mounted to ceilings or walls. They require no external power sources besides normal AC lines in existing buildings.

Technical ConsiderationsThe system will only work with the Windows OS. Development for other platforms will not be considered unless there is significant demand.

1

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Software Architecture Block DiagramThe following diagram is the proposed software architecture for this system followed by a brief explaination of the devices and modules.

FIGURE 1 - SOFTWARE ARCHITECTURE

Please note the following:

Blue dashed arrows represent communication signals and small packets of data

Red arrows represent high traffic internal communication Purple arrows represent web communication with external clients Labels on the arrows convey what information is being passed

Sensor The sensor module will transmit the following information to a hub/server:

Scanner ID Person ID Timestamp Alerts if tampered with or powered off/on

The sensor is a physical device, specifically the Savi® Fixed Reader SR-650. It is responsible for transmitting its ID code, the unique ID of the scanned users and the

10

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

timestamps of the interactions to the hubs. It has built in memory capable of handling several usages between data transmission, in case of intermittent network outages. The scanner may receive alerts from the hub indicating unauthorized/multiple access, etc, along with instructions as to whether or not it should audibly/visibly alert the user.

Building Hub

The Building Hub will do the following:

Receive usage information from sensors Forward usage information to central server(s) Forwards alerts to sensor stations Generate alerts based on anomalous local behavior Alert security personnel of central server alerts Log all events for two days Synchronize communication logs with central server after downtime Synchronize time with the central server

The building hub coordinates all the scanners in its own building. It is responsible for acting as a central (but temporary) repository for all scanner traffic, and synchronizing this data with the central server as often as possible. It will intelligently handle security alerts for its local domain, while notifying staff of incoming central server alerts. It will have sufficient memory to act independently should the central server go down. A computer running Windows XP with 512MB of RAM and 100GB of hard disk space should be acceptable for this type of usage.

Central Server

The Central Server will do the following:

Receive usage information from remote hubs and local scanners Forward usage information to a backup logging server Generate alerts based on anomalous local and global behavior Send alerts to building hubs and local sensors Send alerts to emergency services if deemed necessary

The central server manages its own building, remote buildings and access points. It organizes and categorizes all incoming data and sends out alerts when appropriate. It periodically refreshes the logging server with the latest data. The central server may also handle user/admin web requests for scheduling. A more powerful computer than the Building Hub may be necessary for this module. A computer running Windows XP with 2GB of RAM and 200GB of hard disk space should be sufficient for this task.

1

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Web Admin Module

The Web Administration Module will do the following:

Handle web schedule queries from teachers/aides Allow teachers/aides to view, set and update their schedules Handle web schedule/budget/administrative queries from administrators Allows administrators to view overall statistics and detailed statistics such as

per-patient/per-teacher interaction

The administrative server may or may not be the same as the central server. It acts as a user interface to the scheduling system, allowing users to view and modify their own schedules. For administrators the Web Administration Module will manage users and display an overall view of all schedules and activity.

Logging Server

The Logging Server will do the following:

Receive usage information, alerts, and schedules from the central server Handle long-term backups to tape or other media Synchronize time with the central server

The logging server backs up data from the central server to secure long-term storage. It performs no analysis on the data – only records. This server would not need to be powerful, however it should interface with some more permanent storage such as magnetic tape if deemed necessary.

FlexibilityNetworking for this system would be highly flexible. An infinite number of configurations could be arrived on depending on the number of sensors, servers and hubs deployed. From a user standpoint – this flexibility would be obfuscated during installation. However, there will be some leniency and flexibility that will directly aid the customer.

The following components will be user or customer configurable:

The ability to reprint ID badges in case of a lost or forgotten card The ability to modify times within the database in case of error or

unforeseeable circumstance The ability to add a new patients and therapists The ability to deactivate a patient or therapist when they no longer have a

relationship with the facility The ability to associate a patient with their regular therapist

10

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

If at any time the customer would request more flexibility in certain areas or processes, LB Systems Integration requests the submission of the Change Order form found in this document.

RisksAt LB Systems Integration, we strive to develop solutions that will reduce potential risks – financial, functional or otherwise. The risks that would arise in this primarily occur in an end-user vs. engineer environment. Unforeseen technical risks may arise in the implementation of the product, however the flexibility of the system would allow for considerable deviation in sensor and server placement in order to minimize these chances.

We hope that we have addressed all the administrative needs of the system as is, however there may be conflict in the way in which the user wants to use the product versus the products limitations. We must stress that these problems must be submitted as soon as possible using the Change Order form provided with this document. Changes will have a price – however it is much cheaper to integrate these changes now than two weeks before installation.

Risks pertaining to time constraints will be limited. Time estimates will be as accurate as possible; however there may be unforeseen circumstances. Likewise, budgetary risks will be minimal. Hardware will not need to be developed and is easy integrated within the system.

1

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

FIGURE 2 - RISK BREAKDOWN

10

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Developmental Changes Process

1

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Cross Reference ListingThe following is a numbered list containing the capabilities and deliverables of the proposed system.

1. Provide Scheduling Services by Administration

a. Per Student or Instructor

2. Allow Teachers/Therapists/Users to View Schedules

3. Track actual times of services accurately

4. Store service information safely and securely

5. RFID tracking matrix to track tags throughout a building

6. Administrative interface that allows for

a. Billing

b. Modification

c. Management

7. Secure Web Interface for authorized users

8. Installation of sensors and servers

9. Delivery of Source Code

10.Delivery of Documentation

11.Alert administration of abnormal behavior

12.Distribute campus-wide or directed alerts to scanners

13.Process to create and print RFID tags for replacement

10

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

Integration ThreadThe integration thread that we will be implementing will be focusing around the central server. This will allow both the users of the system and the administrators to have access to the system. The central database will be handled and viewed on the central machine, and shows any information on a status display. Along with this system we will implement a web administration page, so the administrators and users are able to change the settings or view their interactions over the internet.

This will be a good basis for the system to build upon for future expandability. Additional sensors and hubs could be easily added to this design depending on need and cost.

Please note the following:

Blue dashed arrows represent communication signals and small packets of data

Red arrows represent high traffic internal communication Purple arrows represent web communication with external clients Labels on the arrows convey what information is being passed

1

Phase

Tw

o –

Soft

ware

Req

uir

em

en

ts S

peci

fica

tion

| 2

/19

/20

07

SRS Security Policy and Non-Disclosure AgreementPublished: March 23, 2007

LB Systems Integration has implemented policy changes regarding the security of LB Systems Integration Software Requirement Specifications (SRS). LB Systems Integration's purpose for these changes is to protect the value of and investment in the software development and integrity of LB Systems Integration's confidential and trade secret information.

The content of the SRS constitutes confidential LB Systems Integration information protected by trade secret law. Anyone obtaining access to the SRS is obligated to maintain the confidentiality of this information.

By complying with and enforcing this obligation, you help maintain the integrity of LB Systems Integration’s intellectual property. We appreciate your cooperation.

Non-Disclosure Agreement and General Terms of Use

For Software Requirements Specifications

This document is LB Systems Integration confidential and is protected by trade secret law. It is made available to you, the customer, solely for the purpose of appraisal verification. You are expressly prohibited from disclosing, publishing, reproducing, or transmitting this document, in whole or in part, in any form or by any means, verbal or written, electronic or mechanical, for any purpose, without the prior express written permission of LB Systems Integration.

XCustomer Representative