evolving wrs.docx.docx - the university of texas at …chung/cs4351/presentations14f/total... ·...

SE 4351.001 Software Requirements

Fall 2014

Evolving WRS

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

Team Members

Joe Brownjsb100120

Desmond Leedcl102020

Giuseppe Mastrolorenzomxg106320

Michael Raibickmxr110530

Ryan Chenrxc109520

Robert Lockwoodrll092020

Blessing Osakueboo102020

Oscar Reyesoxr110330

Travis Chuntwc101020

Michael Muggermxm121531

Andrew Pohlmannaxp120531

James Williamsjxw110730

Bennilyn Quekbxq120430

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 screenUpdated ProcessAdded Creep Rate ApproximationAdded Why Team Total Recall

1.4.1 10/15/2014 Updated Section 3.2.1Fixed 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 PohlmannMichael Raibick

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

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

3

1.4.0

Table of ContentsRevision 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 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 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 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.

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.


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.



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

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



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

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

8

1.4.0

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.

9

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

10

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

11

1.4.0

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

13

1.4.0

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.

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

14

1.4.0

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

Solutions 1. Define what “multi-dimensional vocabulary” means.

15

1.4.0

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.

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

16

1.4.0

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.

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

17

1.4.0

system’s assumptions of user capabilities. The system will, however, classify emergency objects disjointly from all other objects due to their unique function in the real world.


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


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.



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. 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.4.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 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 object, this functional requirement is rejected in a standalone fashion, but is

22

1.4.0


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

effectively implemented in FR4.


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.


Requirement ID FR9

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

Issues 1. What is the practical limit on the specific types of objects the user can create?

2. If the user can create multiple types of objects, is there any limit on the types of objects that can be created?

Solutions 1. Consider the requirement with respect to the issues raised and the organization’s ability to implement them.

Decision Solution 1 shall be chosen.

Therefore,

23

1.4.0


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

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.


Requirement ID FR10

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

Issues 1. What is the practical limit or number of categories?2. If the user is creating categories on their own, what determines

the fields of the objects that those categories would organize?3. 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.

Solutions 1. Consider the requirement with respect to the issues raised and the organization’s capability to implement them.


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.


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.

24

1.4.0


The system shall be organized by their type.


System shall pre-define set categories.

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.


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


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

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

27

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

28

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

29

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

30

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


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.




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.


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

32

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

33

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



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

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.

34

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



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.

35

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


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


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 domain regarding hardware and software platforms is a smartphone that is running the Android OS.


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


ISR1 The stakeholder groups are defined as:

1. Usera. System user

2. Non-Usera. Requirements Engineerb. Software Developerc. User Interface Engineerd. Project Managere. Financial Backer

38

1.4.0

3.1.3.3 Improved Understanding of Functional Objectives


IFO1 The system shall present a user interface 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.

39

1.4.0

3.1.3.4 Improved Understanding of Non-Functional Objectives


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


NFO3 The system shall ensure quick response times while operating.


NFO4 The system shall maintain specific organization for handling emergency contacts.


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.

41

1.4.0

IFR1.3.3 If the system is currently displaying an Object on the screen, the hidden action 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.

42

1.4.0

IFR4.3 The system shall allow only one attachment at a time per object.

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 single-tapped, the system shall display that object’s form fields and attachment in a new screen.

43

1.4.0

Requirement ID

Statement

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 single-tapped, 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.


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.


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


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


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


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


49

1.4.0

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


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


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

50

1.4.0

Preliminary Prototype

51

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

52

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

53

1.4.0

Creep Rate Approximation

Total Recall feels that due to the flexibility and compactness of the system design from a Non-functional 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

56

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

57

1.4.0

d. Needing help to select appropriate clothing for the climate, season, or occasion

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

58

1.4.0

Appendix B

Visual Requirements Chart

59

1.4.0

evolving wrs.docx.docx - the university of texas at …chung/cs4351/presentations14f/total... ·...

Documents