Senior Reminder System Project 

(Remind Me!) 
World Requirements Specification
  
SE 4351 – Requirements Engineering, Section 001 
September 28, Fall 2015 
  
Milton Bland, ​ mxb120730@utdallas.edu 
Zachary Calman, ​ zxc120530@utdallas.edu 
Ridge Frederick, ​ rmf140130@utdallas.edu 
Grant Freeman, ​ gcf140030@utdallas.edu 
Brad Gracy, ​ bjg130030@utdallas.edu 
Jeanie Handler, ​ jch130930@utdallas.edu 
Maria Haney, ​ maria.haney@utdallas.edu 
Justin Keeling, ​ jxk120130@utdallas.edu 
Mazen Lawand, ​ mjl130430@utdallas.edu 
Maryellen Oltman, ​ mco130030@utdallas.edu 
Kevin Szwagiel, ​ kxs124230@utdallas.edu 
Andrew Vaccaro, ​ andrew.vaccaro@utdallas.edu 
Dalton Wooley, ​ dbw081000@utdallas.edu 
Phillip Yellott, ​
pay130030@utdallas.edu 
 
 
Team Website: ​ http://www.utdallas.edu/~atv130330 
This document is for reference only,  
latest documents are always  
on the website above. 
 
   
Revision History
Version  Date  Comments  Author 

1.0  September 9,  Initial Version.  Milton Bland, 

2015  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,  Removed Architectural Specification.  Dalton Wooley, 

2015  Revised to World Requirements  Milton Bland, 
Specification.Changed Project Title  Jeanie Handler 

1.3  October 1st,  Changes made based on presentation  Dalton Wooley 

2015  results. 

1.5  November 7th,  Preparation for Phase 2 Part 1  Dalton Wooley, 

2015  Submission. Added trade­off analysis.  Milton Bland, 
Mazen Lawand 

1.6  December 1st,  Preparation for Phase 2 Part 2  Dalton Wooley 

2015  Submission. Addressed Grace’s  Milton Bland 
concerns. 

1.7  December 1st,   Rectified UML diagram, Added Activity  Jeanie Handler 

2015  Diagram 
 
 

   
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 three­four teams with a total of 14 members who shall work in tandem 

Documentation Team
Milton Bland ​
­ Documentation Manager 
Jeanie Handler​  ­ Documentation Manager 
Dalton Wooley​  ­ Co­Project Manager, Documentation Manager 

Development Team 1
Ridge Frederick ​
­ Developer 
Grant Freeman ​­ Co­Project Manager, Developer 
Brad Gracy ​
­ Developer 
Maryellen Oltman ​­ Developer 

Development Team 2
Justin Keeling ​ ­ Co­Project 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​  ­ Co­Project 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 Co­Project 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 Co­Project 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, on­campus 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 Co­Project 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 pre­existing 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 Object­Oriented 
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 multi­dimensional 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 activity­based or item­based 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 (middle­stage). 
 
Problem 1.  Assist the elderly with problems of vision loss, moderate Alzheimer's disease 
(middle­stage), 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 (middle­stage). 
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 user­friendly 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 trade­off 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 
trade­off analysis was performed by a subset of our entire group one time. 

Program Scenario A
Feature Criteria  Column A Weight of  Column B   Column A  
Importance  Feature Rating  x 
 Column B 

Service will improve  7  7  49 
quality of life for 
users 

Program will be  9  9  81 
implementable in the 
project time period 

Program will center  9  9  81 
around an easy to 
use interface 

Program makes use  5  7  35 
of existing APIs 
 Total      246 
 
 

Program Scenario B
Feature Criteria  Column A Weight of  Column B   Column A  
Importance  Feature Rating  x 
 Column B 

Service will improve  9  7  63 
quality of life for 
users 

Program will be  3  3  9 
implementable in the 
project time period 

Program will center  5  5  25 
around an easy to 
use interface 

Program makes use  7  9  63 
of existing APIs 

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 voice­to­text. 
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 voice­to­text 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 user­friendly. 
12.1. The SR system shall be error­free 
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. Soft­Goal Interdependency Graph covers Nonfunctional Requirements.  

 
PG1. Problem Interdependency Graph describes key issues that could arise.  
 
 
Traceability
World Traceability Matrix
 
World
Problem Problem
ID Description Goal ID Goal Description
Senior Forgot
1 Some Task 1 Acceptability
Senior Does Not
Receive Regular
2 Assistance 2 Availability
Ineffective
3 Reminder 3 Reliability
4 Alert 4 Low Cost
5 No Portability 5 Security
6 Lost Schedule 6 Portability
Requirements
Preliminar PFR Description
y FR ID FR ID FR Description
Visual
1 Interface/CRUD 1 Visual Interface/CRUD
Emergency
2 Contact 2 Emergency Contact
3 Notifications 3 Notifications
4 Voice Interface 4 Categories
5 Categories 5 Search
6 Empty 6 Ordering
7 Empty

Preliminar PNFR Operationalize Operationalize

y NFR ID Description NFR ID NFR Description d FR ID d FR Desc
Understandabilit
8 y 7 Understandability 1, 2, 3, 4, 5, 6 All FR
Visual
Int/CRUD,
9 Portability 8 Portability 1 and 3 Notif.
10 Enhanceability 9 Enhanceability 1, 2, 3, 4, 5, 6 All FR
 Vis. Int./CRUD,
Notif., Cat.,
11 Reuseability 10 Reuseability 1, 3, 4, 6 Order
Vis. Int./CRUD,
Notif., Cat.,
12 Performance 11 Performance 1, 3, 4, 6 Order
Vis. Int./CRUD,
Notif., Cat.,
13 User-Friendly 12 User-Friendly 1, 3, 4, 6 Order
Vis. Int./CRUD,
Notif., Cat.,
14 Interface 13 Interface 1, 3, 4, 6 Order
Progra
Specification m
Functional Proto
FSpec ID Specification Type ID Proto Type Description
View/Select
1 Reminders 1 MainActivity
Handle data
2 persistence 2 SQLite API
Interact with
3 OS/GUI 3 Android API
4 CRUD Reminders 4 CreateReminderActivity
Data Object
5 Model 5 Reminder
Pushes ReminderBroadcastReceiv
6 Notifications 6 er
Abstracts
Database
7 Operations 7 ReminderDatabaseHelper
Sends SMS
8 notifcation 8 SmsBroadcastReceiver
ReminderPreferenceActivi
9 Edit contact info 9 ty
Proto
NFSpecID NF Specifcation Type ID
1, 2, 3,
Understandable 4, 5, 6,
1 Code 7, 8, 9
2 Portable Code 3
 1, 2, 3,
Enhanceable 4, 5, 6,
3 Code 7, 8, 9
Reusable Code 1, 2,
4 Modules and 3
Good System 1, 2,
5 Performance and 3
User-Friendly 1, 2,
6 GUI and 3
Elderly oriented 1, 2,
7 interface and 3
*terms
 

Requirement Volatility Traceability from Project 1 to Project 2

Requirement  Added  Modified  Removed  Description  Unchanged 
of change 

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.3    x    Google   
Calendar API 
was replaced 
with SQlite 
API. 

1.3.1    x    Google   
Calendar API 
was replaced 
with SQlite 
API. 

1.3.2    x    Google   
Calendar API 
was replaced 
with SQlite 
API. 

1.4    x    Google   
Calendar API 
was replaced 
with SQlite 
API. 

1.4.1    x    Google   
Calendar API 
was replaced 
with SQlite 
API. 

1.4.2    x    Google   
Calendar API 
was replaced 
with SQlite 
API. 

1.5    x    Google   
Calendar API 
was replaced 
with SQlite 
 API. 

1.5.1    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.1.2  x      FR 4.1   
needed 
further 
definition 

4.2  x      FR 4 needed   
 further 
definition 

4.2.1  x      FR 4.2   
needed 
further 
definition 

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

5.1  x      FR 5 needed   
further 
definition 

5.2  x      FR 5 needed   
further 
definition 

5.2.1  x      FR 5.2   
needed 
further 
definition 

5.2.2  x      FR 5.2   
needed 
further 
definition 

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

6.1  x      FR 6 needed   
further 
definition 
6.1.1  x      FR 6.1   
needed 
further 
definition 

6.2  x      FR 6 needed   
further 
definition 

6.2.1  x      FR 6.2   
needed 
further 
definition 

6.2.2  x      FR 6.2   
needed 
further 
definition 

7      x  All NFR IDs  x 
lowered by 1. 

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

Requir Create
ement  Req  Main Andr Remin Reminder ReminderD SmsBroa Reminder
Identifi Teste Activit SQLit oid  derActi Remi Broadcast atabaseHel dcastRec Preferenc Unimple
ers  d  y  e API  API  vity  nder  Receiver  per  eiver  eActivity  mented 
Test 
Cases  73                     
Tested 
Implicit
ly  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 
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. 'Communication­Assistive 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. Berners­Lee, “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. 1­4. 
 
[6] L. Chung, ​Project Phase II: Requirements Elicitation, Specification, and Validation​ , 1st ed. 
Richardson, TX: Lawrence Chung, 2015, pp. 1­3.