Senior Reminder System Project (Remind Me!)chung/CS4351...Senior Reminder System Project (Remind Me!) World Requirements Specification SE 4351 – Requirements Engineering, Section

Senior Reminder System Project (Remind Me!)

World Requirements Specification

SE 4351 – Requirements Engineering, Section 001 September 28, Fall 2015

Milton Bland, [email protected] Zachary Calman, [email protected] Ridge Frederick, [email protected] Grant Freeman, [email protected] Brad Gracy, [email protected]

Jeanie Handler, [email protected] Maria Haney, [email protected] Justin Keeling, [email protected] Mazen Lawand, [email protected]

Maryellen Oltman, [email protected] Kevin Szwagiel, [email protected]

Andrew Vaccaro, [email protected] Dalton Wooley, [email protected] Phillip Yellott, [email protected]

Team Website: http://www.utdallas.edu/~atv130330 This document is for reference only,

latest documents are always on the website above.

mailto:[email protected]













http://www.utdallas.edu/~atv130330

Revision History

Version Date Comments Author

1.0 September 9, 2015

Initial Version. Milton Bland, Zachary Calman, Ridge Frederick, Grant Freeman, Brad Gracy, Jeanie Handler, Maria Haney, Justin Keeling, Mazen Lawand, Maryellen Oltman, Kevin Szwagiel, Andrew Vaccaro, Dalton Wooley, Phillip Yellot

1.1 September 17, 2015

Removed Architectural Specification. Revised to World Requirements Specification.Changed Project Title

Dalton Wooley, Milton Bland, Jeanie Handler

1.3 October 1st, 2015

Changes made based on presentation results.

Dalton Wooley

1.5 November 7th, 2015

Preparation for Phase 2 Part 1 Submission. Added tradeoff analysis.

Dalton Wooley, Milton Bland, Mazen Lawand

1.6 December 1st, 2015

Preparation for Phase 2 Part 2 Submission. Addressed Grace’s concerns.

Dalton Wooley Milton Bland

1.7 December 1st, 2015

Rectified UML diagram, Added Activity Diagram

Jeanie Handler

Process

1. Project organization

1.1 Process model This project shall use the Waterfall model as its process model, except it shall execute in stages. These stages are associated with the two phases of the project, and each phase shall have its own waterfall process. We have chosen the Waterfall model because we know the requirements shall not change in the middle of the phase so it shall be the most efficient process.

1.2 Organizational structure Our team shall consist of threefour teams with a total of 14 members who shall work in tandem

Documentation Team Milton Bland Documentation Manager Jeanie Handler Documentation Manager Dalton Wooley CoProject Manager, Documentation Manager

Development Team 1 Ridge Frederick Developer Grant Freeman CoProject Manager, Developer Brad Gracy Developer Maryellen Oltman Developer

Development Team 2 Justin Keeling CoProject Manager, Developer Kevin Szwagiel Developer Andrew Vaccaro Webmaster, Developer Phillip Yellot Developer

Development Team 3 Zachary Calman Developer, Testing Developer Maria Haney Developer, Testing Developer Mazen Lawand CoProject Manager, Developer

1.3 Organizational boundaries and interfaces Due to the small team size, one team member shall be delegated to each task. The unused team member shall review and make revisions where necessary.

1.4 Project responsibilities Both CoProject Managers shall be involved with all phases of both portions of the project.

Co-Project Manager (CPM) The CPM shall be responsible for managing the deliverable schedule and ensuring completion by due date.

Documentation Manager (DM) The DM shall be responsible for all documentation and documentation control.

Developer The Developer shall be responsible for the entirety of design and implementation of the software system. The developer shall also be responsible for meeting all scheduling as designated by the CPM.

Webmaster The Webmaster shall be responsible for uploading and managing deliverables onto the team website. The deliverables shall be ready on the team website by the due date.

Testing Developer The Testing Developer shall work with the DM and CPM to create, document, and save test cases and their results.

2. Managerial process

2.1 Management objectives and priorities Management, which comprises of the CoProject Managers, is responsible for getting activities completed efficiently and effectively. The main objective of the management is to organize the meetings for discussions, check the status of the project, and submit the project on time. The main objectives are:

● Scheduling ● Directing ● Reviewing ● Submitting Deliverables

2.2 Assumptions, dependencies, and constraints

Assumptions ● Any difficulty with an assigned task is to be communicated to the other team member ● The professor/end customer shall not make changes in the requirements or scope ● Professor/end customer shall clarify any doubts, concerns, or uncertainties

Dependencies ● Each CPM is reliant upon the developer to finish their duties on schedule ● Each developer is reliant upon the CPM to clearly delegate their tasks and their schedule ● The Webmaster is reliant on the DM to provide the deliverables to upload to the team

website

Constraints ● The time frame of 6 weeks for the project shall make scheduling essential to project

completion ● The time frame of 6 weeks for the project shall make understanding of the Android SDK

essential to task completion to schedule ● The quality of the project is dependent upon the requirements of the project

2.3 Risk management

Risks and Contingency Plans ● One of the team members is unable to complete his task on schedule

○ The team member shall be responsible for communicating this issue to the other team member so they can complete the task on schedule.

● Loss of project data or progression ○ Project documents shall be hosted in the cloud. Project source code shall be

version controlled using Git and hosted on GitHub. ● Lack of experience or skill in a required area

○ The team members shall be responsible for researching the skill using resources such as the Internet, the professor, oncampus resources.

● Poor quality ○ Each team member shall review the other team member’s work to ensure that it

fulfills quality requirements. ● Change in requirements

○ Team members shall adjust the schedule and requirements to meet any changes.

● Failure to complete project ○ Team members shall adhere to the schedule and complete tasks on time to

ensure the project is completed.

2.4 Monitoring and controlling mechanisms Each delivery phase shall be lead by both CoProject Managers. Project documents and deliverables shall be controlled with online cloud hosting and version control such as Google Drive and GitHub.

2.5 Meetings On a weekly basis, each CPM will review and meet with their team as necessary. If nothing is scheduled to be completed before the next meeting, then the meeting is not required. Meetings will be scheduled over SMS for all team members who can attend.

3. Technical process

3.1 Methods, tools, and techniques

Tools The following tools shall be used for development of documentation and code:

● Java: The development language for program implementation ● Google Drive: The document editor and cloud host for documentation ● Sqlite API: The preexisting API used for persisting events ● Android Studio: The IDE used for writing source code and porting to android system ● Git: The version control system for source code ● GitHub: The cloud host for our git repository ● SMS: Our main form of communication

Techniques Software development shall follow standard Java naming convention and ObjectOriented structure.

3.2 Software documentation The following documentation shall be written:

● Project Plan

Phase I ● World Requirements Specification ● Program Specification ● User Manual

Phase II ● World Requirements Specification ● Process Specification ● Vision Document ● Program Specification ● User Manual

3.3 Project support functions ● Version Control

○ Source code shall be version controlled with Git and GitHub. ● Quality

○ The GitHub issue tracker shall be used to keep track of issues and tasks that need to be completed.

● Documentation ○ Google Drive shall be used to write all documentation.

Introduction

Purpose The purpose of this document is to compile all documentation on the SE 4351 Preliminary Project Phase II, or the Senior Reminder System Project. This documentation will include the Requirements Specification containing the functional and nonfunctional requirements for this project, the Program Specification containing the implementation of the project, the Process Specification and the User Manual. Having all of this documentation will outline for the reader the motivations and decisions that shaped the development of this project.

Scope The project is defined by the boundaries of the selection process and our narrowing of the project definition. Project selection was completed by meeting together and each person suggesting an idea. After discussion of the upsides and downsides of the various ideas, our team came to a unified agreement on a reminder system. Review of the project goals, deliverables, tasks to complete, their associated costs and deadlines, further narrowed our project to a precise application idea.

Objectives and Success Criteria The goal of this project is to create an Android App to help elderly people manage events and important tasks like taking their medicine. In order to better define the behavior of this system, we devised a Requirements Specification further clarifying what functionality this system is required to fulfill, such as functionality and constraints. Furthermore, we specified that this system was to be implemented using a SQLite database.

Problems The largest problem in successfully creating an App for the domain of this project is that inherently as age increases, familiarity with the latest technology decreases. Our team will have to create an App that is extremely easy to use, even for users with declining motor skills, eye sight, and memory. The App will have to be easy to access, easy to use, while avoiding letting the user unintentionally modify items.

Goals As a group we have decided that our two main goals are to create an App that is effortless to access and very intuitive to use. If the user can’t remember the exact workings of the app, we want it to be intuitive and natural to use so they are still able to use it. This will be a tremendous goal because it means that the user only needs to remember they have the App and none of the details of use. Some of our lesser goals are: creating object persistence that supports useful features, giving a caregiver an easy to way to supplement the user’s use of the App, and easy ways to navigate the app like voice search.

Definitions

SR - Senior Reminder The formal title of our phase 2 project abbreviated for ease of writing and reading.

Android Mobile Operating System developed by Google Inc.

Object-Oriented A methodology that enables a system to be modeled as a set of objects that can be controlled and manipulated in a modular manner.

App A program or piece of software designed and written to fulfill a particular purpose of the user.

Category A category is a descriptor containing the multidimensional vocabulary items having a similar meaning, relation and/or purpose.

Reminder A small collection of data about an important event that includes a task and time.

Disjoint Category A disjoint category is one that does not have its items overlap with any other category.

Overlapping Category An overlapping category is one that has one or more of its items overlap with items in other categories. Categories can be either activitybased or itembased at the root level e.g. items as in ‘Food’, ‘Drink’, ‘People’ etc. and activities like ‘ I want to eat’, ‘I want to go’ etc.

Preliminary Domain

Overview Our team is to architect and implement an Android. The goal of this system is to allow management of notifications and reminders for the visually impaired and those with moderate Alzheimer's disease (middlestage). Problem 1. Assist the elderly with problems of vision loss, moderate Alzheimer's disease (middlestage), and muscle weakness with daily living functions. Problem 2. Utilize visual aids to communicate with elderly users with vision impairment and moderate Alzheimer's disease (middlestage). Problem 3. Use a sorting of categories of actions and items to assist the user in selection of tasks. Problem 4. Handle emergency situations with efficiency and quickness.

Problem 5. Provide a usable search option to easily navigate the system.

Issues with Preliminary Definition

PD 1. Assist the elderly with problems of vision loss, memory loss, and muscle weakness with daily living functions. Issue 1: Definition scope is too broad. Needs to be focused to a smaller subset of the problem. Issue 2: Apps are most useful when handling a well defined problem as opposed to a broad one such as elderly health issues.

PD 2. Utilize visual aids to communicate with elderly users with vision impairment and memory loss. Issue 1: Definition scope is too broad. Needs to be focused to a smaller subset of the problem. Issue 2: Time to implement is not sufficient to address all forms of vision impairment and memory loss.

PD 3. Use a sorting of categories of actions and items to assist the user in selection of tasks. Issue 1: It will be difficult to define categories that are meaningful and unique (due to overlapping categories). Issue 2: Creating new categories might lead to user difficulty in allocating tiles.

PD 4. Handle emergency situations with efficiency and quickness. Issue 1: It will be difficult to define what is an actual emergency issue 2: It will be difficult to detect when an emergency happens

PD 5. Provide a usable search option to easily navigate the system. Issue 1: Search function will not be a useful addition to the app. Issue 2: Voice Search will consume an excessive amount of resources that may be detrimental to the overall. Issue 3: Voice analysis and detection will have to be performed by an outside service because that single function alone exceeds the resources of our team.

Trade-Off Analysis Our team met and decided on a notification application for elderly users. Our team , and it needs to make a decision about decided on two approaches to choose from:

Program Scenario A: A mobile application for the Android OS that will assist users in remembering important tasks like taking their medicine on time. Tasks will be saved locally to the phone using embedded SQLite.

Program Scenario B: A mobile application for the Android OS that will act as a userfriendly interface to the Google Calendar API. It will take advantage of existing structures to save tasks in the cloud. The added bonus is a trusted user can add their event calendar and act as a caretaker. The following illustrates the steps we took for performing our tradeoff analysis.

Step 1: Identify important features to consider in the features, design, and implementation of the system, then weight each criteria as to its importance, with a weight of 1 being low and 9 being high.

Step 2: For each of the program scenarios, rate, on a scale of 1 to 9, with 1 being the worst and 9 being the best, how well each program scenario fulfills each of the feature criteria.

Step 3: Multiply the rating given to calculate how well each scenario will impact a decision by feature importance.

Step 4: Add up the results of Step 3 for each of the program scenarios and compare the totals for each program scenario. The scenario with the highest score is the one that we selected. These steps are followed below and with the total of 246, Program Scenario A is the best. Our tradeoff analysis was performed by a subset of our entire group one time.

Program Scenario A

Feature Criteria Column A Weight of Importance

Column B Feature Rating

Column A x

Column B

Service will improve quality of life for users

7 7 49

Program will be implementable in the project time period

9 9 81

Program will center around an easy to use interface

9 9 81

Program makes use of existing APIs

5 7 35

Total 246

Program Scenario B

Feature Criteria Column A Weight of Importance

Column B Feature Rating

Column A x

Column B

Service will improve quality of life for users

9 7 63

Program will be implementable in the project time period

3 3 9

Program will center around an easy to use interface

5 5 25

Program makes use of existing APIs

7 9 63

Total 160

Functional Requirements 1. The SR system shall display a visual tile interface for interacting with reminders.

1.1. The SR system shall allow the user to customize reminders to make them more meaningful.

1.1.1. The SR system shall allow image association to individual reminders. 1.1.2. The SR system may associate a graphic with each tile to reduce

ambiguity. 1.2. The SR system shall create reminders.

1.2.1. The SR system may fill in reminder information through voicetotext. 1.2.2. The SR system shall persist the reminder in using Sqlite.

1.3. The SR system shall update reminders. 1.3.1. The SR system shall allow modification of the reminder information. 1.3.2. The SR system shall update the reminder in the Sqlite database.

1.4. The SR system shall delete reminders. 1.4.1. The SR system shall ask for confirmation before deletion. 1.4.2. The SR system shall delete the reminder in the Sqlite database.

1.5. The SR system shall retrieve reminders for viewing.

1.5.1. The SR system may retrieve the reminder information from the Sqlite database.

2. The SR system shall require an emergency contact phone number. 2.1. The SR system shall contact the emergency contact through SMS in the case of

missed reminders. 3. The SR system shall notify the user through the Android system about reminder events.

3.1. The SR system shall push notifications at requested times. 3.2. The SR system shall play alarms at requested times. 3.3. The SR system may notify emergency services when requested.

3.3.1. The user may define emergency services to be a service other than 911. 3.3.2. The SR system may provide a quick access key to 911 services.

4. The SR system shall use categories of reminders to aid in selection. 4.1. The SR system shall provide an order by category filter.

4.1.1. The SR system shall perform a first sort by category. 4.1.2. The SR system shall perform a second level sort by event time.

4.2. The SR system shall only store the category identifier. 4.2.1. The SR system may allow the category names to be modified.

5. The SR system may utilize a search interface. 5.1. The SR system may search by the reminder name. 5.2. The SR system may support voice search.

5.2.1. The SR system may utilize Android native voicetotext to enter in search terms.

5.2.2. The SR system may only support the English language. 6. The SR system shall by default display the most relevant reminders.

6.1. The SR system shall display reminders in an ordered list. 6.1.1. The SR system shall display in ascending order.

6.2. The SR system shall determine relevance by the event time. 6.2.1. The SR system shall store the event time in the reminder. 6.2.2. The SR system shall require an event time for all reminders.

Non-Functional Requirements 7. The SR system shall be easily understood.

7.1. The SR system shall be well commented. 8. The SR system shall be portable.

8.1. The SR system shall be able to run on any system that supports Android API 15/Version 4.0.3.

9. The SR system shall be enhanceable. 9.1. The SR system shall facilitate future additions to the source code

9.1.1. The SR system shall have a simple build system. 9.1.2. The SR system shall be open sourced.

9.2. The SR system shall use an Object Oriented Architecture. 10. The SR system shall be reusable and adaptable.

10.1. The SR system shall abstract all method calls to the Sqlite database

11. The SR system shall have good performance and be responsive. 11.1. The SR system shall be fast.

11.1.1. The SR system shall complete its tasks in less than 0.5 seconds. 11.2. The SR system shall minimize memory usage

11.2.1. The SR system shall avoid making unnecessary copies of data in memory 12. The SR system shall be userfriendly.

12.1. The SR system shall be errorfree 12.1.1. The SR system shall complete executing without any errors. 12.1.2. The SR system shall be well documented. 12.1.3. The SR system shall have a User Manual that explains how to use the

system. 13. The SR system shall use simplistic interfaces.

13.1. The SR system shall use visible high contrast icons. 13.1.1. The SR system shall only display icons that are in contrast to the user

interface placed behind it. 13.2. The SR system shall use tiles with consistent coloring and images to visually

organize. 13.2.1. The SR system shall have a coloring scheme. 13.2.2. The SR system shall have a set of distinct images associated with each

type of reminder.

Diagrams

UC1. Use Case Diagram covering Interactions of multiple Actors with the Senior Reminder System based on Functional Requirements.

SD1. Sequence Diagram Create Reminder based on Use Case Create Reminder.

SD2. Sequence Diagram View Reminder based on Use Case View Reminder.

SD3. Sequence Diagram Edit Reminder based on extendable Use Case Edit Reminder.

SD4. Sequence Diagram Delete Reminder based on extendable Use Case Delete Reminder.

SD5. Sequence Diagram Notify Reminder based on Use Case Notify Reminder.

SD6. Sequence Diagram Emergency Notification based on Use Case Emergency Notification.

SD7. Sequence Diagram Failed Notify Reminder covers when the User does not respond to notification alert.

CD1. Class Diagram documents current implementation and traces dependencies between classes.

Process Specification

AD1. Activity Diagram.

SG1. SoftGoal Interdependency Graph covers Nonfunctional Requirements.

PG1. Problem Interdependency Graph describes key issues that could arise.

Traceability

World Traceability Matrix

World

Problem

ID

Problem

Description Goal ID Goal Description

1

Senior Forgot

Some Task 1 Acceptability

2

Senior Does Not

Receive Regular

Assistance 2 Availability

3

Ineffective

Reminder 3 Reliability

4 Alert 4 Low Cost

5 No Portability 5 Security

6 Lost Schedule 6 Portability

Requirements

Preliminar

y FR ID

PFR Description

FR ID FR Description

1

Visual

Interface/CRUD 1 Visual Interface/CRUD

2

Emergency

Contact 2 Emergency Contact

3 Notifications 3 Notifications

4 Voice Interface 4 Categories

5 Categories 5 Search

6 Empty 6 Ordering

7 Empty

Preliminar

y NFR ID

PNFR

Description NFR ID NFR Description

Operationalize

d FR ID

Operationalize

d FR Desc

8

Understandabilit

y 7 Understandability 1, 2, 3, 4, 5, 6 All FR

9 Portability 8 Portability 1 and 3

Visual

Int/CRUD,

Notif.

10 Enhanceability 9 Enhanceability 1, 2, 3, 4, 5, 6 All FR

11 Reuseability 10 Reuseability 1, 3, 4, 6

Vis. Int./CRUD,

Notif., Cat.,

Order

12 Performance 11 Performance 1, 3, 4, 6

Vis. Int./CRUD,

Notif., Cat.,

Order

13 User-Friendly 12 User-Friendly 1, 3, 4, 6

Vis. Int./CRUD,

Notif., Cat.,

Order

14 Interface 13 Interface 1, 3, 4, 6

Vis. Int./CRUD,

Notif., Cat.,

Order

Specification

Progra

m

FSpec ID

Functional

Specification

Proto

Type ID Proto Type Description

1

View/Select

Reminders 1 MainActivity

2

Handle data

persistence 2 SQLite API

3

Interact with

OS/GUI 3 Android API

4 CRUD Reminders 4 CreateReminderActivity

5

Data Object

Model 5 Reminder

6

Pushes

Notifications 6

ReminderBroadcastReceiv

er

7

Abstracts

Database

Operations 7 ReminderDatabaseHelper

8

Sends SMS

notifcation 8 SmsBroadcastReceiver

9 Edit contact info 9

ReminderPreferenceActivi

ty

NFSpecID NF Specifcation

Proto

Type ID

1

Understandable

Code

1, 2, 3,

4, 5, 6,

7, 8, 9

2 Portable Code 3

3

Enhanceable

Code

1, 2, 3,

4, 5, 6,

7, 8, 9

4

Reusable Code

Modules

1, 2,

and 3

5

Good System

Performance

1, 2,

and 3

6

User-Friendly

GUI

1, 2,

and 3

7

Elderly oriented

interface

1, 2,

and 3

*terms

Requirement Volatility Traceability from Project 1 to Project 2

Requirement Added Modified Removed Description of change

Unchanged

1 x

1.1 x

1.1.1 x

1.1.2 x x 1.1.2 was deleted and 1.1.3 was relabeled to 1.1.2

1.1.3 x 1.1.2 was deleted and 1.1.3 was relabeled to 1.1.2

1.2 x Google Calendar API was replaced with SQlite API.

1.2.1 x Google Calendar API was replaced with SQlite

API.

1.2.2 x Google Calendar API was replaced with SQlite API.







1.5 x Google Calendar API was replaced with SQlite

API.


2 x

2.1 x

3 x

3.1 x

3.2 x

3.3 x

3.3.1 x

3.3.2 x

4 x x Voice Command requirement was removed due to scope issues. Categories requirement is now FR 4.

4.1 x FR 4 needed further definition

4.1.1 x FR 4.1 needed further definition


4.2 x FR 4 needed

further definition


5 x Added support for search functionality, implementation will not be available in this version.





6 x Ordering was not defined in original project. Added requirement for ordering of items.






7 x All NFR IDs lowered by 1.

x

7.1 x

8 x

8.1 x

9 x

9.1 x

9.1.1 x

9.1.2 x

9.2 x

10 x

10.1 x

11 x

11.1 x

11.1.1 x

11.2 x

11.2.1 x

12 x

12.1 x

12.1.1 x

12.1.2 x

12.1.3 x

13 x

13.1 x

13.1.1 x

13.2 x

13.2.1 x

13.2.2 x

Requirement to Implementation Traceability Requirement Identifiers

Req Tested

MainActivity

SQLite API

Android API

CreateReminderActivity

Reminder

ReminderBroadcastReceiver

ReminderDatabaseHelper

SmsBroadcastReceiver

ReminderPreferenceActivity

Unimplemented

Test Cases 73

Tested Implicitly 93

1 1 x

1.1 1 x

1.1.1 1 x

1.1.2 1 x

1.2 3 x x x

1.2.1 3 x x x

1.2.2 3 x x x

1.3 3 x x x

1.3.1 3 x x x

1.3.2 3 x x x

1.4 3 x x x

1.4.1 3 x x x

1.4.2 3 x x x

1.5 3 x x x

1.5.1 3 x x x

2 1 x x

2.1 1 x x

3 2 x x

3.1 2 x x

3.2 2 x x

3.3 2 x

3.3.1 2 x

3.3.2 2 x x

4 3 x x x

4.1 3 x x x

4.1.1 3 x x x

4.1.2 3 x x x

4.2 3 x x x

4.2.1 3 x x x

5 0 x

5.1 0 x

5.2 0 x

5.2.1 0 x

5.2.2 0 x

6 1 x

6.1 1 x

6.1.1 1 x

6.2 1 x

6.2.1 1 x

6.2.2 1 x

7 8 x x x x x x x x x

7.1 8 x x x x x x x x x

8 1 x

8.1 1 x

9 8 x x x x x x x x x

9.1 8 x x x x x x x x x

10 8 x x x

10.1 1 x

11 3 x x x

11.1 3 x x x

11.1.1 3 x x x

11.2 3 x x x

11.2.1 3 x x x

12 3 x x x

12.1 3 x x x

12.1.1 3 x x x

12.1.2 3 x x x

12.1.3 3 x x x

13 3 x x x

13.1 3 x x x

13.1.1 3 x x x

13.2 3 x x x

13.2.1 3 x x x

13.2.2 3 x x x

Program Specification The program specification for this project is available in the src/ directory of the deliverable .zip this document came in, or from our project website: http://www.utdallas.edu/~atv130330

http://www.utdallas.edu/~atv130330

User Manual

Chapter 1: RemindMe! Introduction This is an app designed with the elderly in mind, but can benefit anyone! It’s a simple app that can help a person keep track of everything they need to do. Let’s learn how to use it!

1.1: App Layout

The app has three main buttons. On the left there is a “NEW BUTTON” rectangle which can be pressed to add new events, there is an “Event” box which can be clicked to look at certain types of events, and then there is the three dots on the top right which allows the users to go to the settings. Once an event is added it will appear right in the middle of the screen below the two buttons.

1.2: App Functionalities Here are a few highlights of RemindMe!

● Add event reminders ● Events can be sorted by type ● Images can be added to an event ● Notifications can appear as reminders

Chapter 2: Getting Started In this section, you will get a jump start on creating your first reminder.

2.1: Creating Your First Reminder The following steps will guide you to create your first reminder: 1. From the main screen, tap NEW BUTTON to start creating a new reminder.

2. Fill in details about the reminder including the time. If you click the Image button you can upload an image with the reminder.

3. Tap on Save when done.

Congratulations, you have successfully created your first reminder! Reminders can be viewed and sorted from the app’s home screen. You can create a reminder for anything you want to remember.

Chapter 3: Viewing Your Reminders In this section, you will learn how to view your reminders two different ways.

3.1: Viewing Reminders by Event Type The following steps will guide you to viewing your reminders by event type: 1. From the main screen tap on Event and then click on the event type you would like to view.

2. Tap on the event type you would like to view.

3. You can tap the reminder to bring up more details of this event.

Chapter 4: Managing Reminders In this section, you will learn how to edit and delete reminders.

4.1: Editing a Reminder The following steps will guide you to editing the details of an already existing reminder. 1. When viewing your reminders, you can simply tap on an existing reminder to bring up the details of that event.

2. From this screen you can edit the time, name, description, image or the type of event it is.

3. Be sure to hit Save or your changes won’t be saved!

4.2: Deleting a Reminder The following steps will guide you in deleting an already existing reminder. 1. Navigate to the category of the event you would like to delete.

2. Choose the event you would like to delete.

3. Press the Delete button at the bottom of the screen.

Appendix

Test Cases Test Case 1: Create Reminder

1. Open the RemindMe! app 2. Tap on the “New” button 3. On the next page, set a time for the event to occur 4. Set a Name and Description below the time 5. Optional: Add an image by tapping on the “Image” button and selecting one from your gallery 6. Tap on the “Event” menu on the bottom right and set it to any category you desire 7. To finish, tap save

Result: A new event is created and scheduled at the specified time Test Case 2: Change Category View

1. Open the RemindMe! app 2. Tap on the menu next to the “new” button 3. Select the category of reminders that you wish to see

Result: The view will change to show reminders of the category you selected Test Case 3: Delete Reminder

1. Open the RemindMe! app 2. Navigate to the category of the reminder you want to delete 3. Tap on the reminder you want to delete 4. At the bottom of the page, tap on the “Delete” button 5. Return to the category the reminder was in

Result: The reminder no longer appears and is no longer scheduled to occur Test Case 4: Edit Reminder

1. Open the RemindMe! app 2. Navigate to the category of the reminder you want to edit 3. Tap on the reminder you want to delete 4. In this window, you may change of the reminder’s properties 5. When you are finished editing, tap the “Save” button

Result: The reminder has been updated with the specified changes Test Case 5: Show Reminder Notification

1. Open the RemindMe! app 2. Create a reminder 3. Wait until the time you have set your reminder to

Result: A notification will appear in the notification panel for your scheduled reminder

References [1]Chung, Lawrence. 'Requirements Engineering', Utdallas.edu, 2015. [Online]. Available: http://utdallas.edu/~chung/CS4351/syllabus.htm. [Accessed: 27 Aug 2015]. [2]Chung, Lawrence. 'CommunicationAssistive Technology Project'. N.p., 2015. Web. 27 Aug. 2015. [3]Chung, Lawrence. 'H.O.P.E (Helping Our People Easily) System'. N.p., 2015. Web. 27 Aug. 2015. [4] T. BernersLee, “Uniform Resource Identifier (URI): Generic Syntax”, RFC 3986, January 2005. [5] L. Chung, Project Phase I: Requirements Elicitation: Initial Understanding, 1st ed. Richardson, TX: Lawrence Chung, 2015, pp. 14. [6] L. Chung, Project Phase II: Requirements Elicitation, Specification, and Validation, 1st ed. Richardson, TX: Lawrence Chung, 2015, pp. 13.

Senior Reminder System Project (Remind Me!)chung/CS4351...Senior Reminder System Project (Remind Me!) World Requirements Specification SE 4351 – Requirements Engineering, Section

Documents