Software Requirements Specification

Software Requirements Specification (SRS)
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

y 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. 1
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)
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.
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 .
Android Developer
Google maps
LOCALE User
Figure 2.1
2.2
y
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 Androids 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.
y y
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 doesnt 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.
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 Requirements
One 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. Network b. GPS signals
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

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

4.1.1: maps Use Case Id:

Use Case name: Actors: Goal: Description: Interface devices: Operational Flow: User starts the locale application on his mobile device or web browser. User identifies application using the browser. application is shown.
UC1
View maps user To identify a particular location The user can view the required location on google maps Mobile device or web browser
User gets the application from the desired location Error: If the user doesnt have the android based phone, application is terminated.
User selects a lcation from the list or The list of places makes the user to provided database. identify the required place Extension: If all places are selected, then option is not shown.
Preconditions: Post conditions:
Location based identifications should be in the system. None
4.1.2 setting remainders
Use Case Id:

Use Case name: Actors: Goal: Description: Interface devices: Operational Flow:
UC2
remainders user To get the remainder of a particular location The user can set the settings based on the remainder Mobile device or web browser User starts the locale application on application is shown. his mobile device or web browser. User identifies application using the browser. User gets the application from the desired location Error: If the user doesnt have the android based phone, application is terminated. User selects a lcation from the list or provided database.
The list of places makes the user to identify the required place Extension: If all places are selected, then option is not shown.
Remainders must be set in the system. None
4.1.3 searching location Use Case Id:

UC3
search user To get a particular location The user can search the required location on google maps Mobile device or web browser
User selects a lcation from the list or provided database. The list of places makes the user to identify the required place Extension: If all places are selected, then option is not shown.
Search option should be provided in the system. None
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been 10 made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
4.1.4 location settings Use Case Id:

UC4
Location settings user To set settings for a particular location The user can set the required location on google maps Mobile device or web browser
Location settings must be done in the system. None
4.1.5 update Use Case Id:

UC5
update user To details for a particular location must be updated The user can set the required location on google maps Mobile device or web browser
updations must be done in the system. None
4.1.6 display Use Case Id:

UC6
display user To details for a particular location must be displayed to user The user can view the required location on google maps Mobile device or web browser
updations must be done in the system. None
Fig: sequence diagram for search
Fig:sequence diagram for maps
Fig: sequence diagram for remainders
Fig: sequence diagram for get location
Fig:sequence diagram for update
Fig:sequence diagram for display
5 Other Nonfunctional Requirements

y 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 Prototype
The 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.
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 doesnt 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 circles 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 Ive 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 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:
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 Wifes 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:
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
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.
y
y
References
Download the Android SDK http://developer.android.com/sdk/index.html Android Developers 2009 Android
y y
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
:.atient login() :Health Care newRecord() Provider
:Medical Record
:Entry
:Basic Info
:Database
:Computer
addBasicInfo()
addEntry()
uploadImage(string filepath)
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been 23 made by Betty H.C. Cheng, Michigan State University (chengb at sync() chengb.cse.msu.edu)
:Health Care Worker
:Patient
:Medical Record login() sync() display()
:Entry
:Basic Info
:Database
:Computer
returnXML() display() downloadImage(image i) returnImage()
commentInfo() commentBasicInfo() commentEntry()
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 systems 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 Patients 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 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.5 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 patients medical record from this state. When a Provider begins editing the data in a Patients 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.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 Prototype
The 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 <http://www.cse.msu.edu/~cse435/Projects/F09/PMRTemplate based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been 27 made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
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.
Figure 5.2.1 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.
Figure 5.2.2 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.3 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.
Figure 5.2.4 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.5 Since the user did not log in yet, everything but Basic Information and Emergency Contacts will be disabled. To log in and see the patients information, the patient will click the Login button. Figure 5.2.6 shows the login screen.
Figure 5.2.6
After logging in the patient will have complete access to the application. Figure 5.2.7 shows the unlocked main screen.
Figure 5.2.7 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.8
In this case, the patients 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.
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.10
7
[1] [2] [3] [4]
References
Download the Android SDK Android Developers http://developer.android.com/sdk/index.html CRC. Update on Meaningful Use CRC Healthcare. November 2009 2009 Android
PIH Model Online. EMR Benefits, Challenges and Uses 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
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.

Software Requirements Specification

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Software Requirements Specification

Încărcat de

Drepturi de autor:

Formate disponibile

Software Requirements Specification (SRS)

Definitions, acronyms, and abbreviations

Assumptions and Dependencies

Fig : class diagram of the system

Fig:usecase diagram that reperesents the system

4.1.1: maps Use Case Id:

Preconditions: Post conditions:

Location based identifications should be in the system. None

4.1.2 setting remainders

Use Case Id:

Preconditions: Post conditions:

Remainders must be set in the system. None

4.1.3 searching location Use Case Id:

Preconditions: Post conditions:

Search option should be provided in the system. None

4.1.4 location settings Use Case Id:

Preconditions: Post conditions:

Location settings must be done in the system. None

4.1.5 update Use Case Id:

Preconditions: Post conditions:

updations must be done in the system. None

4.1.6 display Use Case Id:

Preconditions: Post conditions:

updations must be done in the system. None

Fig: sequence diagram for search

Fig:sequence diagram for maps

Fig: sequence diagram for remainders

Fig: sequence diagram for get location

Fig:sequence diagram for update

Fig:sequence diagram for display

5 Other Nonfunctional Requirements

How to Run Prototype

6.2 Sample Scenarios

:.atient login() :Health Care newRecord() Provider

:Health Care Worker

:Medical Record login() sync() display()

returnXML() display() downloadImage(image i) returnImage()

commentInfo() commentBasicInfo() commentEntry()

How to Run Prototype

S-ar putea să vă placă și