SE 4351.001 Software Requirements
Fall 2014
Evolving WRS
http://www.utdallas.edu/~axp120531/SE4352/
Team Members
Joe Brown
jsb100120
Desmond Lee
dcl102020
Giuseppe
Mastrolorenzo
mxg106320
Michael Raibick
mxr110530
Ryan Chen
rxc109520
Robert Lockwood
rll092020
Blessing Osakue
boo102020
Oscar Reyes
oxr110330
Travis Chun
twc101020
Michael Mugger
mxm121531
Andrew Pohlmann
axp120531
James Williams
jxw110730
Bennilyn Quek
bxq120430
1
1.4.0
Revision History
Version
Date
Comments
1.0.0
09/30/2014
Initial draft of Section 2.
Formatted document for Phase 1-Interim
turn-in
1.1.0
10/01/2014
Updated FR/NFR list justification ID fields.
Updated traceability matrix fields.
1.2.0
10/02/2014
Updated Sections 3.1, 3.2.2
1.3.0
10/05/2014
Updated Section 3.2.1
1.4.0
10/10/2014
Updated prototype screen
Updated Process
Added Creep Rate Approximation
Added Why Team Total Recall
1.4.1
10/15/2014
Updated Section 3.2.1
Fixed topographical errors, cosmetic
improvements
2
1.4.0
Process
Phase 1 - Interim
Management Meetings
Team
Date
Time
Location
Team Members
Present
Management
10/13/2014
1-3:00pm CST
Monarch Room, UTD
Andrew Pohlmann
Michael Raibick
09/29/2014
1-3:00pm CST
Topaz Room, UTD
Andrew Pohlmann
Blessing Osakue
Michael Muggler
Michael Raibick
09/22/2014
1-5:00pm CST
Bluebonnet Room, UTD
Andrew Pohlmann
Blessing Osakue
Michael Muggler
Michael Raibick
Bennilyn Quek
09/15/2014
1-3:30PM CST
Longhorn Room, UTD
Andrew Pohlmann
Blessing Osakue
Michael Muggler
Michael Raibick
09/08/2014
1-3:00PM CST
Starbucks, UTD
Andrew Pohlmann
Blessing Osakue
Michael Muggler
Michael Raibick
3
1.4.0
Table of Contents
Revision History ............................................................................................................................................................2
Process ..........................................................................................................................................................................3
Phase 1 - Interim ............................................................................................................................................................3
1.
Introduction ..........................................................................................................................................................5
2.1.1 Domain Issues .......................................................................................................................................................6
2.1.2 Stakeholder Issues ..............................................................................................................................................10
2.1.3.1 Functional Objectives Issue Identification .......................................................................................................12
2.1.3.2 Nonfunctional Objectives Issue Identification .................................................................................................19
2.2 Functional Requirements Issue Identification .......................................................................................................20
2.3 Nonfunctional Requirements Issue Identification .................................................................................................27
3. WRS..........................................................................................................................................................................36
3.1 W ...........................................................................................................................................................................36
3.1.1 Problem ..............................................................................................................................................................36
3.1.2 Goal .....................................................................................................................................................................36
3.1.3 Improved Understanding of the Domain, Stakeholders, Functional, and Non-Functional Objectives. .............37
3.1.3.1 Improved Understanding of the Domain .........................................................................................................37
3.1.3.2 Improved Understanding of the Stakeholders ................................................................................................38
3.1.3.3 Improved Understanding of Functional Objectives .........................................................................................39
3.1.3.4 Improved Understanding of Non-Functional Objectives .................................................................................40
3.2 RS ...........................................................................................................................................................................41
3.2.1 Improved Understanding of II.2: FRs ..................................................................................................................41
3.2.2 Improved Understanding of II.2: NFRs ...............................................................................................................49
Preliminary Prototype .................................................................................................................................................51
Traceability ..................................................................................................................................................................52
Creep Rate Approximation ..........................................................................................................................................54
Why Team Total Recall ................................................................................................................................................55
Appendix A...................................................................................................................................................................56
Appendix B ...................................................................................................................................................................58
4
1.4.0
1. Introduction
The primary purpose of Augmentative and Alternative Communication (AAC)
technologies is to facilitate the communication between the disabled user and the
world. Difficulties range from speaking clearly to recalling necessary information to
perform tasks. AAC applications utilize a variety of techniques to facilitate
communication. Techniques include but are not limited to sign language, gestures,
braille, visual aids, pictures, symbols, text-to-speech and speech-to-text engines.
Today’s mobile devices are small, powerful, and affordable and offer an intuitive touchscreen interface. These devices provide an exceptional platform for a software-based
AAC application.
The extent to which AAC applications facilitate communication is dependent on the
user. While users may exhibit some forgetfulness and memory loss, repetition, losing
items, confusion, managing medications, loss of concentration this project assumes
users are capable of utilizing a mobile phone and understanding the conventions
associated with mobile applications. Conventions include understanding how to activate
the application, using a finger to select and making gestures, navigating through
screens, use contextual menus, providing various forms of input and interpreting visual
representations on a screen.
This project is intended to help those suffering from mild dementia in communicating
more effectively by presenting a software system that capable of recalling objects that
the user has forgotten about so that they may communicate to or about them.
5
1.4.0
2.1.1 Domain Issues
Domain Issue ID
DR1
Statement
“In the application domain, the communication typically consists of the
following people and events/situations: [...]”
Issues
1.
The “application domain” is a vague generalization of the
complete disability spectrum, referencing different types of
impairments including speech, hearing, vision, and/or memory
loss.
Solutions
1.
Define the domain and scope of the system.
Decision
Solution 1 shall be picked.
Therefore,
This project’s domain of disability assistance shall be defined as
those suffering from Stage 3 or “Mild” on the medical scale “The
Stages of Dementia”.
Rationale
The goal of the system is to assist a user with communication who is
diagnosed with stage 3 dementia.
Domain Issue ID
DR2
Statement
”An elderly with speech, hearing, vision and /or memory loss [...]”
Issues
1.
The terms “speech, hearing, vision and /or memory loss” are
general domain terms and not explicit to the scope of the
system.
Solutions
1.
Define the scope of system assistance with regard to DR1.
Decision
Solution 1 shall be picked.
Therefore,
The system shall not provide functionality to solve problems
originating from other disabilities in the world domain.
Rationale
The system will be for users of a specific domain disability scope, not
the broad spectrum of the disability domain. An emergency situation
will by no means impact the domain target of this system.
6
1.4.0
Domain Issue ID
DR3
Statement
“[..] daily living activities like washing, taking a bath, going to the
restroom, eating/drinking, walking, transferring to the bed, are the
typical activities that are of concern to them [...] and they often have to
call/communicate to people around them for fulfilling these.”
Issues
1.
The phrase “[users] often have to call/communicate to people
around them for fulfilling these [daily/typical activities]” is
unsound because, depending on the scope definition of
baseline user capability, assistance with any kind of activity
may not be necessary to begin with.
Solutions
1.
Define the scope of system assistance with regard to DR1.
Decision
Solution 1 shall be picked.
Therefore,
The system shall only assist users who fit the cognitive and physical
capabilities as defined in DR1 and who are thus capable of operating
a smart phone.
Rationale
The scope definement of the use capabilities reads, ““At this stage,
patients are “usually able to do basic activities of daily living,” says
Shah — which means they can perform their daily routines, such as
getting up, going to the bathroom, getting dressed, and so on, without
difficulty.” Based on this professional medical opinion, it can safely be
assumed that the system does not need functionality to assist the user
with the activities defined in the statement.
Domain Issue ID
DR4
Statement
“It is learnt that human perception is visual rather than only textual
and the mind functions best when all senses work in a complementary
manner.
Issues
1.
2.
The statement implies that the system must engage all sensory
facilities of the user to be effective in its fulfilling its goal of
defined in DR1.
The statement implies that the user is incapable of
comprehending meaning without substantial sensory aid and
7
1.4.0
thus regardless of system scope or domain of assistance, the
system must assist the user in comprehending the meaning of
an object.
Solutions
Decision
1.
Define the scope of system assistance with regard to DR1.
Solution 1 shall be picked.
Therefore,
The system scope of assistance is bringing object remembrance, and
comprehension of the object shall be the burden of the user.
Rationale
The system shall not concern itself with functionality that provides
comprehension about the meaning of an object. The system shall only
help a user remember an object.
Domain Issue ID
DR5
Statement
”This system will be designed for a mobile smartphone platform
running the Android OS.”
Issues
None
Solutions
Decision
1.
Accept this statement.
Solution 1 shall be picked.
Therefore,
This hardware/software domain of this system shall only exist on a
mobile smartphone platform running the Android OS.
Rationale
The system is being designed with a mobile smartphone platform that
is running the Android operating system.
Domain Issue ID
DR7
Statement
“An important part of elderly communication is knowing who or what
to contact when the user feels an emergency situation has occurred.”
Issues
1.
Definition of an “emergency situation” is vague. What is an
“emergency? “What is an “emergency situation.”?
8
1.4.0
Solutions
Decision
2.
Will the system scope of assistance change if an emergency
situation occurs?
1.
2.
3.
Define “emergency.”
Define an “emergency situation.”
Define the system scope of assistance with regard to DR1
Solutions 1-3 shall be picked.
Therefore,
The system shall define an “emergency” as an immediate risk to the
user’s health, life, property, or environment.
The system shall define an “emergency situation” as when that
immediate risk has materialized and the user must contact the
appropriate entities for quick assistance.
The system shall treat the user as fully capable of both mentally and
physically operating the system in the event of an “emergency
situation.”
The system shall not detect an emergency situation, and will not
express the user’s will if an emergency situation does occur.
Rationale
An emergency is when a user must contact 911, or a medical
professional, or a medical facility. However, because this system is not
designed as an emergency platform, the system scope of assistance
shall not change.
9
1.4.0
2.1.2 Stakeholder Issues
Stakeholder Issue ID
SR1
Statement
“In the application domain, the communication typically consists of
the following people and events/situations: [...]”
Issues
The term “people” is vague and does not accurately represent the
stakeholder group that may be using the system.
Solutions
Decision
1.
Define the system stakeholders.
Solution 1 shall be picked.
The Stakeholder groups shall be defined as the following:
User
System user
Non-User: Organization
Requirements Engineer
Software Developer
User Interface Engineer
Project Manager
Financial Backer
Rationale
The stakeholder groups are defined as the user who is suffering from
memory impairment consistent with DR1, and the system’s software
development organization.
Stakeholder Issue ID
SR2
Statement
“An assistive person is one that is either a disabled person or a nondisabled person with whom the user wants/needs to communicate.”
Issues
1.
Attaching the adjective “assistive” to any stakeholder group
(especially impaired) just because that group is the target of a
communication attempt is unsound because it cannot be
implied that the target of the communication attempt is even
capable of assistance.
Solutions
1.
Qualify the necessity of a the “assistive” stakeholder user
category with the system’s assumption of user capabilities.
10
1.4.0
Decision
Solution 1 shall be picked.
The term “assistive” is not necessary given the scope of user-defined
capabilities per DR1.
Therefore,
The system shall reject this requirement.
Rationale
The system assumes that the user is physically capable of assisting
himself or herself. No assistance is necessary.
11
1.4.0
2.1.3.1 Functional Objectives Issue Identification
Justification ID
DR1, DR2, DR3, DR4
Objective ID
FO1
Statement
“In the application domain, the communication typically consists of the
following people and events/situations: [...]”
Issues
1.
“Communication” as used is vague. Is “communication” itself
an “event/situation” or is “communication” the act of
conveying information?
Solutions
1.
2.
Define “communication/”
Qualify the system’s level of assistance during “communication”
against DR2, DR3, and DR4.
Decision
Solutions 1-2 shall be chosen.
“Communication” is the act of conveying information about some
object.
The system’s scope of assistance neither permits expressing the user’s
will for them or providing meaning about the object the user is
attempting to communicate about.
The system’s reason for existence is to help the user communicate by
providing the user with remembrance of the object(s) the user is
attempting to communicate to, or about.’
Therefore,
The system shall present a graphical user interface so that the user
may find the object he or she cannot remember so that they can
communicate about it or to it.
Rationale
Communication is not possible for anyone (much less the system user),
if they cannot remember what they are talking about. Communication
is always focused on “something”. That “something” can be described
in generic fashion as an object, whether it is physical (people, places,
things, events etc) or metaphysical (an idea, an opinion, an expression
of will etc.) Therefore, when one cannot remember what that object is,
communication is not simply difficult - it is impossible.
12
1.4.0
Justification ID
Objective ID
FO2
Statement
“[..] daily living activities like washing, taking a bath, going to the
restroom, eating/drinking, walking, transferring to the bed, are the
typical activities that are of concern to them [...]
Issues
1.
The phrase “daily living activities [...] are the typical activities
that are of concern to them [...]” is unsound because the
adjectives “daily” and “typical” are defined with respect to
some entirely arbitrary measure of self-importance to a
specific user..
Solutions
1.
2.
Define “daily living activities” and “typical activities.”
Define the scope of system assistance with regard to DR1.
Decision
Solution 1-2 shall be picked.
A “daily” activity has been defined as a “typical” activity like “washing,
taking a bath, going to the restroom, eating/drinking, walking, and
transferring to bed.” The system shall ignore the “daily” and “typical”
nature of these activities and simply refer to them as “activities”
The system’s understanding of user capability assumes the user is
capable of carrying out activities with no outside assistance.
Therefore,
The system shall reject this requirement.
Rationale
The user has the capability to ““[...] perform their daily routines, such
as getting up, going to the bathroom, getting dressed, and so on,
without difficulty.” as per the scope-defined capability understanding
in DR1.
Justification ID
DR4
Objective ID
FO3
Statement
“In a typical scenario, where a person wants to communicate a
message to the elderly having hearing loss and a weak memory,
he/she uses visual aids like pictures and icons and text and/or speech
on top of it, to reinforce the meaning of an item – say showing a sign
or picture of a restaurant, along with the name of the restaurant and
13
1.4.0
saying the name loudly, to indicate the place where they will go out to
eat.”
Issues
1.
The statement combines two different scopes of domain
impairment, and implies that the system must provide
solutions for more than 1 domain disability type.
Solutions
1.
Define the scope of system assistance with regard to DR1.
Decision
Solution 1 shall be picked.
The system’s understanding of user capability assumes that the user is
fully capable of understanding the meaning of an object once
remembered. While the system does not itself provide comprehension
of an object, it allows user-defined and user-inputted meaning to
objects.
Therefore,
The system shall allow system-approved user-defined meaning to
objects.
Rationale
The scope of the system does not deal with mental impairment past
level 3. As such, the system stakeholder user group is assumed to have
the proper mental abilities to understand the meaning of an item once
that item has been remembered. This system is not for individuals who
have serious cognitive impairment past mild memory loss.
Objective ID
FO4
Statement
“Apart from the basic communication messages, the elderly also
want to perform other activities or express an opinion about
something like – ‘ I want to watch Television’, ‘ I want to drink Cola’,
‘I am not feeling well’ and so on.”
Issues
1.
2.
“Basic communication messages” is vague because it is
context-less. A “basic communication message” in an
emergency situation would be different that a “basic
communication message” in a non-emergency situation.
The statement as a whole assumes that the system shall
construct “basic communication messages,”
14
1.4.0
Solutions
Decision
3.
The statement is implying that the system must assist the user
express his/her will, regardless of scope.
1.
Define the scope of system assistance with regard to DR1 and
DR4.
Solution 1 shall be used.
The system understanding of user capabilities assumes that the user is
fully capable of expressing their will.
The system shall provide no functionality to communicate the will of
the user.
Therefore:
The system shall reject this requirement.
Rationale
The user is not defined to be physically or mentally handicapped to the
point that they cannot express their will. This system is not for
individuals who have serious physical and mental handicaps to the
point that they cannot express themselves at all.
Justification ID
DR3, DR4
Objective ID
FO5
Statement
“A category is a descriptor containing the multi-dimensional
vocabulary items having a similar meaning, relation and/or purpose.
A disjoint category is one that does not have its items overlap with any
other 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.”
Issues
Solutions
1.
2.
“Multi-dimensional vocabulary” is very vague. What signifies
“mult-dimensionality”? Context? Type? Usage?
The terms “disjoint category” and “overlapping category” are
vague due to the lack of definition of “multi-dimensional” in
respect to the things they may be classifying.
1.
2.
Define what “multi-dimensional vocabulary” means.
Define what a category is based on the understanding of what
15
1.4.0
a “multi-dimensional vocabulary” item is.
Decision
Solutions 1-2 shall be picked.
The term “multi-dimensional vocabulary” shall be defined and
referenced as “object” in the singular, and “objects” in the plural.
Therefore,
FO5
Objects are items the user wants to remember.
FO5.1
Categories are collections of objects that have a contextually similar
relation to each other.
FO5.2
All categories shall be disjoint.
Rationale
The notion of “multi-dimensionality vocabulary” can only be grasped if
the context, type, or association of usage is known beforehand.
However, the context, type, or association is not known until the actual
event occurs that defines these associated qualifiers. As such, an
easier approach to defining “multi-dimensional vocabulary” is to simply
look at all vocabulary items as simply generic objects that have no
implied associated descriptors that would infer usage. This flexibility
allows definition of categories to be groups of objects that are brought
together by a pre-determined measure of associations. Given the
known association qualifiers such as context, type, or usage, categories
can then be made to be disjoint or overlapping.
Justification ID
Objective ID
FO6
Statement
“An important part of elderly communication is handling emergency
situations. It is more often the case that elderly living alone require
prompt medical attention in cases of health emergency as well as
quick response in cases of fire, theft etc.”
Issues
1.
“Handling of emergency situations” is vague. Does an
emergency change the system’s scope regarding user
capabilities? What is the system’s role in an emergency? Is the
16
1.4.0
system detecting the emergency and then responding to the
appropriate outside entities?
Solutions
Decision
1.
Define the scope of system assistance with regard to DR1 and
DR7.
Solution 1 shall be picked.
The system shall treat the user as fully capable of both mentally and
physically handling an “emergency situation.”
Therefore,
This requirement shall be rejected.
Rationale
This system is not designed as an emergency detection and response
application. This system is designed merely to assist the user with
communication by helping them to remember objects that may be used
in an emergency situation.
Justification ID
DR7
Objective ID
FO7
Statement
“The system must be capable of providing an easy interface for
emergency calls like 911, to any emergency contacts, as well as send
fast messages to a nearby response department like a hospital.”
Issues
1.
The statement implies system functionality that will
automatically assist in contacting emergency contacts,
regardless of system scope of assistance given user capabilities.
Solutions
1.
Reword this functional objective as:
“The system shall assist the user in an emergency situation by
recognizing the uniqueness of emergency contacts.”
Decision
Solution 1 shall be picked.
Therefore:
The system shall provide direct and accurate access to emergency
contacts.
Rationale
The system will provide no automation of contacting emergency
entities because an emergency shall not change the scope of the
system’s assumptions of user capabilities. The system will, however,
17
1.4.0
classify emergency objects disjointly from all other objects due to their
unique function in the real world.
Justification ID
DR6
Objective ID
FO11
Statement
“The mobile platform must have the necessary environmental
resources to run the system.”
Issues
None.
Solutions
Decision
1.
Accept the statement as is.
Solution 1 shall be picked.
Therefore,
The mobile platform must have the necessary environmental
resources to run the system.
Rationale
Because the system will be potentially storing many objects, the
platform requirements must be sufficient so that the system can
quickly process user requests involving objects in the system.
18
1.4.0
2.1.3.2 Nonfunctional Objectives Issue Identification
Objective ID
NFO1
Statement
“The system graphical user interface must be intuitive and easy to
use.”
Objective ID
NFO3
Statement
“The system shall ensure low-latency operation.”
Objective ID
NFO4
Statement
“The system shall maintain specific organization for emergency
contacts.”
Objective ID
NFO5
Statement
“The system shall implemented limited on-platform hardware
extensibility.”
19
1.4.0
2.2 Functional Requirements Issue Identification
Justification ID
NFO1, FO1, NFR1, NFR3, NFR9
Requirement ID
FR1
Statement
Providing a way for the users to select proper categories and navigate
through various dimensions of vocabulary.
Issues
1.
“Proving a way [...] to select [...] and navigate [...]” as worded is
vague.
Solutions
1.
Define the way for the system to select and manipulate objects
while navigating through the system.
Decision
Solution 1 shall be picked.
Therefore,
The system shall provide menus, forms, and buttons for operating the
system.
Rationale
The user must be given an efficient and familiar navigational structure
that ensure usability.
Justification ID
NFO4, FO7, NFR14
Requirement ID
FR3
Statement
Placing emergency calls and messages, possibly after detecting a fall.
Issues
1.
The statement implies that the system has special functionality
to detect when the user has fallen, and also the functionality to
automatically send an emergency call or message immediately
afterward.
Solutions
1.
Define the scope of system assistance with regard to DR1 and
DR7.
Decision
Solution 1 shall be picked.
20
1.4.0
Therefore,
The system shall create a dedicated emergency menu for emergency
objects where all emergency contacts shall be placed.
Rationale
Because the scope capabilities of the user indicate that the user may
forget pertinent emergency-orientated contact info due to memory
loss, it can easily be seen that quick and accurate access to the proper
emergency contact categories should be carried out by the system.
Justification ID
NFO5, FO3, NFR11, NFR16
Requirement ID
FR4
Statement
Giving a specific meaning to each picture to reduce the ambiguity, as a
picture can be worth a thousand words and a thousand
interpretations.
Issues
1.
2.
Solutions
Decision
1.
The term “specific meaning” is vague. What type of descriptor
imparts a “specific meaning” to each picture?
How can the system tell if one interpretation out of a thousand
is sufficient given the user?
Define the system’s role in assisting the user with
comprehending an object.
Solution 1 will be picked.
Therefore,
The system shall allow the user to attach specific types of userdefined meaning to objects.
Rationale
The system shall take on no burden for implementing functionality that
provides extra contextual logic for a picture or object other than
displaying the caption or annotation the user has provided for that
picture or object.
Justification ID
NFO1, FO5, NFR17
Requirement ID
FR5
Statement
Making each vocabulary item available through a search interface.
21
1.4.0
Issues
1.
No issues with this statement, other than replacing the term
“vocabulary item” with object.
Solutions
1.
Define a manner in which objects can be searched through.
Decision
Solution 1 will be picked.
Therefore,
The system shall provide a search interface for objects.
Rationale
It is mandatory to impart search functionality upon all objects. System
usability is greatly enhanced by this function.
Justification ID
NFO5, FO3, NFR11, NFR16
Requirement ID
FR7
Statement
Integrating already available technologies like alarm clock in a
meaningful manner.
Issues
1.
2.
3.
Solutions
Decision
1.
2.
The phrase “integrating already available technologies” is
vague.
Are these technologies internal smartphone features, internal
applications, or separate applications not native to the
operating system?
Are these technologies meant to assist users with out of scope
impairments?
Reject this requirement as redundant given FR4.
Allow this requirement, but restrict “available technologies” to
only smartphone technologies, and only smartphone
technologies that can be used to help the user remember an
object.
Solution 1 will be chosen.
Therefore,
This functional requirement shall be rejected.
Rationale
The system has already has a requirement in FR4 to allow the
attachment of self-meaning to objects. Instead of allowing a
functional requirement to simply allow the integrating of already
available technologies with no context toward their actual value
toward the main system goal of assisting the user by recalling an
22
1.4.0
object, this functional requirement is rejected in a standalone fashion,
but is effectively implemented in FR4.
Justification ID
NFO1, FO5, NFR4
Requirement ID
FR8
Statement
Displaying relevant or most frequently used items before other
vocabulary items.
Issues
1.
No issues with this statement, aside from renaming “items”
and “vocabulary items” as “objects.”
Solutions
1.
Define the nature of system categorization for this specific
functionality.
Decision
Solution 1 will be used.
Therefore,
The system shall present most recently viewed objects.
Rationale
Displaying recently viewed objects can be seen as a wise feature to
implement in the system. Because the user may use the same objects
repeatedly, this functionality allows extremely quick fulfilling of the
system goal of assisting the user in locating an object.
Justification ID
NFO1, FO5, NFR4
Requirement ID
FR9
Statement
“System shall allow user to create multiple types of objects.”
Issues
1.
2.
Solutions
Decision
1.
What is the practical limit on the specific types of objects the
user can create?
If the user can create multiple types of objects, is there any limit
on the types of objects that can be created?
Consider the requirement with respect to the issues raised and
the organization’s ability to implement them.
Solution 1 shall be chosen.
23
1.4.0
Therefore,
System shall allow user to create, retrieve, update, and delete
multiple types of specific objects.
Rationale
Because there are infinitely many types of objects, allowing this feature
to be unrestrained in scope is a dangerous precedent that could mire
the development organization into a perpetual process of category
and/or object maintenance.
Justification ID
NFO1, FO5, NFR4
Requirement ID
FR10
Statement
“System shall allow user to create multiple types of categories.”
Issues
1.
2.
3.
Solutions
Decision
1.
What is the practical limit or number of categories?
If the user is creating categories on their own, what determines
the fields of the objects that those categories would organize?
Implying that the user can create multiple specific types of
categories also implies that the user can create multiple types
of specific objects to go into those new categories.
Consider the requirement with respect to the issues raised and
the organization’s capability to implement them.
Solution 1 shall be chosen.
Therefore,
System shall pre-define a specific set of category types.
Rationale
Because there are infinitely many types of categories of objects,
allowing this feature to be unrestrained in scope is a dangerous
precedent that could mire the development organization into a
perpetual process of category and/or object maintenance.
Justification ID
NFO1, FO5, NFR4
Requirement ID
FR11
Statement
Overall, the system should also make the vocabulary organization such
that the user can use it in many contexts and sentences are generated
24
1.4.0
in fewer clicks.
Issues
1.
2.
Solutions
Decision
1.
2.
“Sentences are generated in fewer clicks” is outside the scope
of this system.
Objects organized in “many contexts” represents complexity
that is not only difficult to define, but challenging to
implement.
Remove “sentences are generated in fewer clicks.”
Rephrase “the system should also make the vocabulary
organization such that the user can use it in many contexts” but
rephrase it for better understanding.
Solution 1-2 will be picked.
Therefore,
The system shall present object categories based on type.
Rationale
The system must organize objects in an intuitive, yet defined manner.
As such, the system will ensure that objects of like type are categorized
together.
Justification ID
NFO3, FO11, NFR2
Requirement ID
FR15
Statement
The system shall check the platform of the smartphone to ensure
compatibility with the system’s minimum platform requirements.
Issues
1.
None.
Solutions
1.
Accept statement as is.
Decision
Solution 1 will be picked.
Therefore:
The system shall check the smartphone platform’s resources to
ensure system compatibility with minimum system requirements.
25
1.4.0
26
1.4.0
2.3 Nonfunctional Requirements Issue Identification
Justification ID
NFO1, FO1, FR1
Requirement ID
NFR1
Statement
The system should be usable.
Issues
Solutions
Decision
1.
2.
Usability is ambiguous without a clear metric. Does this mean
the system should not crash or have minimal crashing.
This statement does not define the scope to apply usability. For
example does it apply to the system maintainers or to the users
in terms of the user interface?
1.
Define the term usability in terms of the user interface.
Solution 1 shall be chosen.
Therefore:
The system shall not display more than 3 layers over root level.
Rationale
Given the application is geared towards a consumer market running on
a user's smartphone we will define usability in terms of the user
interface with defined metrics.
Justification ID
NFO3, FO11, FR15
Requirement ID
NFR2
Statement
The system shall be ubiquitous.
Issues
1.
2.
3.
The context and scope of ubiquitous is undefined and
ambiguous. Should the system or user interface be ubiquitous
and where should it be found?
The ubiquity of the system has no limits defined. Should this be
limited to the scope of a mobile application or does this mean a
solution must be created for mobile, tablet, desktop and cloud.
Ubiquity means that performance characteristics of the system
cannot be defined because computing systems all have varying
levels of power.
27
1.4.0
Solutions
Decision
1.
Reword this statement to reflect the hardware/software
platform constraint of the project.
Solution 1 shall be used.
This requirement shall be accepted, but reworded as:
The system requires that the platform possess at least a 1ghz
processor, 250mb hard drive space and 150mb free ram.
Rationale
A ubiquitous system is a system that can be made to appear on any
device computing device, regardless of hardware platform, operating
system, or form factor. This system is specifically designed to be used
on a smartphone running the Android operating system that has a
minimum amount of processing power and ram to run the system at
the desired minimum level of performance.
Justification ID
NFO1, FO1, FR1
Requirement ID
NFR3
Statement
The system should be quick to understand (the learning time should be
very low) and very easy to use.
Issues
1.
2.
Solutions
Decision
1.
No acceptable range or tolerances are defined for low and or
high learning times. The range and or tolerances may be
dependent on a variety of factors concerning the users.
No procedure is defined to accurately measure and determine
if the learning time is valid. Further when and where should
learning time be measured? What defines the starting point
and ending point for measurements?
The system shall require only two taps or clicks at most to
access any functionality in the system.
Solution 1 shall be picked.
Therefore,
The system shall give accessibility to each menu, form, or button with
at most two taps or clicks.
Rationale
The system should not make the user perform counter-intuitive or
burdensome input to access any portion or functionality of the system.
28
1.4.0
Justification ID
NFO1, FO5, FR5, FR8, FR9, FR10, FR11, FR16
Requirement ID
NFR4
Statement
The vocabulary organization should be clear and intuitive.
Issues
1.
2.
3.
Solutions
Decision
1.
The means to provide clarity is not defined. Does this refer to
the clarity of user interface elements or the ease of finding
elements displayed on the user interface.
The metrics and measuring instructions are not defined.
Further no acceptable ranges with tolerances are defined to
constitute acceptable clarify and intuitiveness.
Clarity and intuitiveness are dependent on the user. To further
define this requirement will require that the targeted types of
users this application intends to help is provided.
Define a system requirement regarding the organization of
objects.
Solution 1 shall be picked.
Therefore,
The system shall maintain organization of objects at all times.
Rationale
The system will properly categorize types of objects based on their
likeness as the user would see them.
Justification ID
Requirement ID
NFR5
Statement
The navigation of the system should be seamless and evident to all
users.
Issues
1.
2.
3.
This requirement is too broad and cannot be guaranteed in all
cases as it is dependent on a variety of factors concerning the
user.
No definition of seamless is given. The term seamless is used
previously in other requirements to describe both the software
system and the user interface.
No method of measuring and acceptable ranges with
tolerances are given to ensure that the interface is seamless
and evident to all users.
29
1.4.0
Solutions
1.
2.
Decision
Provide a persisted object that is always on the top layer of the
display that displays current location of user relative to root.
Reject this requirement as being unnecessary.
Solution 2 will be taken.
Therefore,
This non-requirement shall be rejected.
Rationale
Given the scope assumptions of user capabilities, the user should have
no issues operating the system and understanding what the
implications are of navigation elements.
Justification ID
Requirement ID
NFR6
Statement
New sentence generation should be done as dynamically and with as
much flexibility as possible.
Issues
1.
This non-functional requirement is describing sentence
generation, which has been deemed outside the scope of this
system.
Solutions
1.
Reject this non-functional requirement on the basis of DR1.
Decision
Solution 1 will be taken.
Therefore,
This non-functional requirement will be rejected.
Rationale
This non-functional requirement describes a non-existent system
functionality that would assist the user in expressing self, and as such
is irrelevant and unnecessary.
Justification ID
Requirement ID
NFR7
Statement
The number of clicks that a user has to press to generate a sentence
should be kept minimal.
Issues
1.
This non-functional requirement is describing the operating
30
1.4.0
characteristics of a system feature that has been deemed out
of scope by FO4.
Solutions
Decision
1.
Reject this non-functional requirement on the basis of DR1.
Solution 1 will be chosen.
Therefore,
This non-functional requirement shall be rejected.
Rationale
This non-functional requirement describes a non-existent system
functionality that would assist the user in expressing self, and as such is
irrelevant and unnecessary.
Justification ID
Requirement ID
NFR8
Statement
The communication system to be built should reflect as closely as
possible the way users communicate in the real world (see the domain
theory above).
Issues
1.
“Reflecting as closely as possible the way users communicate in
the real world” is vague as there is no possible way to know all
the potential ways people communicate with each other, and
thus impossible to “reflect as closely possible” from a design
standpoint what is unknowable.
Solutions
1.
Define the scope of system assistance with regard to DR1.
Decision
Solution 1 will be taken.
Therefore,
This non-functional requirement shall be rejected.
Rationale
There is no possible way for this system to reflect as closely as possible
communication in the real world. There are individual, cultural, and
societal differences in the way that humans communicate with each
other. Methods can consist of sign language, verbal, visual, or any
other human movement that could carry meaning.
Justification ID
NFO1, FO1, FR1
31
1.4.0
Requirement ID
NFR9
Statement
The system should provide an appropriate level of performance: the
elapsed time between the click of an icon and the sound generation
should be minimal, (emergency calls and messages should be fast and
accurate).
Issues
1.
2.
Solutions
Decision
1.
This requirement does not define what it means to be minimal
or what an appropriate level of performance is with an
acceptable range and tolerance.
This requirement does not define meaningful metrics and
measurement instructions to provide proof of the appropriate
level of performance.
Set a defined system response time to any type of user input.
Solution 1 shall be picked.
Therefore,
The system shall respond to user navigational input with no greater
than a two second delay.
Rationale
If the phone meets minimum hardware resource specifications, the
system shall respond to navigational input in no longer than two
seconds.
Justification ID
Requirement ID
NFR10
Statement
The sentence building should be done as accurately as possible
(considering grammatical constraints of natural language).
Issues
1.
Sentence building functional requirements are described.
Sentence building is outside the scope of this system.
Solutions
1.
Reject this nonfunctional requirement based on DR1.
Decision
Solution 1 will be chosen.
Therefore,
This non-functional requirement will be rejected.
Rationale
This non-functional requirement describes a non-existent system
32
1.4.0
functionality that would assist the user in expressing self, and as such
is irrelevant and unnecessary.
Justification ID
NFO5, FO3, FR4
Requirement ID
NFR11
Statement
The system should be customizable to every user in the context of
making sense of an visual clue as the user wants, how he/she wants to
view the clues and what speech should be generated (if the user wants
to generate it).
Issues
1.
The system is assisting the user with the meaning of an object.
Solutions
1.
Allow the user to create meaning of an object using systemapproved descriptors.
Decision
Solution 1 shall be chosen.
Therefore,
The on-platform technologies used in system-allowed, user-defined
meaning cannot require third-party driver or plug-in support.
Rationale
The system shall not provide functionality to assist the user in
understanding an object, past what the user has inputted as contextual
descriptors. The system shall also not be generating sentences.
Justification ID
Requirement ID
NFR12
Statement
The system should be easily extensible to accommodate the following
typical variations: variations in interface, language, definitive needs of
the user, new features, new hardware etc.
Issues
1.
2.
3.
“Variations in interface” is vague and incomplete. Do
“variations in interface” change or interrupt functionality?
Will “variations in interface” confuse the user? How will the
system go about in real time changing the interface?
Variations of “language” is unsound because the software
developers cannot hope to accommodate all potential different
languages.
33
1.4.0
4.
5.
6.
“Definitive needs of the user” is vague and the system cannot
hope to anticipate arbitrary needs of the user. What defines a
“definitive need” of the user?
“Variations of features” is unsound. The system is designed to
accomplish a specific objective.
“Variations of hardware” is not applicable to an otherwise
closed upgrade platform like a smartphone.
Solutions
Reject this requirement.
Decision
Solution 1 shall be chosen.
Therefore,
This non-functional requirement shall be rejected.
Rationale
Neither the system, nor the hardware platform will implement the
extensibility as it is stated here. Extensibility is virtually impossible on a
mobile device.
Justification ID
NFO4, FO7, FR3
Requirement ID
NFR14
Statement
“The system shall allow handling of emergency situations.”
Issues
1.
What does “handle” mean with respect to system
functionality? Is “handling of emergency situations” detecting
an emergency and automatically taking action based on the
understanding of what type of emergency situation has
occurred?
Solutions
1.
Define a system requirement that impacts how quickly the
system will present emergency objects.
Decision
Solution 1 shall be chosen.
Therefore,
Emergency contacts must be accessible within 5 seconds.
Rationale
All emergencies, no matter the type, are urgent and thus have time
constraints. Because of the “immediate risk” nature of what defines an
emergency, the system make all possible design considerations to take
response time into an account.
34
1.4.0
Justification ID
NFO5, FO3, FR4
Requirement ID
NFR16
Statement
“The system shall allow interfacing to specific local smartphone
integrated devices like GPS, Camera, and microphone.”
Issues
1.
None.
Solutions
1.
Allow nonfunctional requirement.
Decision
Solution 1 will be chosen.
Therefore,
All on-platform technologies allowed to be used by the user to
provide object self-meaning must provide output that can be
attached to an object.
Rationale
Local technologies on the smartphone platform like a GPS, Camera, or
Microphone can provide useful in recording contextual data that the
user may attach to an object to assist in remembering.
Justification ID
NFO1, FO5, FR5
Requirement ID
NFR17
Statement
“The system search mechanism shall return results within 3 seconds.”
Issues
1.
None.
Solutions
1.
Allow nonfunctional requirement.
Decision
Solution 1 will be chosen.
Therefore,
The system search mechanism shall return results within 3 seconds.
Rationale
It is important that the system be quick to return search results.
35
1.4.0
3. WRS
3.1 W
3.1.1 Problem
The problem of mild dementia can be a serious impediment to communication.
Because the topic of many conversations typically revolves around a something or
someone, having memory loss that impacts what the target of the conversation is can
provide a direct challenge to the ability to communicate. When one is unable to
remember what he or she is desiring to talk about, or even who they are desiring to talk
to, communication is all but impossible. In fact, a wide range of assistive devices that
do not assist the user in memory recall are made ineffective for the purposes of
communicating because they do not address the root cause of the communication
problem, which is memory loss.
3.1.2 Goal
The purpose of this project is to create an AAC application, running on a mobile
device, capable of aiding a user suffering from mild dementia (stage 3) by recalling
pertinent objects to facilitate communication.
36
1.4.0
3.1.3 Improved Understanding of the Domain, Stakeholders,
Functional, and Non-Functional Objectives.
3.1.3.1 Improved Understanding of the Domain
Requirement ID
Statement
IDR1
This project’s domain of disability assistance shall be dementia,
Stage 3. (Appendix A)
Requirement ID
Statement
IDR2
The system’s scope of assistance shall only be only for those
suffering from stage 3 dementia. (Appendix A)
Requirement ID
Statement
IDR3
The system shall assume that the use is not physically and
mentally handicapped and thus capable without assistance of
carrying out trivial activities such as operating a mobile device.
Requirement ID
Statement
IDR4
The system shall assist the user only with remembering an object,
and any comprehension of the object shall be the burden of the
user.
Requirement ID
Statement
IDR5
This system’s domain regarding hardware and software platforms
is a smartphone that is running the Android OS.
Requirement ID
Statement
37
1.4.0
IDR7
The system shall not detect an emergency situation, and will not
express the user’s will if an emergency situation does occur.
3.1.3.2 Improved Understanding of the Stakeholders
Requirement ID
Statement
ISR1
The stakeholder groups are defined as:
1.
2.
User
a. System user
Non-User
a. Requirements Engineer
b. Software Developer
c. User Interface Engineer
d. Project Manager
e. Financial Backer
38
1.4.0
3.1.3.3 Improved Understanding of Functional Objectives
Requirement ID
Statement
IFO1
The system shall present a user interface to the user so that the
user may find the object he or she cannot remember.
Requirement ID
Statement
IFO3
The system shall allow the user to impart limited user-defined
understanding on an object.
IFO3.1
The system will itself not provide functionality to discover the
meaning of an object on behalf of the user.
Requirement ID
Statement
IFO5
Objects are things the user is wants to remember.
IFO5.1
Categories are collections of objects that have a contextually
similar relation to each other.
IFO5.2
All categories shall be disjoint.
Requirement ID
Statement
FO7
The system shall provide direct and accurate access to
emergency objects.
Requirement ID
Statement
IFO11
The mobile platform must have the necessary environmental
resources to run the system.
39
1.4.0
3.1.3.4 Improved Understanding of Non-Functional Objectives
Requirement ID
Statement
NFO1
The system user interface shall be intuitive and easy to use.
Requirement ID
Statement
NFO3
The system shall ensure quick response times while operating.
Requirement ID
Statement
NFO4
The system shall maintain specific organization for handling
emergency contacts.
Requirement ID
Statement
NFO5
The system shall support limited hardware and software
extensibility.
40
1.4.0
3.2 RS
3.2.1 Improved Understanding of II.2: FRs
Requirement
ID
Statement
IFR1
The system shall provide menus, forms, and buttons for operating the system.
IFR1.1
The system shall provide a persistent upper main menu, an inner frame area,
and a persistent lower menu.
IFR1.1.1
The persistent lower menu shall consist of the platform-provided navigation
buttons “Back”, “Home”, “Recently Used Applications.”
IFR1.1.1.1
If the “Back” button from the persistent lower menu is actuated, the system
shall attempt to go to the previous inner frame area.
IFR1.1.1.2
If the “Home” button from the persistent lower menu is actuated, the system
shall attempt to minimize the Total Recall application completely.
IFR1.1.1.3
If the “Recently Used Applications” button is actuated, the system shall carry
out the platform programming for displaying “Recently Used Applications.”
IFR1.1.1.3.1
If another recently used application is actuated from the “Recently Used
Applications” button, the system shall attempt to minimize Total Recall and
open the selected application.
IFR1.1.2
The system shall prevent screens from obscuring the upper main menu, and
the lower menu.
IFR1.2
The user shall be able to navigate between menus with single taps or clicks.
IFR1.3
The system shall persist an always visible top level action bar menu that
displays visible action items and hidden action items.
IFR1.3.1
The system shall visible action bar items are “Search” and “Recently Viewed”.
IFR1.3.2
If the system is not interacting with an object, the hidden action bar menu item
shall be “New Object” along with the action items listed in IFR1.3.1.
IFR1.3.3
If the system is currently displaying an Object on the screen, the hidden action
41
1.4.0
bar menu items shall contain the items “Edit” and “Delete”.
IFR1.3.4
If the system is in the process of creating an Object, the Action Bar shall contain
the visible action bar items listed in IFR1.3.1, and no hidden action bar items.
IFR1.4
The system shall provide forms that allow the user to input data into the
system.
IFR1.4.1
The system shall provide input areas for retrieving inputted text.
IFR1.4.2
The system shall capture input from an input area the moment the area is
pressed.
IFR1.4.2.1
The system shall highlight the input area when the area is pressed.
IFR1.4.2.2
The system shall persist the input data for processing.
IFR1.5
The system shall provide a scrolling function on all screens as necessary.
Requirement
ID
Statement
IFR3
The system shall create a dedicated category where emergency objects shall
be placed.
Requirement
ID
Statement
IFR4
The system shall allow the user to attach specific types of user-defined
meaning to objects.
IFR4.1
The system shall allow text captions, new images, new videos, or audio to be
attached to objects as attachments.
IFR4.1.1
The system shall allow text captions, existing pictures, or existing video to be
attached to an object while it is being created or updated.
IFR4.1.2
The system shall allow text captions, new pictures, new video, or new audio to
be attached to an object while it is being created or updated.
IFR4.2
The system shall allow the removal of text captions, pictures, videos, or audio
attachment from objects.
IFR4.3
The system shall allow only one attachment at a time per object.
42
1.4.0
IFR4.4
The system shall allow icon attachments.
IFR4.4.1
The system shall allow new or existing images or pictures to be attached as
icons.
Requirement
ID
Statement
IFR5
The system shall provide a search interface for objects.
IFR5.1
The system shall provide the user with a search form to input parameters for
objects.
IFR5.2
The system shall provide search as a form with an input area and navigation
button.
IFR5.3
The system shall perform search functionality when text input is provided.
IFR5.3.1
The system shall match parts of the text input with objects and their
associated tags.
IFR5.4
The system shall display all search results the moment there is a match with
currently entered text in the form.
IFR5.
The system shall represent an object by its icon and its caption in the search
results.
Requirement
ID
Statement
IFR8
The system shall present frequently selected objects within a recent time
period disjointly from other objects.
IFR8.1
The system shall display no more than the 5 most recently viewed objects in
this disjoint manner.
IFR8.1.1
The system shall consider “recent time span” as a period of 5 days.
IFR8.2
If the system detects that one of the search result objects has been singletapped, the system shall display that object’s form fields and attachment in a
new screen.
Requirement
Statement
43
1.4.0
ID
IFR9
The system shall allow users to create, update, modify, and delete multiple
types of specific objects.
IFR9.1
The system shall represent objects on screens as icons.
IFR9.1.1
The system shall represent an object by its icon attachment, if it has been
attached.
IFR9.1.2
If the object does not have an existing icon attachment, the system shall
represent the object with a default icon.
IFR9.1.2.1
The default icon shall be a pre-assigned image that is contextually descriptive of
the type of object.
IFR9.2
The system shall show the View <Object> inner frame screen the moment an
object icon has been single-tapped or single-clicked.
IFR9.2.1
The system shall display the following components on the View <Object> inner
frame screen: filled-in text fields that represent the system’s stored fields for
that object, an Emergency Indicator button, an“Add Attachment” button, a
button to remove an attachment, an “Add Icon” button, a button to remove the
icon, and a “Save Object.”
IFR9.2.2
The system shall present available attachments on the View <Object> inner
frame screen.
IFR9.2.2.1
If the attachment is an image, the system shall render the image on the View
<Object> inner frame screen.
IFR9.2.2.2
If the attachment is a video, the system shall render the video on the View
<Object> inner frame screen.
IFR9.2.2.3
If the attachment is an audio attachment, the system shall a display an audio
icon to indicate the presence of the audio attachment, and a “Preview Audio”
button on the View <Object> inner frame screen.
IFR9.2.2.3.1
If the “Preview Audio” button is actuated, the system shall be capable of
playing the audio attachment.
IFR9.2.3
The system shall ensure that all View <Object> inner frame screen elements are
locked.
IFR9.3
The system shall allow the creation of new objects.
44
1.4.0
IFR9.3.1
If the top menu Action Bar option “Create Object” is selected, the system shall
display a list of types of objects that can be created.
IFR9.3.1.1
The system shall display in the list of types of objects that can be
created: “People”, “Places”, and “Things”.
IFR9.3.1.2
The system shall display the following components on the Create <Object>
inner frame screen: blank text fields that represent the system’s stored fields
for that object, an Emergency Indicator button, an “Add Attachment” button, a
button to remove an attachment, an “Add Icon” button, a button to remove the
icon, and a “Save Object.”
IFR9.3.2
If the “Add Attachment” button is actuated, the system shall prompt the screen
with a menu containing the following items: “New”, “Existing”.
IFR9.3.2.1
If the system was prompted to add either a new video or a new image
attachment, the system shall actuate the camera object.
IFR9.3.2.1.1
Once the camera object has taken either the new image or the new video, the
system shall disable the camera object, provide the image or video path to the
system, and attach the image or video to the object.
IFR9.3.2.2
If the system was prompted to add a new audio attachment, the system shall
present an audio recording screen to enable the recording of audio.
IFR9.3.2.2.1
The system shall present a “Start/Stop Recording” button and a “Replay” button
on the audio recording screen.
IFR9.3.2.2.2
If the button to stop recording is actuated, the system shall disable the audio
recorder, close the audio recording screen, provide the audio file path to the
system, and attach the audio file to the object.
IFR9.3.2.3
If the system was prompted to select an existing attachment, the system shall
provide a gallery screen to select an existing image or video.
IFR9.3.2.3.1
Once a video or image has been selected from the gallery screen, the system
shall close the gallery screen, provide the image or video path to the system,
and attach the image or video to the object.
IFR9.3.3
If the “Add Icon” button was actuated, the system shall display a menu with the
following items: “New”, “Existing”, and “Use Current Attachment.”
IFR9.3.3.1
If the system was prompted to add a new icon, and the existing attachment is
an icon, the system shall not enable the “Use Current Attachment” option in the
menu described in IFR9.3.5.1.
45
1.4.0
IFR9.3.3.2
If the system was prompted to add a “New” Icon, the system shall actuate the
Camera object, take a picture, close the Camera object, provide the path to the
system, and attach the image as an icon.
IFR9.3.3.3
If the system was prompted to add an “Existing Icon”, the system shall open the
gallery of images.
IFR9.3.3.3.1
Once an image has been picked out of the gallery, the system shall close the
gallery, provide the path to the system, and attach the image as an icon.
IFR9.3.3.4
If the system was prompted to “Use the Current Attachment”, the system shall
ensure that the current attachment is either an image or a video, and attach it
as an icon.
IFR9.3.4
If the Save button was actuated, the system shall prompt the screen if the input
is correct, and if so, save the object to the system.
IFR9.3.5
If the system is directed to navigate from the current screen, the system shall
prompt the screen to indicate if the navigation move was intended and, if so,
clear the current Create <Object> screen and comply with the navigational
request.
IFR9.4
The system shall provide a method to update the information of an object.
IFR9.4.1
The system shall display the View <Object> inner frame screen if the object
was single-tapped or single-clicked.
IFR9.4.2
The system shall display and lock the following components on the View
<Object> inner frame screen: filled-in text fields that represent the system’s
stored fields for that object, an Emergency Indicator button, an “Add
Attachment” button, a button to remove an attachment, an “Add Icon” button,
a button to remove the icon, and a “Save Object.”
IFR9.4.3
If the top menu Action Bar item “Edit Object” is actuated, the system shall
unlock all object fields and enable all inner frame screen buttons.
IFR9.4.3.1
The system shall rename the inner screen text header to “Update <Object>
screen.”
IFR9.4.4
If the Add Attachment button is actuated, the system shall follow the
commands for attaching an object detailed in IFR9.3.2
IFR9.4.5
If the Add Icon button is actuated, the system shall follow the commands for
attaching an icon detailed in IFR9.3.3.
IFR9.4.6
If the Save Object button was actuated, the system shall prompt the screen if
46
1.4.0
the fields are acceptable, and if so, commit the new object data to the system.
IFR9.4.6.1
If the screen prompt to commit the new object data is negative, the system
shall not update the data of the object.
IFR9.4.6.2
The system shall display a screen that says if the update of information was
successful.
IFR9.4.7
If the system is forced to navigate from the current screen, the system shall ask
if the navigation move was intended and if so, clear the screen and comply with
the navigational request.
IFR9.5
The system shall provide a method to delete the object.
IFR9.5.1
The system display the View <Object> inner screen if the object was singletapped, or single clicked.
IFR9.5.1.1
The system shall display and lock the following components on the View
<Object> inner frame screen: filled-in text fields that represent the system’s
stored fields for that object, an Emergency Indicator button, an “Add
Attachment” button, an “Add Icon” button, and a “Save Object.”
IFR9.5.2
If the top menu Action Bar option “Delete Object” is actuated, the system shall
display a prompt on the screen asking if the Delete was intended.
IFR9.5.2.1
If the Delete command is validated, the system shall remove all information
corresponding to the object.
IFR9.5.2.2
The system shall display a screen confirming the delete.
Requirement
ID
Statement
IFR10
The system shall define object categories.
IFR10.1
The system shall define 4 types of categories: “People”, “Places”, “Things”,
and “Emergency”.
IFR10.2
All objects within the 4 defined categories defined in IFR10.1 shall be
internally organized alphabetically.
Requirement
ID
Statement
47
1.4.0
IFR11
The system shall present object categories on the upper main menu.
IFR11.2
The system shall present categories named
“People”,”Places”,”Things”, “Emergency.”
IFR11.3
The system shall represent the categories defined in IFR11.2 at all times in the
main upper menu.
IFR11.3.1
The system shall place all “People” objects that have been designated as an
emergency objects within the Category “Emergency Contacts.”
IFR11.3.2
The system shall place all “Places” objects that have been designated as an
emergency objects within the Category “Emergency.”
IFR11.4
When the system detects that a specific object category button has been
actuated, the system shall display all objects associated with that category in a
new screen.
IFR11.5
The system shall always display all objects associated with their respective
categories on screen.
Requirement
ID
Statement
IFR15
The system shall check the smartphone platform’s resources to ensure system
compatibility with minimum system operating requirements.
IFR15.1
The system shall run a check on the platform CPU speed, RAM capacity, and
Hard drive capacities in the beginning of the installation.
IFR15.1.1
If the platform does not meet the minimum requirements, the system shall not
continue with the installation.
IFR15.2
If the platform meets the minimum requirements, the system shall continue
with the installation.
48
1.4.0
3.2.2 Improved Understanding of II.2: NFRs
Requirement ID
INFR1
Statement
The system shall not display more than three layer of screens
above root layer.
Requirement ID
INFR2
Statement
The system shall require that the platform possess at least a 1ghz
single core processor, 250mb hard drive space, and 150mb of
system ram capacity.
Requirement ID
INFR3
Statement
The system shall require no more than two taps or clicks to
access any user interface element.
Requirement ID
INFR4
Statement
The system shall require a form of organization upon all objects
at all times.
Requirement ID
INFR9
Statement
The system shall respond to a user navigational request within
two seconds.
Requirement ID
INFR11
Statement
The on-platform technologies used to provide user-defined
meaning shall not require third-party driver or plug-in support.
Requirement ID
INFR14
49
1.4.0
Statement
The system’s emergency objects must be accessible from
anywhere in the user interface within five seconds.
Requirement ID
INFR16
Statement
Any on-platform technology used by the user to provide selfmeaning to an object must provide output that be attached to
an object.
Requirement ID
INFR17
Statement
The system search mechanism shall return results within three
seconds.
50
1.4.0
Preliminary Prototype
51
1.4.0
Traceability
DR
DR1
DR2
DR3
DR4
DR5
DR7
IDR
IDR1
IDR2
IDR3
IDR4
IDR5
IDR7
DR
DR1
DR2
DR3
DR4
DR5
DR7
IDR
IDR1
IDR2
IDR3
IDR4
IDR5
IDR7
FO
FO1
FO3
FO5
FO7
FO11
IFO
IFO1
IFO3
IFO5
IFO7
IFO11
FO
FO5
FO5
FO1, SR1
FO3, SR1
FO11
FO7
IFO
IFO5
IFO5
IFO1, ISR1
IFO3, ISR1
IFO11
IFO7
NFO
NFO1
NFO1
NFO1
NFO5
NFO3
NFO4
INFO
INFO1
INFO1
INFO1
INFO5
INFO3
INFO4
FR
FR1
FR4
FR5,8,9,10,11
FR3
FR15
IFR
IFR1
IFR4
IFR5,8,9,10,11
IFR3
IFR15
52
1.4.0
NFO
INFO
FR
IFR
NFO1
NFO3
NFO4
NFO5
INFO1
INFO3
INFO4
INFO5
FR1,5,8,9,10,11
FR15
FR3
FR4
IFR1,5,8,9,10,11
IFR15
IFR3
IFR4
NFO
INFO
NFR
INFR
NFO1
NFO3
NFO4
NFO5
INFO1
INFO3
INFO4
INFO5
NFR1,3,4,9,17
NFR2
NFR14
NFR11,16
NFR1,3,4,9,17
INFR2
INFR14
INFR11,16
53
1.4.0
Creep Rate Approximation
Total Recall feels that due to the flexibility and compactness of the system design from a Nonfunctional objectives perspective, the team can handle a specific amount of creep rate that will
be calculated below.
The system contains the following Non-functional objectives. Each non-functional objective has
a specific number of functional objectives, non-functional requirements, and functional
requirements associated with it.
NFO
FO
NFR
FR
Total
Scope Creep
Impact
1
3
5
6
15
60%
3
1
1
1
3
12%
4
1
1
1
3
12%
5
1
2
1
4
16%
25
100%
The most costly scope creep impact would be felt in the domain of NFO1, which is usability
regarding the system. As such, if scope creep were to occur in this area, it would likely devote
much, if not all, of the organizational resources. Therefore, the team feels that it can handle a
scope rate creep of 60% if the scope creep is localized to NFO1.
All other NFO domains are relatively light-weight compared to NFO1. As such, taking the
average of the impact within NFOs 3,4,5, each NFO has an impact of average 13.3%. Therefore,
the team feels it is capable of handling a creep rate of 13.3%, if the scope creep does not
involve NFO1.
54
1.4.0
Why Team Total Recall
Here at Total Recall, we pride ourselves as a disciplined and motivated software development
organization. Our methods of development rely on proper product and process engineering
practices throughout the entire development life-cycle of a system. What is produced at the
end is a functioning software system that answers the problems of the client with a solution
that functions exactly as documented per the system requirements.
Effective organization practices guiding the process engineering of any software development
effort are absolutely critical for ultimately producing a solution to the client’s problem. At Total
Recall, we stress the following best practices:
Accountability: Work units are completed before internal deadlines.
Accuracy: Work units are generated through requirements analysis.
Quality Assurance: Work units are tested against the system requirements.
Communication: Teams have multiple points of contact internally and externally.
Due to the best practices listed above, we are confident that our development process is
efficient and highly flexible. As a result, the project objectives guiding the development effort
are clearly known and produce high quality deliverables. Our deliverables are grounded in the
following:
Specific system domain and concise scope declarations.
Traceable system functional and non-functional objectives.
Accurate functional requirements modeling.
Superior documentation.
In conclusion, Total Recall is confident in our process and product engineering. We ensure the
capability of our process by enforcing best practices. Our product engineering, as a result, is
superior. Therefore, no matter the problem presented, we feel that our organization can and
will provide the solution.
55
1.4.0
Appendix A
The Stages of Dementia
1. No impairment. At this stage, there are no obvious signs of dementia and people are still able to function independently.
2. Very mild. Dementia signs are barely noticeable and simply appear to be the kind of forgetfulness associated with aging —
such as misplacing keys but finding them again after some searching.
3. Mild. At this stage, patients are “usually able to do basic activities of daily living,” says Shah — which means they can
perform their daily routines, such as getting up, going to the bathroom, getting dressed, and so on, without difficulty.
Symptoms of dementia at this stage may include:
a. Some forgetfulness and memory loss
b. Repetition
c. Losing items without being able to retrace steps to find them
d. Slight trouble managing finances, such as balancing a checkbook
e. Confusion while driving
f. Trouble managing medications
g. Loss of concentration
4. Moderate. At this stage patients have “trouble doing routine tasks that they always did, such as cooking, laundry, or using
the phone,” explains Shah. Other dementia symptoms during this stage include:
a. Trouble holding urine (incontinence)
b. Increase in memory loss and forgetfulness
c. Inability to use or find the right words and phrases
d. Difficulty doing challenging mental math exercises, such as counting backwards from 100 by 7
e. Increase in social withdrawal
5. Moderately severe. At this stage, dementia patients will need some assistance with their day-to-day activities. Symptoms
of moderately-severe dementia include:
a. Increase in memory loss, including inability to remember home address, phone number, or other personal
details
b. Confusion about location or chain of events
c. Trouble with less challenging mental math exercises
d. Needing help to select appropriate clothing for the climate, season, or occasion
56
1.4.0
6. Severe. “Caregivers have to help a lot more with day-to-day activities” at this stage, says Shah. Dementia signs at the
severe stage include:
a. Needing help to get dressed
b. Requiring help with toileting, such as wiping and flushing
c. Wandering and becoming lost if not supervised
d. Inability to recall the names of family members or caregivers, but still
e. Sleep disturbances
f. Changes in personality or behavior, such as increased paranoia or even hallucinations
7. Very severe. This is the final stage of the disease. Symptoms of dementia during this stage include:
a. Loss of language skills
b. Loss of awareness of surroundings
c. Requiring help to eat
d. Lack of control over urination
e. Loss of muscle control to smile, swallow, or even walk or sit without being able to recognize familiar faces
57
1.4.0
Appendix B
Visual Requirements Chart
58
1.4.0