PRODUCT - WRS.docx.docxchung/CS4351... · Web viewThe extent to which AAC applications facilitate...

SE 4351.001 Software Requirements

Fall 2014

WRS

http://www.utdallas.edu/~axp120531/SE4352/

Team Members

Joe Brownjsb100120

Desmond Leedcl102020

Giuseppe Mastrolorenzo

mxg106320

Michael Raibickmxr110530

Ryan Chenrxc109520

Robert Lockwoodrll092020

Blessing Osakueboo102020

Oscar Reyesoxr110330

Travis Chuntwc101020

Michael Muggermxm121531

Andrew Pohlmannaxp120531

James Williamsjxw110730

Bennilyn Quekbxq120430

1

1.5.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 Sections 3.2.1

1.4.0 10/10/2014 Updated prototype screenUpdated ProcessAdded Creep Rate ApproximationAdded Why Team Total Recall

1.5 11/15/2014 Updated Process tableUpdated SpecificationsUpdated Prototype Screens

1.6 11/24/2014 Cosmetic Updates

1.7 12/01/2014 Final Check

2

1.5.0

Process

Management Meetings

Team Date Time Location Team Members Present

Management 12/01/2014 1-3:00pm CST Longhorn Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

11/24/2014 1-3:00pm CST Longhorn Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

11/17/2014 1-3:00pm CST Topaz Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

11/10/2014 1-3:00pm CST Monarch Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

10/27/2014 1-3:00pm CST Monarch Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

10/13/2014 1-3:00pm CST Longhorn Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

10/06/2014 1-3:00pm CST Topaz Room, UTD Andrew PohlmannMichael RaibickBennilyn Quek

09/29/2014 1-3:00pm CST Topaz Room, UTD Andrew PohlmannBlessing OsakueMichael MugglerMichael Raibick

3

1.5.0

09/22/2014 1-5:00pm CST Bluebonnet Room, UTD Andrew PohlmannBlessing OsakueMichael MugglerMichael RaibickBennilyn Quek

09/15/2014 1-3:30PM CST Longhorn Room, UTD Andrew PohlmannBlessing OsakueMichael MugglerMichael Raibick

09/08/2014 1-3:00PM CST Starbucks, UTD Andrew PohlmannBlessing OsakueMichael MugglerMichael Raibick

4

1.5.0

Table of ContentsRevision History

Process

Phase 1 - Interim

Introduction

2.1.1 Domain Issues

2.1.2 Stakeholder Issues

2.1.3.1 Functional Objectives Issue Identification

2.1.3.2 Nonfunctional Objectives Issue Identification

2.2 Functional Requirements Issue Identification

2.3 Nonfunctional Requirements Issue Identification

3. WRS

3.1 W

3.1.1 Problem

3.1.2 Goal

3.1.3 Improved Understanding of II.1

3.1.3.1 Domain

3.1.3.2 Stakeholder

3.1.3.3 Functional Objective

3.1.3.4 Non-Functional Objective

3.2 RS

3.2.1 Improved Understanding of II.2: FRs

3.2.2 Improved Understanding of II.2: NFRs

Preliminary Prototype

Traceability

Visual Requirements Chart

5

1.5.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 touch-screen 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 communicate more effectively by developing a software system that is quickly and efficiently able to recall objects that the user has forgotten.

6

1.5.0

2.1.1 Domain IssuesDomain 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.2. Does the scope of the system change based on how an

emergency may change the abilities of a user?

Decision Solution 1 shall be picked.

Therefore,This project’s domain of disability assistance shall be defined as assistance for those suffering Stage 3 or “Mild” on the medical scale “The Stages of Dementia”, regardless of an emergency situation or not.

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.


Therefore,The system shall not provide functionality to solve problems originating from other disabilities in the world domain.

7

1.5.0

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.

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.



Therefore,The system shall only assist users who fit the cognitive and physical capabilities as defined in DR1 and 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. The statement implies that the system must engage all sensory facilities of the user to be effective in its fulfilling its goal of

8

1.5.0

defined in DR1.2. The statement implies that the user is incapable of

comprehending meaning without substantial sensory aid and thus regardless of system scope or domain of assistance, the system must assist the user in comprehending the meaning of an object.



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 1. Accept this statement.


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.”

9

1.5.0

Issues 1. Definition of an “emergency situation” is vague. What is an “emergency? “What is an “emergency situation.”?

2. Will the system scope of assistance change if an emergency situation occurs?

Solutions 1. Define “emergency.”2. Define an “emergency situation.”3. Define the system scope of assistance with regard to DR1

Decision 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.

10

1.5.0

2.1.2 Stakeholder Issues

Stakeholder Issue ID SR1


Issues The term “people” is vague and does not accurately represent the stakeholder group that may be using the system.

Solutions 1. Define the system stakeholders.


The Stakeholder groups shall be defined as the following:User System userNon-User: Organization Requirements Engineer UI/UX Engineer Software Architect Software Developer Project Manager

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 non-disabled 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.

11

1.5.0


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.

2.1.3.1 Functional Objectives Issue Identification

Justification ID DR1, DR2, DR3, DR4

Objective ID FO1


Issues 1. “Communication” as used is vague. Is “communication” itself an “event/situation” or is “communication” the act of conveying information?

Solutions 1. Define “communication/”2. 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

12

1.5.0

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) and 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.

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. Define “daily living activities” and “typical activities.”2. 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,

13

1.5.0

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 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.



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.

14

1.5.0

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. “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.

2. The statement as a whole assumes that the system shall construct “basic communication messages,”

3. The statement is implying that the system must assist the user express his/her will, regardless of scope.

Solutions 1. Define the scope of system assistance with regard to DR1 and DR4.

Decision 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

15

1.5.0

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 1. “Multi-dimensional vocabulary” is very vague. What signifies “mult-dimensionality”? Context? Type? Usage?

2.3. The terms “disjoint category” and “overlapping category” are

vague due to the lack of definition of “multi-dimensional.”

Solutions 1. Define what “multi-dimensional vocabulary” means.2. Define what a category is based on the understanding of what

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,FO5Objects are items the user wants to remember.

FO5.1Categories are collections of objects that have a contextually similar relation to each other.

FO5.2All 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.

16

1.5.0

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 system detecting the emergency and then responding to the appropriate outside entities?



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.


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.

17

1.5.0

Solutions 1. Reword this functional objective as:“The system shall assist the user in an emergency situation by recognizing the uniqueness of emergency contacts.”


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.


Objective ID FO11

Statement “The mobile platform must have the necessary environmental resources to run the system.”

Issues None.

Solutions 1. Accept the statement as is.


Therefore,The mobile platform must have the necessary environmental resources to run the system.

Rationale Because of the nature of data stored by the person on this system, the system must include functionality that is designed to ensure that the user’s data is protected at a minimum level.

18

1.5.0

2.1.3.2 Nonfunctional Objectives Issue Identification

Objective ID NFO1

Statement Usability - The system must be intuitive and easy to use.

Objective ID NFO3

Statement Performance - The system shall ensure low-latency operation.

Objective ID NFO4

Statement Emergency - The system shall recognize the uniqueness of emergency contacts by maintain specific functionality for organizing emergency contacts.

Objective ID NFO5

Statement Hardware Extensibility - The system shall implemented limited on-platform hardware extensibility.

19

1.5.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.


Therefore,The system shall provide a graphical user interface that consists of menus, buttons, and forms.

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.



20

1.5.0

Therefore,The system shall create a dedicated emergency category that contains all objects deemed as emergency.

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 given 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. The term “specific meaning” is vague. What type of descriptor imparts a “specific meaning” to each picture?

2. How can the system tell if one interpretation out of a thousand is sufficient given the user?

Solutions 1. Define the system’s role in assisting the user with comprehending an object.

Decision Solution 1 will be picked.

Therefore,The system shall allow the user to attach specific types of user-defined 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.


Requirement ID FR5

Statement Making each vocabulary item available through a search interface.

Issues 1. No issues with this statement, other than replacing the term

21

1.5.0

Andrew Pohlmann, 09/26/14,

The system shall allow user-defined descriptors of objects.


The system shall employ a search mechanism that can traverse through each object.

“vocabulary item” with object.

Solutions 1. Define a manner in which objects can be searched through.


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. The phrase “integrating already available technologies” is vague.

2. Are these technologies internal smartphone features, internal applications, or separate applications not native to the operating system.

3. Are these technologies meant to assist users with out of scope impairments?

Solutions 1. Reject this requirement as redundant given FR4.2. 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.

Decision Solution 1 will be chosen.

Therefore,This functional requirement shall be rejected.

Rationale


Requirement ID FR8

22

1.5.0


The system shall allow existing organic smartphone technologies to be attached to objects to remind the user.

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 frequently used objects.

Rationale This is an important requirement that will greatly enhance the user experience.


Requirement ID FR9

Statement “System shall allow user to create multiple specific types of objects.”

Issues 1. No issues with this statement.

Solutions 1. Accept requirement.

Decision Solution 1 shall be chosen.

Therefore,System shall allow user to create, retrieve, update, and delete specific types of objects.

Rationale The user will find increased usefulness from the system if he or she can add as many as objects as possible.


Requirement ID FR10

Statement “System shall allow user to create multiple specific types of

23

1.5.0


System shall pre-define set categories.


The system shall allow the user to make multiple same objects per category.

categories.”

Issues 1. No issues with this statement.

Solutions 1. Accept requirement.


Therefore,The system shall define a set of category types.

Rationale The system will increase usability by determining pre-existing categories of objects.


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 in fewer clicks.

Issues 1. “Sentences are generated in fewer clicks” is outside the scope of this system.

2. Objects organized in “many contexts” represents complexity that is not only difficult to define, but challenging to implement.

Solutions 1. Remove “sentences are generated in fewer clicks.”2. 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.

Decision 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.

24

1.5.0


The system shall be organized by their type.


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.


Therefore:The system shall check the smartphone platform’s resources to ensure system compatibility with minimum system requirements.

25

1.5.0

2.3 Nonfunctional Requirements Issue Identification

Justification ID NFO1, FO1, FR1

Requirement ID NFR1

Statement The system should be usable.

Issues 1. Usability is ambiguous without a clear metric. Does this mean the system should not crash or have minimal crashing.

2. 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.

Solutions 1. Define the term usability in terms of the user interface.


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.


Requirement ID NFR2

Statement The system shall be ubiquitous.

Issues 1. The context and scope of ubiquitous is undefined and ambiguous. Should the system or user interface be ubiquitous and where should it be found?

2. 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.

3. Ubiquity means that performance characteristics of the system cannot be defined because computing systems all have varying levels of power.

26

1.5.0


This is a system designed for 1 type of hardware platform and 1 type of software environment.


The system shall be usable.

Solutions 1. Reword this statement to reflect the hardware/software platform constraint of the project.

Decision 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.


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. 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.

2. 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?

Solutions 1. The system shall require only two taps or clicks at most to access any functionality in the system.


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.

27

1.5.0


The system shall require only simple input from the user.

Justification ID NFO1, FO5, FR5, FR8, FR9, FR10, FR11, FR16

Requirement ID NFR4

Statement The vocabulary organization should be clear and intuitive.

Issues 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.

2. The metrics and measuring instructions are not defined. Further no acceptable ranges with tolerances are defined to constitute acceptable clarify and intuitiveness.

3. 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.

Solutions 1. Define a system requirement regarding the organization of objects.


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. This requirement is too broad and cannot be guaranteed in all cases as it is dependent on a variety of factors concerning the user.

2. 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.

3. No method of measuring and acceptable ranges with tolerances are given to ensure that the interface is seamless and evident to all users.

28

1.5.0


The system will always remind the user of where he/she is in relation to root level.


Objects shall be organizable and searchable.

Solutions 1. Provide a persisted object that is always on the top layer of the display that displays current location of user relative to root.

2. Reject this requirement as being unnecessary.

Decision Solution 2 will be taken.

Therefore,This non-functional 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.


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

29

1.5.0


REJECTED - The system shall not help the user physically express himself.



characteristics of a system feature that has been deemed out of scope by FO4.

Solutions 1. Reject this non-functional requirement on the basis of DR1.



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.




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.


30

1.5.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. 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.

2. This requirement does not define meaningful metrics and measurement instructions to provide proof of the appropriate level of performance.

Solutions 1. Set a defined system response time to any type of user input.


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.


Therefore,This non-functional requirement will be rejected.

Rationale This non-functional requirement describes a non-existent system

31

1.5.0




The system shall quickly respond to the user.

functionality that would assist the user in expressing self, and as such is irrelevant and unnecessary.



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 system-approved descriptors.


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


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. “Variations in interface” is vague and incomplete. Do “variations in interface” change or interrupt functionality?

2. Will “variations in interface” confuse the user? How will the system go about in real time changing the interface?

3. Variations of “language” is unsound because the software developers cannot hope to accommodate all potential different languages.

32

1.5.0


REJECTED - The system is designed on a very hardware/software constrained platform.


The system shall allow the user to define his or her own meaning only in an approved manner.

4. “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?

5. “Variations of features” is unsound. The system is designed to accomplish a specific objective.

6. “Variations of hardware” is not applicable to an otherwise closed upgrade platform like a smartphone.

Solutions Reject this requirement.

Decision Solution 1has been chosen.


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.



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 occured?

Solutions 1. Define a system requirement that impacts how quickly the system will present emergency objects.


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.

33

1.5.0


The system must allow the user to access emergency contacts within 3 seconds.



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.


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 NF01, FO5, FR5


Statement “The system search mechanism shall return results within 3 seconds.”

Issues 1. None.

Solutions 1. Allow nonfunctional requirement.


Therefore,The system search mechanism shall return results within 3 seconds.

Rationale It is important that the system be quick to return search results.

34

1.5.0


The system shall allow the inclusion of specific local organic technologies if they assist the user in remembering.


The system shall allow the inclusion of specific local organic technologies if they assist the user in remembering.

3. WRS

3.1 W

3.1.1 ProblemThe 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 GoalThe 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) in recalling pertinent information to facilitate communication.

35

1.5.0

3.1.3 Improved Understanding of II.1

3.1.3.1 Domain

Requirement ID Statement

IDR1 This project’s domain of disability assistance shall be dementia, targeted at stage 3. See the Appendix Document: “The Stages of Dementia”


IDR2 The system’s scope of assistance shall only be only for those suffering from stage 3 dementia.


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.


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.


IDR5 This system’s hardware and software platform target is a smartphone that runs the Android OS.


36

1.5.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 Stakeholder


ISR1 The stakeholder groups are defined as:User System userNon-User Requirements Engineer UI/UX Engineer Software Developer Software Architect Project Manager

37

1.5.0

3.1.3.3 Functional Objective


IFO1 The system shall present a system to the user so that the user may find the object he or she cannot remember.


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.


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.


FO7 The system shall provide direct and accurate access to emergency objects.


IFO11 The mobile platform must have the necessary environmental resources to run the system.

38

1.5.0

3.1.3.4 Non-Functional Objective


INFO1 The system user interface shall be intuitive and easy to use.


INFO3 The system shall ensure quick response times while operating.


INFO4 The system shall maintain specific functionality for handling emergency contacts.


INFO5 The system shall support limited hardware and software extensibility.

39

1.5.0

3.2 RS

3.2.1 Improved Understanding of II.2: FRs


IFR1 The system shall provide a graphical user interface that consists of menus, buttons, and forms.

IFR1.1 The system shall provide areas on the screen where menus and buttons shall be anchored

IFR1.2 The system shall provide a navigational mechanism to view specific categories of objects.

IFR1.3 The system shall provide a navigational mechanism to view recently accessed objects

IFR1.4 The system shall provide a navigational mechanism to view emergency objects.

IFR1.5 The system shall provide buttons to perform actions on objects.

IFR1.5.1 The system shall provide a button for creating an object.

IFR1.5.2 The system shall provide a button for editing an object.

IFR1.5.3 The system shall provide a button for deleting an object.

IFR1.6 The system shall not block the display or operating action of the native Android-provided default navigational buttons.

IFR1.6.1 If the native platform-provided “Back” button is tapped, the system shall attempt to go to the previous inner frame screen (if it exists).

IFR1.6.2 If the native platform-provided “Home” button is tapped, the system shall immediately attempt to minimize the Total Recall application completely.

IFR1.6.3 If the native platform-provided “Recently Used Applications” button is tapped, the system shall immediately carry out the platform programming attached to the “Recently Used

40

1.5.0

Applications” button.


IFR3 The system shall create a dedicated emergency category that contains all objects deemed as emergency.

IFR3.1 The system shall aggregate all objects designated as emergency objects in the emergency category, no matter the object type.


IFR4 The system shall allow the user to attach specific types of user-defined meaning to objects.

IFR4.1 The system shall allow a single image to be attached to an object.

IFR4.1.1 The system shall provide a way to remove an attachment from its parent object.

IFR4.2 The system shall allow a single icon to be attached per object.

IFR4.2.1 The system shall allow new or existing images to be attached as icons.


IFR5 The system shall provide a search interface for objects.

IFR5.1 The system shall perform search functionality as text input is provided.


IFR8 The system shall present frequently used objects.

IFR8.1 When the button to display recently viewed objects is tapped, the system present all objects marked as recently viewed to the screen immediately.

41

1.5.0


IFR9 System shall allow user to create, retrieve, update, and delete specific types of objects.

IFR9.1 The system shall represent an unaccessed object on the inner frame screen by its icon attachment and associated name.

IFR9.1.1 If the object does not have an existing icon attachment, the system shall represent the object with a default icon.

IFR9.2 The system shall immediately display a new screen that contains that object’s persisted information an the moment object icon has been tapped, including its attachment and icon.

IFR9.3 The system shall allow the creation of new objects.

IFR9.3.1 If the button to create a new object is tapped, the system shall immediately display a menu consisting of the types of objects that can be created by the system.

IFR9.3.1.1 The menu generated in IFR9.3.1 shall contain the following options: “Person”, “Place”, “Thing”.

IFR9.3.1.2 If input is received from the menu generated in IFR9.3.1, the system shall immediately display a new screen that contains fields and buttons to allow data to be added to the object.

IFR9.3.2 If the “Add Attachment” button is tapped, the system shall immediately prompt the screen with a menu containing the following items: “Camera”, “Gallery”.

IFR9.3.2.1 If the “Camera” option is tapped, the system shall allow the user to take a picture and then return to the system with the path of the picture.

IFR9.3.2.2 If the “Gallery” option is tapped, the system shall allow the user to select a picture from the internal storage of the device and then return to the system with the path of the picture.

IFR9.3.3 If the “Add Icon” toggle button is tapped, the system shall immediately prompt the screen with a menu containing the following items: “Camera”, “Gallery”.

IFR9.3.3.1 If the “Camera” option is tapped, the system shall allow the user to take a picture and then return to the system with the path of

42

1.5.0

the picture.

IFR9.3.3.2 If the “Gallery” option is tapped, the system shall allow the user to select a picture from the internal storage of the device and then return to the system with the path of the picture.

IFR9.3.4 The system shall immediately attempt to display an attachment and/or icon if it detects that one or both have been added to object.

IFR9.3.5 The system shall provide a mechanism to remove an attachment and/or icon.

IFR9.3.5 If the system is directed to navigate from the current screen, the system shall immediately prompt the screen with a menu to indicate if the navigation move was intended and, if positive, clear the current inner frame 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 If the button to edit an object is tapped, the system shall immediately display a new screen that contains that object’s persisted information, including its attachment and icon data.

IFR9.4.1.1 The system shall ensure that the fields on the screen are editable.

IFR9.4.2 If the Add Attachment button is tapped, the system shall follow the commands for attaching an object detailed in IFR9.3.2

IFR9.4.3 If the Add Icon toggle button is tapped, the system shall follow the commands for attaching an icon detailed in IFR9.3.3.

IFR9.4.4 If the Save Object button is tapped, the system shall immediately prompt the screen with a menu confirming object fields.

IFR9.4.4.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.4.2 If the screen prompt to commit the new object data is positive, the system shall save the object and then display confirmation of the successful save operation.

IFR9.4.5 If the system is directed to navigate from the current screen, the system shall immediately prompt the screen with a menu to

43

1.5.0

indicate if the navigation move was intended and, if positive, clear the current inner frame screen and comply with the navigational request.

IFR9.5 The system shall provide a method to delete the object.

IFR9.5.1 If the button to delete an object is tapped, the system shall display a prompt on the screen asking if the delete command was intended.

IFR9.5.1.1 If the Delete command is validated, the system shall immediately remove all information corresponding to the object and display a screen confirming the delete of the object from the system.


IFR10 The system shall define a set of category types.

IFR10.1 The system shall define 4 types of categories: “People”, “Places”, “Things”, “Emergency”.


IFR11 The system shall present object categories based on type.

IFR11.1 The system shall use menus to present object categories.

IFR11.2 The system shall label each category menu item type by the type of object it displays .

IFR11.3 When the system detects that a specific object category menu item has been selected, the system shall display all objects associated with that category in the inner frame screen.


IFR15 The system shall check the smartphone platform’s resources to ensure system compatibility with minimum system 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.

44

1.5.0

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.

3.2.2 Improved Understanding of II.2: NFRs


INFR1 The system shall not display more than three layer of screens above root layer.


INFR2 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.


INFR3 The system shall require no more than two taps or clicks to access any user interface element.


INFR4 The system shall require a form of organization upon all objects at all times.


45

1.5.0

INFR9 The system shall respond to a user navigational request within two seconds.


INFR11 The on-platform technologies used to provide user-defined meaning shall not require third-party driver or plug-in support.


INFR14 The system’s emergency objects must be accessible from anywhere in the user interface within five seconds.


INFR16 Any on-platform technology used by the user to provide self-meaning to an object must provide output that be attached to an object.


INFR17 The system search mechanism shall return results within three seconds.

46

1.5.0

Preliminary Prototype

47

1.5.0

Traceability

DR IDR FO IFODR1 IDR1 FO5 IFO5DR2 IDR2 FO5 IFO5DR3 IDR3 FO1, SR1 IFO1, ISR1DR4 IDR4 FO3, SR1 IFO3, ISR1DR5 IDR5 FO11 IFO11DR7 IDR7 FO7 IFO7

DR IDR NFO INFODR1 IDR1 NFO1 INFO1DR2 IDR2 NFO1 INFO1DR3 IDR3 NFO1 INFO1DR4 IDR4 NFO5 INFO5DR5 IDR5 NFO3 INFO3DR7 IDR7 NFO4 INFO4

FO IFO FR IFRFO1 IFO1 FR1 IFR1FO3 IFO3 FR4 IFR4FO5 IFO5 FR5,8,9,10,11 IFR5,8,9,10,11FO7 IFO7 FR3 IFR3FO11 IFO11 FR15 IFR15

48

1.5.0

NFO INFO FR IFRNFO1 INFO1 FR1,5,8,9,10,11 IFR1,5,8,9,10,11NFO3 INFO3 FR15 IFR15NFO4 INFO4 FR3 IFR3NFO5 INFO5 FR4 IFR4

NFO INFO NFR INFR

NFO1 INFO1 NFR1,3,4,9,17 NFR1,3,4,9,17NFO3 INFO3 NFR2 INFR2NFO4 INFO4 NFR14 INFR14NFO5 INFO5 NFR11,16 INFR11,16

49

1.5.0

Visual Requirements Chart

50

1.5.0

PRODUCT - WRS.docx.docxchung/CS4351... · Web viewThe extent to which AAC applications facilitate...

Documents

Transcript of PRODUCT - WRS.docx.docxchung/CS4351... · Web viewThe extent to which AAC applications facilitate...