Software Requirements Specification

Software Requirements Specification (SRS)

1 Introduction Recently, mobile phones are one of the most popular devices among people; so that people's life in many aspects is dependent on them. Because of the variety of the usage of mobile phones and their role in our life, investigating and assessing the correctness of their functionalities are very vital. Among platforms for mobile devices, Google's android platform is currently one of the most interesting developments in the mobile phone market. The android platform consists of a Linux-based operating system, middle-ware and a set of core applications. The core applications are most likely part of all produced mobile devices running android and provide access to essential functionality.

This Software Requirements Specification document provides an overview of the functionality of a locale designed for the Android phone. This document will cover the scope, organization, description, constraints, requirements, and the prototype of the locale.

1.1 Purpose

The purpose of this document is to describe the functionality and specifications of the design of a locale application for the Android. The expected audiences of this document are the developers and users of the application.

1.2 Scope

The LOCALE application will be designed to run on the Android. The user will be able to search, access and view the locations from their Android phone. This information will be provided from google maps which is already a running application in many mobiles,since this is a google open source project. The application will then be able to set the different modes for the given location .

1.3 Definitions, acronyms, and abbreviations

Android- The operating system, developed by Google, made to run on cellular phones.

Droid- A smart phone that is currently distributed by Verizon Wireless that runs the latest version of the Android operating system.

GUI (Graphical User Interface) - The part of the application that the user sees and interacts with.

Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)

1

IP Address- A unique number given to every computer on a network to uniquely identify it.

PC (Personal Computer) - A desktop or laptop running the Microsoft windows operating system..

SDK (Software Development Kit) – set of tools that makes it possible to create software for a particular piece of software or hardware, in our case the Android 2.0 operating system.

Thumbnail- A scaled down version of an image used to save space but still allow you to preview the image.

XML (Extensible Markup Language) – A widely used type of text data organization and storage language that use ‘<’ and ‘>’ to label and distinguish sections of data or instructions from each other.

1.4 Organization

The remaining portions of this document are decomposed into four major sections, followed by references and a point of contact. The first section will provide an overall description of the project and the next part will give more detailed requirements. Following the requirements, there are models describing the application and the description/use of the prototype.

2 Overall Description

This section provides a high level description of the entire application. It describes the product perspective, functionality, and characteristics of an expected user, constraints, assumptions and dependencies, and the approportioning of requirements.

2.1 Product Perspective

This application is specifically designed for the Android. There needs to be a GPS based system for the application to access. The interface will be made to have a similar look and feel that is consistent with other Android applications. Most Android applications have a similar way to display and navigate through data. The display that will be implemented by the LOCALE application will be consistent and extended with other applications. This familiar GUI will make the user feel more comfortable navigating and viewing the data on our system.

Our LOCALE application is a part in a larger system. In figure 2.1 you will see that the . application development . Once our application is downloaded into a mobile, it provides the location based settings on which we rely on for future use .


2

2.2 Product Functions

Provides a high-level view of the location details that includes different ringing modes, toggling of wallpapers, location search and emergency contacts.

Provides a means to easily navigate, using the Android’s touch screen interface and keyboard, to the details of any of the location information.

Provides access to different types of media for search including images, text-based documents.

2.3 User Characteristics

The user should be familiar with the basic functionality of the phone. The user should be able to use the touch screen and the other navigation buttons along with the keyboard to input the data. The user will also have to know some basic Google maps terminology and information to understand the application and the different categories.

2.4 Constraints

One major constraint on the application is the amount of memory size that can be used on the phone. The Google maps of Google contain large sized files such a location details, images and different places in a country. These large files can quickly use up a lot of the space available on the Android, so our application doesn’t save these files stored locally. Instead, a thumbnail is saved on the Android and the user can choose to download the image if they feel it is important. This will save space by limiting the amount of images actually stored on the phone.

One other constraint is that this application will not work on other phones. This application will only work on the Android 2.0 operating system. The Motorola Droid is currently the only phone in production that supports Android 2.0.


Android Google maps

LOCALE

Figure 2.1

Developer User

3

2.5 Assumptions and Dependencies

Android 2.0 has a number of features that are included that we can assume our application can utilize. Some important features include a web browser, java support, video and camera, and touch-screen support. Our application will use all of these features and should work on any phone as long as it is running Android 2.0.

We can also assume that all input will only come in three forms, the touch screen, keyboard, and the other buttons found on the Android. Since each phone has its’ unique buttons, we will only use these buttons to end the application and rely on the touch screen and keyboard to perform the rest of the applications navigation.

2.6 Aproportioning of RequirementsOne of the things the customer would like implement is a more robust application on the

computer. The computer side application will only have limited functionality to edit and view the locations. Having a more robust system could offer better navigation, ability to see if a file on the Android or server has changed, or many other features.

Another feature to be added will be a Google earth feature. This will automatically give the location details by using location name as an input.

As of now, to access the LOCALE application on the Android you need to pay some amount of money to the developer. Some customers might want their applications to be more secure so there could be functionality added to improve the security. Some ways to improve security could be to add some security based applications that are available in android market for free, like Mc.afee, webroot

3 Specific Requirements This section provides further details on the specific requirements of our application.

Each requirement is given along with a description of the requirements.

1. Provide a high-level view of the location details. We will have a “front page” where basic location details will be displayed. This front page is designed to be used in case of an emergency. If enter into particular location the application should unknowingly change the mode of ringing for the mobile.

2. Provide a means to easily navigate to the details of any major categories: there is a tabbed user interface where the major topics will be selectable. Once a category is selected, the screen will be refreshed to a separate page where all the relevant information will be displayed in an organized fashion.

3. Provide access to different types of settings for Locale, including:a. Networkb. GPS signals


4

c. Wi-Fi (optional)First, check Android's configuration to ensure that all the necessary location services are enabled. Make sure that Network and GPS locations are both turned on under the Android system settings. Also make sure that Wi-Fi Tethering ("Mobile Hotspot") and Airplane Mode is turned off under the Android system settings.

Second, check the accuracy of the location data that Locale is receiving. To do this, move yourself to the location that you are interested in and create a new Location condition.

4. Locale manages settings based on conditions, like Location and Time. With Locale, never worry about your ringer going off accidentally again! You can set it and forget it! Locale's advanced artificial intelligence algorithms automatically combine cell, Wi-Fi, and GPS signals to accurately determine location without draining the battery.

Locale is an Android application in which you configure situations by specifying conditions like geolocation. Situations trigger actions like changing volume settings or setting your security lock pattern on or off.

.

Fig : class diagram of the system


5


6

4 functional requirements

functional requirements are those that refers to the functionality of the system i.e,what services that it provide to the user.Here we are providing the detailed functional requirements of the system

4.1 usecases

Fig:usecase diagram that reperesents the system


7

4.1.1: maps


8

Use Case Id: UC1

Use Case name: View maps

Actors: user

Goal: To identify a particular location

Description: The user can view the required location on google maps

Interface devices: Mobile device or web browser

Operational Flow:

User starts the locale application on his mobile device or web browser.

User identifies application using the browser.

User selects a lcation from the list or provided database.

application is shown.

User gets the application from the desired location

Error: If the user doesn’t have the android based phone, application is terminated.

The list of places makes the user to identify the required place

Extension: If all places are selected, then option is not shown.

Preconditions: Location based identifications should be in the system.

Post conditions: None

.


9

4.1.2 setting remainders

4.1.3 searching location


10

Use Case Id: UC2

Use Case name: remainders

Actors: user

Goal: To get the remainder of a particular location

Description: The user can set the settings based on the remainder


Operational Flow:









Preconditions: Remainders must be set in the system.



11

Use Case Id: UC3

Use Case name: search

Actors: user

Goal: To get a particular location

Description: The user can search the required location on google maps


Operational Flow:









Preconditions: Search option should be provided in the system.


4.1.4 location settings


12


13

Use Case Id: UC4

Use Case name: Location settings

Actors: user

Goal: To set settings for a particular location

Description: The user can set the required location on google maps


Operational Flow:









Preconditions: Location settings must be done in the system.


4.1.5 update


14


15

Use Case Id: UC5

Use Case name: update

Actors: user

Goal: To details for a particular location must be updated

Description: The user can set the required location on google maps


Operational Flow:









Preconditions: updations must be done in the system.


4.1.6 display


16


17

Use Case Id: UC6

Use Case name: display

Actors: user

Goal: To details for a particular location must be displayed to user

Description: The user can view the required location on google maps


Operational Flow:









Preconditions: updations must be done in the system.



18

Fig: sequence diagram for search

Fig:sequence diagram for maps


19

Fig: sequence diagram for remainders

Fig: sequence diagram for get location


20

Fig:sequence diagram for update

Fig:sequence diagram for display


21

5 Other Nonfunctional Requirements

Backup: For devices running Android 2.2 or later that support Google's Backup Manager, Locale will automatically backup situations in the background. In the event you replace or reset your device, Locale will immediately and automatically restore situations when the app is reinstalled. To use this feature, simply make sure that Google's Backup Manager is enabled by going to Android Settings -> Privacy and verifying that the checkboxes for Backup and Restore are both checked. (If you can't find these settings, then your device doesn't support the Google Backup Manager.) For users running older versions of Android, there is a beta backup and restore feature that can be enabled by given instructions.

Security: Locale plug-in that switches your security unlock pattern on or off based on configured conditions, like your location. Locks your phone with the Android lock pattern screen when your leave your home and unlocks it when you get back.

6 Prototype

The prototype of this Android application will encompass the basic functions of the completed application. This will include most of the features on the Android phone, as well as the form used by a health care provider. The main functions on the Android will include downloading a data file from the server, viewing the file in separate categories, and editing sections of the data file. The application will also include buttons to upload the data files to both the server and a PC as a backup file. The server side will include a template located online to input information that will generate an XML based file. This file will then be downloaded by the application on the phone when it is started. The server will also contain example pictures that will be viewable on the phone.

6.1 How to Run PrototypeThe primary way to view this application is to download the Android emulator to your home or office computer. Windows, Mac, and Linux systems are all able to access this emulator. You will find information that will help you download and install the emulator at <http://developer.android.com/sdk/index.html>. You will need to download an SDK tool to run the emulator. The Motorola Droid is running SDK 2.0, which is what the application has been running on. There are more links under the SDK tab on the android development website that will further assist you in downloading and installing the emulator.

A Microsoft Powerpoint presentation has been set up if this option is not feasible for you. This presentation provides screen captures of each of the viewable screens on the application.


22

6.2 Sample Scenarios

Location-based settings:

The first example that comes to mind is location-based. With Locale I can always be

sure that my phone doesn’t ring in Church. You can use the map to define a location.

The location appears as a highlighted circle:

This screen makes great use of the Android interface. You can drag the thumb tack

around the screen, or drag the circle’s border to resize the location. You do not have to

have GPS turned on for this feature to work. It can determine your location based on the

Cell tower your phone is connected to. This is not as accurate as GPS, but works well for

my Church mode.

Once I’ve defined the condition (at Church) I can add the settings I want. The first one is

obviously Volume set to silent. But I can also change my wallpaper to something more


23

heavenly, turn on/off GPS, Bluetooth, or Wi-Fi and even choose how it notifies me of my

location change.

Time-based settings:

Another situation I defined is Night Time. I set locale to set my phone to silent mode between the hours of 11 pm and 8 am.This way I will not be disturbed by phone calls in the evening. You could also use this to have a work-appropriate ringtone

From this screen you can select a start and end time as well as the days of the week. In the following example the condition is st for 8 am to 6 pm for Monday through

Friday:


24

Contact-based settings

My Night Time setting is nice, but I worried what would happen in case of an

emergency. So I added another situation called Wife. When any of my Wife’s contact

numbers contact me, the ringer turns on. You can select multiple contacts at one time.

Managing Situations

Locale handles multiple situations by giving priority to the first one listed, so in this

example:


25

My phone is silent when I am in Church. Between the hours of 11pm and 8am my phone

is silent except when I receive a call from my wife. It will ring at night when it is from

her, but not at Church.

You can also see that the Home situation is currently disabled. You can also use this

screen to see if any of the conditions are currently active. When active, the situation

name appears in bold

You can also change the order of the situations from the manage screen


26

You move the situation by dragging the dots (looks like a textured area) to the position

you want, or into the trash can to delete.

I wish you could set a setting for when the condition ends (that is, when I leave Church)

but that is not an option. However I can set defaults. I set the default for my ring

volume, so whenever a condition is not met, my ringer is on. Unfortunately this can

yield less than ideal results. While at a conference in Vegas, my ringer turned on at

10am in the middle of a presentation, because it was no longer “night”.

Locale has become one of my essential applications. It makes an excellent use of the

Android interface and provides a lot of flexibility in configuring. The program is fairly

intuitive and defintitely worth the time to experiment with.


27

References

“Download the Android SDK” Android Developers 2009 Android http://developer.android.com/sdk/index.html

Ilie, Virginia, Courtney, James, and Slyke, Craig. “Paper vs. Electronic: Challenges Associated with Physicians’ Usage of Electronic Medical Records”. Hawaii International Conference on System Science. 2007

Licenses Android Open Source Project. Open Handset Alliance http://source.android.com/license. Retrieved on 22 October 2008

for getting detailed information on Android http://code.google.com/android


addEntry()

newRecord():Health Care Pro…vider

:….atient…

:Medical Record :Entry :Basic Info :Computer:Database

editInfo()

addBasicInfo()

login()

sync()

uploadImage(string filepath)

28


:Health Care

Worker

:Patient :Medical Record :Entry :Basic Info :Computer:Database

login()

display()downloadImage(image i)

commentInfo()commentBasicInfo()commentEntry()

sync()

display()

returnImage()

returnXML()

29

The following diagrams (Figures 4.5 and 4.6) illustrate the behavior of our “Patient” and “Health Care Provider” classes, respectively. The Patient object initially executes the “login” function when starting the program, and enters the “Patient Logged In” state upon successful authentication. In this state, the Patient automatically executes the “sync” function, which updates the data on the Droid device to match that on the system’s database server (and if there is still unsaved Patient-edited data on the Droid device, uploads that data to the database). The Patient also executes the “display” function from this state automatically, which displays the data from the Patient’s medical record on the screen of the Droid device.

The Patient can also change his or her data from the “Patient Logged In” state in two main ways. First, the Patient can upload an image file and attach it to an entry in the medical record. This happens when the “UploadImage” function is executed by the user and the Patient enters the “Uploading Image” state. When the image has finished uploading, the Patient enters the “Local Patient Info Changed” state. Similarly, from the “Patient Logged In” state, the Patient can make a comment on an entry in the medical record when the “commentInfo” function is executed by the user and the Patient enters the “Commenting on Info” state. When the Patient finishes the comment, he or she enters the “Local Patient Info


30

Changed” state, and the commented information is flagged as edited by the Patient. From the “Local Patient Info Changed” state, the Patient can execute the “sync” function to upload the data back to the database. The Patient can log out of the system from either the “Patient Logged In” or the “Local Patient Info Changed” states – in the latter, the changed data is stored on the Droid device until the Patient logs in again.

Figure 4.6 shows the state diagram for the Health Care Provider class. Initially, the Health Care Provider logs into the system using the “login” function and enters the “HC Provider Logged In” state upon successful authentication. A Health Care Provider can add a new Patient to the system from here by executing the “addPatient” function from the interface. The Provider can also display a patient’s medical record from this state. When a Provider begins editing the data in a Patient’s medical record, the “EditInfo” function is executed and the Provider enters the “Editing Info” state. When the editing is complete, the Provider executes the “syncInfo” function, and returns to the “HC Provider Logged In” state. The Provider can also log out of the system from this state by executing the “Logoff” function.


Figure 4.5

31

6 Prototype

The prototype of this Android application will encompass the basic functions of the completed application. This will include most of the features on the Droid phone, as well as the form used by a health care provider. The main functions on the Droid will include downloading a data file from the server, viewing the file in separate categories, and editing sections of the data file. The application will also include buttons to upload the data files to both the server and a PC as a backup file. The server side will include a template located online to input information that will generate an XML based file. This file will then be downloaded by the application on the phone when it is started. The server will also contain example pictures and/or medical documents that will be viewable on the phone.

6.1 How to Run PrototypeThe primary way to view this application is to download the Android emulator to your home or office computer. Windows, Mac, and Linux systems are all able to access this emulator. You will find information that will help you download and install the emulator at <http://developer.android.com/sdk/index.html>. You will need to download an SDK tool to run the emulator. The Motorola Droid is running SDK 2.0, which is what the application has been running on. There are more links under the SDK tab on the android development website that will further assist you in downloading and installing the emulator. Source code for this application will be located on the project website under the Prototype section <http://www.cse.msu.edu/~cse435/Projects/F09/PMR-droid/web/Prototype/pmr.zip>.

A Microsoft Powerpoint presentation has been set up if this option is not feasible for you. The link to this presentation is


Figure 4.6

32

<http://www.cse.msu.edu/~cse435/Projects/F09/PMR-droid/web/proto-2.html>. This presentation provides screen captures of each of the viewable screens on the application.

6.2 Sample Scenarios

If a doctor wants to add a patient to the PMR database, the doctor will have to go to the form. Figure 5.2.1 shows the first blank screen that a doctor would see.

To add information, the doctors will have to simply type in the information. Figure 5.2.2 represents input for the basic information such as name and address.

For basic info, all they need to do is type in the information. However, entries such as medications or vaccinations, they need to click on “Add (Entry name)” to add the info to the output file. Figure 5.2.3 shows where the button is.


Figure 5.2.1

Figure 5.2.2

33

After inputting all the data, doctors will then save the information to a file the server by clicking on “Submit All” button. This button will save the information as an XML file. Figure 5.2.4 shows where the “Submit All” button is.

Since the data was saved in the server, the client will have access to this data. When the patient first open up the application, the patient will see a screen that looks like Figure 5.2.5.


Figure 5.2.3

Figure 5.2.4

34

Since the user did not log in yet, everything but Basic Information and Emergency Contacts will be disabled. To log in and see the patient’s information, the patient will click the “Login” button. Figure 5.2.6 shows the login screen.


Figure 5.2.6

Figure 5.2.5

35

After logging in the patient will have complete access to the application. Figure 5.2.7 shows the unlocked main screen.

Now the patient wants to see their basic information. All they need to do is click on the basic information to go to basic information screen. Figure 5.2.8 shows the basic information screen.


Figure 5.2.7

Figure 5.2.8

36

In this case, the patient’s name is John Smith, not John Doe as shown in Figure 5.2.9. This means that the patient needs to comment or edit the last name. To do so, the patient will click on Edit button to go to the edit screen shown in Figure 5.2.9.

After changing the name, the user has two options. The first option is to click the button “Return with Unchanged Data” and have all changes reverted. The second option is to click the “Done Editing” button to change the data as shown in Figure 5.2.10


Figure 5.2.9

Figure 5.2.10

37

7 References

[1] “Download the Android SDK” Android Developers 2009 Android http://developer.android.com/sdk/index.html

[2] CRC. “Update on Meaningful Use” CRC Healthcare. November 2009

[3] PIH Model Online. “EMR Benefits, Challenges and Uses”

[4] Ilie, Virginia, Courtney, James, and Slyke, Craig. “Paper vs. Electronic: Challenges Associated with Physicians’ Usage of Electronic Medical Records”. Hawaii International Conference on System Science. 2007

8 Point of Contact

For further information regarding this document and project, please contact Prof. Betty H.C. Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this document have been sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation of our industrial collaborators.


38

http://developer.android.com/sdk/index.html

Software Requirements Specification

Documents

Transcript of Software Requirements Specification