Veritas d1.7.1 Final

Accessible and Assistive ICT
VERITAS
Virtual and Augmented Environments and Realistic User
Interactions To achieve Embedded Accessibility DesignS
247765
Final version of VERITAS Use Cases and

Application Scenarios
Deliverable No. D1.7.1.a

SubProject No. SP1 SubProject Title User Modelling
Workpackage W1.7 Workpackage Title Use Cases and application
No. scenarios
Activity No. A1.7.3 Activity Title Use Cases
Authors Eleni Chalkia, Evangelos Bekiaris, (CERTH/HIT),

Karel Van Isacker (MCA), Serge Boverie (CAF),
Onorino Di Tanna (PIAGGIO), Nikos
Partarakis(FORTH), Kostas Moustakas (ITI),
Hans-Joachim Wirsching (HS), Maria Fernanda
Cabrera (UPM), Elena Tamburini (I+), Mytas
Nicolas (BYTE)
Status F (Final)
Dissemination Level: Pu (Public)
File Name: VERITAS_D1.7.1_final
Project start date and 01 January 2010, 48 Months

duration
VERITAS_D1.7.1 PU Grant Agreement # 247765
Version History table

Version Dates and comments
no.
1 1st Draft created from CERTH/HIT before the 1st Review. June 2010
2 Creating a 2nd Draft by implementing the Review commends. August

2010
3 Receiving and implementing comments and input from the partners

having in mind avoiding the inconsistencies with the DoW and among
the Use Cases. 3rd Draft. November 2010
4 Creating a methodology for the prioritisation of the Use Cases during the
Workshop and Use Forum meeting. November 2010
5 Updating the Use Cases including the prioritisation phase from the
Workshop and Use Forum meeting. December 2010
6 Sending the final Use Cases to the partners and receive comments.
December 2010
7 Creating a final Draft and send it for peer review. December 2010
December 2010 iii CERTH/HIT

Table of Contents
Version History table ....................................................................... iii
Table of Contents ............................................................................ iv
List of Figures .................................................................................. vi
List of Tables ................................................................................... vi
List of Abbreviations ....................................................................... vii
Executive Summary......................................................................... 1
1 Introduction ............................................................................... 3
1.1 The Use Cases concept ........................................................................ 4
1.1.1 Use Cases modelling ............................................................................... 4
2 The VERITAS Use Cases methodological framework ............... 9
2.1 Use Cases descriptions......................................................................... 9
2.1.1 Scenarios and Goals ............................................................................. 10
2.1.2 Other Use Cases Elements ................................................................... 11
2.2 Personas added value......................................................................... 13
3 Methodology of VERITAS Use Cases extraction ..................... 15
3.1 Correlation with the User Requirements.............................................. 18
4 Use Cases list ......................................................................... 29
5 Use Cases description............................................................. 31
5.1 Use Framework ................................................................................... 31
5.1.1 Interface with external applications ........................................................ 32
5.1.2 Generation of virtual test sample ........................................................... 40
5.1.3 Virtual design analysis ........................................................................... 41
5.2 Automotive sector................................................................................ 45
5.2.1 Car interior ............................................................................................. 45
5.2.2 Motorcycle ............................................................................................. 63
5.2.3 ADAS/IVIS ............................................................................................. 70
5.2.4 ARAS/OBIS ........................................................................................... 80
5.3 Smart living places .............................................................................. 89
5.3.1 Interior Design ....................................................................................... 89
5.3.2 Domotics ............................................................................................... 93
5.4 Workspaces ...................................................................................... 106
5.4.1 Workplace design ................................................................................ 106
5.4.2 Collaborative tools ............................................................................... 112
5.5 Infotainment ...................................................................................... 117
5.5.1 Metaverses .......................................................................................... 117
5.5.2 Collaborative games ............................................................................ 122
5.6 Health Care ....................................................................................... 126
5.6.1 Remote Patient Monitoring .................................................................. 126
5.6.2 Mobile device solution simulation......................................................... 129
5.6.3 Medical education and health coach .................................................... 134
6 Use Cases Prioritisation ........................................................ 140
6.1 VERITAS User Forum and Workshop ............................................... 140
6.2 Methodology ...................................................................................... 141
6.3 Results .............................................................................................. 142
6.3.1 User Forum ......................................................................................... 142
6.3.2 Workshop ............................................................................................ 147
6.3.3 Conclusions ......................................................................................... 152
December 2010 iv CERTH/HIT

7 Application scenarios............................................................. 153

8 Conclusions ........................................................................... 167
9 Reference .............................................................................. 169
ANNEX 1: VERITAS Use Cases Template .................................. 171
ANNEX 2: VERITAS User Forum agenda ................................... 172
ANNEX 3: VERITAS Workshop agenda ...................................... 174
ANNEX 4: VERITAS Use Cases Prioritisation Template ............. 179
List of Charts
Chart 2: Use Cases prioritisation, sum of priority grades. .............................. 143
Chart 3: Use Cases prioritisation, Use Cases with grade 1.......................... 143
Chart 4: Scenarios prioritisation, Use Cases 2.1. ........................................... 144
Chart 10: Scenarios prioritisation, Use Cases 4.2. ......................................... 145
Chart 16: Use Cases prioritisation, sum of priority grades. ............................ 148
Chart 17: Use Cases prioritisation, Use Cases with grade 1........................ 148
December 2010 v CERTH/HIT

List of Figures
Figure 1: Domains within a project where Use Cases can be implemented. ...... 5
Figure 2: A holistic approach for the Use Cases methodology based on the
Domain Model. ................................................................................................... 6
Figure 3: Use Cases Model. ............................................................................... 7
Figure 4: Use Cases hub & spoke scheme. ....................................................... 8
Figure 5: Striped trousers scenarios succeed or fail. ........................................ 11
Figure 6: Interaction steps of the scenario anatomy. ........................................ 13
Figure 7: VERITAS Use Cases extraction methodology. ................................. 16
Figure 8: VERITAS Use Cases overview. ........................................................ 30
Figure 9: Axes of the driving position. .............................................................. 52
Figure 10: Axes of the driving position. ............................................................ 61
Figure 11: Body sensors ................................................................................ 129
Figure 12: Health care coaching application standard use cases. .................. 134
Figure 13: Shot of the 1st Pan-European User Forum of VERITAS. ............... 141
Figure 14: Illustration of the methodology followed for the VERITAS Use Cases
prioritisation. ................................................................................................... 142
Figure 15: Automotive simulation example of driving posture/position. .......... 155
Figure 16: Automotive simulation example of handbrake release, gear changing
and looking at the right mirror. ........................................................................ 156
Figure 17: Automotive simulation example of handbrake release, gear changing
and looking at the right mirror. ........................................................................ 156
Figure 18: Automotive immersive simulation example the driving task. ......... 157
Figure 19: Motorcycle simulation scenarios examples. .................................. 159
Figure 20: Smart living spaces, interior simulation example of entering the
kitchen ............................................................................................................ 161
Figure 21: Smart living spaces, interior simulation example of using the kitchen.
....................................................................................................................... 162
Figure 22: Smart living spaces, interior simulation example of a workplace. .. 162
Figure 23: Smart living spaces interior, immersive simulation example of the
construction. ................................................................................................... 163
Figure 24: Infotainment simulation examples. ................................................ 164
Figure 25: Elderly collaborative games simulation examples. ........................ 165
Figure 26: Healthcare simulation examples.................................................... 166
List of Tables
Table 1: Use Cases fully-dressed template. ..................................................... 10
Table 2: Essential and secondary Use Cases table. ...................................... 168
December 2010 vi CERTH/HIT

List of Abbreviations
Abbreviation Explanation
A Activity
ADAS Advanced Driver Assistance Systems
ARAS Advanced Rider Assistance Systems
CAS Collision Avoidance system
DOM Domain Object Model
EARL Evaluation and Report Language
ICT Information and communication technologies
ID Internal Deliverable
IVIS In-Vehicle Information System
OBIS On-Board Information System
SoA State of the Art
UC Use Cases
UCD User Centred Design
VRDECO VR-based DEsign COordination
WP Work Package
December 2010 vii CERTH/HIT

Executive Summary
The current Deliverable has been issued in the scope of WP1.7 Use Cases
and Application Scenarios and, more specifically, the Activity 1.7.3 on Use
Cases. This Deliverable serves the preliminary outcomes, until Month 12
(December 2010), of the Activity 1.7.3, which are the first version of the project
Use Cases and the Application Scenarios. The final Use Cases and Application
Scenarios though, are going to be released on Month 18 (June 2011), in order
to be used in the pilot planning of the project, both for the developers and the
beneficiaries.
The main content of the current Deliverable is the description of the Use Cases,
which have been derived from the User Needs and requirements that are
illustrated in Deliverable 1.1.1 [24]. The Use Cases are extracted and presented
in such a way, as to cover all the application areas of VERITAS which are
namely, the Automotive domain (WP2.2, WP3.1), the Smart Living Spaces
domain (WP2.3, WP3.2), the Office Workplace domain (WP2.4, WP3.3), the
Infotainment domain (WP2.5, WP3.4) and the Healthcare domain (WP2.6,
WP3.5). The initial Use Cases which are presented herein are accompanied by
the template that has been used by the partners for their detailed description,
which is presented in the Annex 1 of the current document.
Also, within the current Deliverable the Application Scenarios that derive from
the Use Cases are presented (Chapter 8). The application scenarios for each
application domain have emerged as indicative combinations of the Use Cases
and will constitute the basis for the detailed Application Scenarios, to be
included in the updated version of the current Deliverable in Month 18
(D1.7.1.b). The final Application Scenarios will be used for the support of the
evaluation activities of the project. They will be included in Deliverables 3.6.1,
3.7.1 and 3.8.1 of the pilot plans and may also be refined there, in order to fully
fulfil the needs of all the application areas separately, according to the pilot sites
needs and expectations.
Based upon the UCD methodology, the Use Cases have been iteratively and
interactively evaluated by the partners of the project, the users of VERITAS
(developers/designers) and, finally, the beneficiaries. The partners of the
project have updated the Use Cases according to their developments-to-be,
already twice and they are going to update them again, after Month 12, in order
to end up to the final document (D1.7.1.b) of Month 18. For gathering feedback
on the Use Cases by the end users and the beneficiaries of the project, we
organised the 1st Pan-European Workshop and User Forum meeting, in which
the end users and the beneficiaries were introduced to the Use Cases of the
project and prioritised them. The methodology of the prioritisation, as well as the
results, is presented in Chapter 7 of the current Deliverable.
In total we have extracted 24 use cases that fully cover all VERITAS application
domains. They entail 3 use cases for the Generic framework of VERITAS, 8 for
the Automotive sector, 4 for the Smart Living Spaces, 4 for the Workspaces, 2
December 2010 1 CERTH/HIT

for the Infotainment and 3 for the Healthcare domain. All the Use Cases are
presented in detail in Chapter 6 of the current document.

1 Introduction
One of the highest priorities of the European Commission, as well as of the
European Society, during the last years, is the growing disabled and elderly
population, who have diverse and special needs in their everyday lives, that
sometimes do not correspond with the needs of the typical young and healthy
individuals, for which products are designed.
When including in this group also the people with cognitive impairments, as well
as those people who are in the hinterland between fully able bodied and
classically impaired, the percentage of people with disabilities across Europe
reaches 15% [1]. Also, along with the increased life expectancy, the visual and
hearing impairments are increasing. Thus, we should not exclude this
population from the everyday living activities by providing inaccessible design
products, in both ICT and non ICT domains. To this end, it is a technological
challenge to provide senior and disabled citizens with systems and products
that could foster the different facets in their perception of quality of life.
But how easy is it for a typical developer, on the one hand to know and
understand the needs of this population and on the other hand, to implement
the proper accessibility principles in his/her products. Many, if not the most, of
the developers of both ICT and non-ICT products are not fully equipped with the
required knowledge about incorporating accessibility into their products or
services, and even if they are, even fewer of them know how to implement
them.
To this end, VERITAS aims to develop tools for built-in accessibility support at
all stages of ICT and non-ICT product development. The goal is to introduce
simulation-based and virtual reality based all-inclusive models at all stages
of product design and development into the following application domains:
Automotive,
Smart living spaces, (buildings & construction, domotics),
Workplace,
Infotainment and
Healthcare.
Thus, the goal of VERITAS is to ensure that future products and services are
being systematically designed for all people, including those with disabilities
and functional limitations as well as older people. In the current Deliverable the
way the end users interact with the outcomes of VERITAS is initially introduced
in the form of narratives which constitute the projects Use Cases and the
Application Scenarios. In VERITAS we have two groups of users:
1. The end users: developers and designers
2. The beneficiaries: people with disabilities and elderly
The Use Cases of VERITAS have been developed using a thorough and
complete methodology that includes all the activities, which have been realised
in the context of the project, so far. These Use Cases, even though preliminary,

have undergone several refinements by partners and external users and

beneficiaries, in order to be specified and prioritised, as thoroughly as possible.
1.1 The Use Cases concept

1.1.1 Use Cases modelling
Aiming at a better understanding concerning the need and the use of the Use
Cases, as a requirements-gathering tool for VERITAS, a presentation of the
concept and the general idea of the Use Cases approach is introduced in this
chapter.
Use Cases were initially presented by Ivar Jacobson in 1967 as usage

scenarios and became immediately attractive because the term implies "the
ways in which a user uses a system". In the mid-1980s, Jacobson coined the
Swedish term anvendningsfall, which roughly means situation of usage or
usage case, but when publishing into English he translated it in use case [2].
A use case is used as a tool that is being implemented in the system analysis to
identify, clarify, and organize system requirements. A Use Case can be simply
defined as what happens when actors interact with the system. The use case is
made up of a set of possible sequences of interactions between systems and
users in a particular environment and related to a particular goal. By recording
all the ways the system is used (use cases), we accumulate the requirements of
the system. Therefore, a Use Case is a collection of possible sequences of
interactions (scenarios) between the system under research/development and
its users (or actors), relating to a particular goal [2].
The main purpose of the Use Cases is to present, in a detailed and also clear
and easy-to-understand and realise way, the functional requirements of a
system. The Use Cases can also be considered as being a description of a
systems behaviour, written from the point of view of a user who has told the
system to do something specific. In this way, the Use Cases have the unique
ability to help teams to understand the value that the system provides to its
stakeholders [3]. In a more simple approach, Use Cases describe who is doing
what and when, and also what is expected from the system for each request. To
this end, Use Cases comprise a powerful tool to capture functional
requirements for software systems, in order to evaluate them [4].
1.1.1.1 Use Cases and system functional requirements

Functional requirements capture the intended behaviour of the system. This
behaviour may be expressed as services, tasks or functions the system is
required to perform. The systems functional requirements, either basic or
exclusive are the features that characterise the system, making it useful and
usable for the target groups and allow it to penetrate into the market [5].
The Use Cases can be an effective tool for gathering the system requirements,
if they are developed in a disciplined (systematic) and coherent manner, as part
of a methodology that first creates a well defined domain-model (a concept that
will be developed in the next chapter).

Another aspect to consider is, that the Use Cases can be used during many
stages of a system development, being associated with different objectives.
Used at the analysis stage, can prevent the occurrence of costly error correction
at later stages of the development cycle.
1.1.1.2 Use Cases in the problem domain model

The Use Cases may follow the Domain Object Model (DOM), which in problem
solving and software engineering can be thought of as a conceptual model of a
domain of interest (often referred to as a problem domain) which describes the
various entities, their attributes and relationships, plus the constraints that
govern the integrity of the model elements comprising that problem domain.
Despite that, the Use Cases are not explicitly object-oriented, but they are a
broadly applicable requirements analysis tool, which can be applied to non-
object-oriented projects, which increases their usefulness as a requirements
method; they resemble functional decomposition and show aspects of
behaviour [6]. David M. Rubin, identified some of the fields of a projects lifecycle
where Use Cases can be applied and is illustrated in Figure 1.
Figure 1: Domains within a project where Use Cases can be implemented.

Source: [6]
This domain model describes the various entities involved in the system under
research and their relationships. According to Jacobson: A domain model
captures the most important types of objects in the context of the business. [7],
[8]. The domain model represents the things that exist, or the events that
transpire, in the business environment. The domain model can be effectively
used to verify and validate the understanding of the problem domain among
various stakeholders of the project group [9]. The problem-domain describes in
an object-oriented way the part of the real world that concerns the system to be
developed, but without any reference to the system itself. Thus, use cases
capture who (actor) does what (interaction) with the system, for what purpose
(goal), without dealing with system internals [5].
To create a domain-model means, in a sense, to construct a dictionary of words

(a terminology) that will be used to write descriptions of the functions and Use

Cases we wish the system to support. This vocabulary implicitly defines a set of
possible system functions. We should also take into consideration the ambiguity
that some terms can have and try to avoid it.
The domain-model provides an infrastructure for the requirements-gathering

process, so that the development of Use Cases can proceed systematically (in
a way that could never happen without the domain-model). The domain model
is a live, collaborative artefact. It is refined and updated throughout the project,
so that it always reflects the current understanding of the problem space. The
figure below presents the participation and the hierarchy of a use case
approach including the domain model and it has been initially identified by Doug
Rosenberg and Matt Stephens [10].
Figure 2: A holistic approach for the Use Cases methodology based on the Domain
Model.
Source: [10]
Whether the process of developing a Use Case is simple or tricky, its foundation
must always lie in a solid understanding of the problem and a carefully-
constructed description of the problem-domain: a domain-model.
The VERITAS Use Cases model is comprised of two complementary parts: Use
Cases descriptions and Unified Modelling Language (UML) diagrams. Although
the Use Cases are associated with UML diagrams, they have been introduced
long before UML existed. Specifically, Ivac Jackobson has been credited with
inventing use cases which appeared in the object-oriented community in about
1992 [4]. The following pages present different concepts and their interrelations,
as they are essential elements of these two parts of the Use Cases. The
description of the Use Cases is the preliminary step that will conclude to the
design of the UML diagrams, which will be included in the updated version of
the current Deliverable, D1.7.1.b, due in Month 18. In order to construct the
UML diagrams we will await the final version of the Use Cases description. In
the current Deliverable the UMLs of the Use Cases are not included; we will

include the UMLs on the final version of the Use Cases and of this Deliverable
on Month 18.
Figure 3: Use Cases Model.
1.1.1.3 Use Cases Value

Use Cases provide some very clear benefits to the Analysis Phase. In this
chapter we tried to gather and present these advantages of the Use Cases
approach.
One important benefit of the Use Cases driven analysis is, that it helps
managing complexity, since it focuses on one specific usage aspect at a time.
Use cases start from the very simple viewpoint that a system is built first and
foremost for its users [11]. Thus, Use Cases allow capturing the users need by
focusing on a task that the user needs to do. Starting by naming the Use Cases,
value is created since this list of titles-context is the list of goals that announces
what the system will do [12].
Also, the Use Cases help in defining the right functionalities of the system,
meaning they ensure that the correct system is developed by capturing the
requirements from the user's point of view. In addition, the Use Cases help in
finding all the exceptions and alternatives, since the main success scenario is a
sequence of simple steps, going through each step and checking what else the
user could do or what in the system can goes wrong.
Another benefit of Use Cases is that they provide basic groundwork for the pilot
plans, since they are written from the user perspective. Use Cases also
encourage designers to envision outcomes before attempting to specify
outcomes, and thereby they help to make requirements more proactive in
system development [13].
Also, the Use Cases help discovering and gathering requirements for all users
and beneficiaries, and work as a hub that links together different sorts of
information. Use Cases are at the centre of the requirements document; even
for many of the non-functional requirements, as illustrated below (Figure 4).
Data formats are not part of the Use Cases, but the Use Cases name the need
for the data and so we can hyperlink from the Use Cases to the data

descriptions. Complex business rules do not fit well into the Use Cases
narrative, but again we can link to entries containing them. This shows the
cross-linking from Use Cases to other requirements, called the Hub-and-
Spoke model of requirements, which places the use cases at the centre of a
wheel, and by this way the great utility of this tool is easily revealed [2].
Figure 4: Use Cases hub & spoke scheme.

Source: [2]
Finally, by using the Use Cases methodology we can achieve both verification
and validation of the system under development. With the verification, we make
sure that the system has been well structured and developed and with the
validation we ensure that the system corresponds to the Users needs and
expectations.

2 The VERITAS Use Cases methodological

framework
When developing a system or an application within a specific oriented project,
the correlation between the system and the users is a challenging task. This
task is very demanding, especially when the main purpose is to provide a
solution to a problem considering the users environment. Specifically, in
VERITAS, we have to have in mind both the end users (developers and
designers), but also the beneficiaries (elderly and disabled). Even if the Use
Cases will only address the end users (developers, designers), the beneficiaries
(elderly and disabled) and their requirements should be also included, since the
final product will be used by them. Under this framework, each technical detail
of the system must be clearly defined and correlated with the actors that are
involved in it and most of all, there must be a clear and understandable
explanation of the interaction between the user and each technological
component-function.
This chapter provides the theoretical basis, for the reader to understand how
the Use Cases descriptions are extracted, which components they consist of
and what these components mean.
2.1 Use Cases descriptions

Use Cases descriptions are narratives, expressed at the level of the users
intentions and systems responsibilities, rather than concrete actions. According
to Cockburn, to write a UC in an essential type is to keep the user interface out;
focus on intent [20].
Those descriptions require a template to provide a systematic methodology.

Depending on the project objectives, there are different formats or templates to
present the Use Cases descriptions. The fully-dressed format, with which the
Use Cases are described on a long template with fields for various sections,
seems to fit better the complexity of VERITAS objectives. According to
Cockburn, writing requirements for a new system imply writing fully-dressed,
black-box (those that do not discuss the innards of the system) and at the user
goal level Use Cases.
The fully-dressed format is characterized by:

One column of text (not a table).
Numbered steps.
no if statements.
A numbering convention in the extensions sections that involves
combinations of digits and letters (e.g. 2a, 2a1, 2a2, etc.).
A simple and typical fully-dressed template is presented below [20], together

with the elements that are typically included in this kind of UC description
(actors, goals, scenarios, etc.). The VERITAS template is constructed based on
the following format, but it has been enriched and adapted according to the
project objectives and it is presented in Annex 1.

Use-case Title:
Use-case Local ID:
Brief Description:
Scenario:
Actors:
Priority level
System input
System output
Interaction steps
Notes:
Table 1: Use Cases fully-dressed template.
Source: [20]
In the chapters that follow the main fields of the fully dressed template are going
to be described in detail.
2.1.1 Scenarios and Goals

The Use Cases, are goals (use cases and goals are used interchangeably) that
are made up of scenarios. Scenarios consist of a sequence of steps to achieve
the goal; each step in a scenario is a sub goal of the use case. As such, each
sub-goal represents either another use case (subordinate use case) or an
autonomous action that is at the lowest level desired by our use case
decomposition. This hierarchical relationship is needed to properly model the
requirements of a system being developed. In addition, it helps avoid the
explosion of scenarios that would occur if we were to try to simply list all
possible ways of interacting with the system.
The scenarios that comprise a Use Case are detailed explanations of the
followed steps that need to take place, so the scope of the Use Case can be
realised. Additionally, the scenarios of a Use Case allow structuring the system
requirements according to the user goals and provide the means to specify the
interaction between a certain software system and its environment.
The primary actor has a goal; the system should help the primary actor to reach
that goal. Each scenario contains a sequence of steps showing how the actions
and interactions unfold. A Use Case collects all the scenarios together, showing
all the ways that the goal can succeed or fail. A useful metaphor is used by
Alistair Cockburn [14] to illustrate the striped trousers image. The belt of the
trousers is the goal that holds together all the scenarios. The stripes are the
individual scenarios (each stripe characterized by its conditions and result).
Each line in a scenario is a subordinate use case goal or a primitive action. A
subordinate use case appears (often) in two stripes - once for should it succeed
and once for should it fail. The stripes separate into two groups - those that
deliver the goal (the success leg) and those that abandon the goal (the failure
leg). No matter how many scenarios are in the use case, there are these two
legs. In the rare cases of partial delivery, other legs may be added. Thus the
entire use case may be inserted into higher level scenarios in the same fashion
- as a success line and as a failure line (and as a partial success line, if that is a

separate case). In Figure 5 we present the striped trousers form that follows the
aforementioned principles.
Figure 5: Striped trousers scenarios succeed or fail.

Source: [14]
A Use Case is a collection of related success and failure scenarios that

describe actors using the system to support a goal. So, as the image reflects, a
goal holds together all the scenarios (success and failure).
Scenarios and Use Cases go until goal success or abandonment.
Scenario: a sequence of interactions happening under certain conditions,

to achieve the primary actors goal, and having a particular result with
respect to that goal. The interactions start from the triggering action and
continue until the goal is delivered or abandoned, and the system
completes whatever responsibilities it has with respect to the interaction.
Use Case: a collection of possible scenarios between the system under

discussion and external actors, characterized by the goal the primary
actor has towards the systems declared responsibilities, showing how
the primary actors goal might be delivered or might fail.
Scenarios do not just refer to what the system can do, but also refer to those
interactions that the system must be able to identify as invalid (e.g. error
conditions and exceptions).
2.1.2 Other Use Cases Elements

The key elements of the VERITAS Use Cases template (Annex 1) are shortly
described below:
Use Case No
Each use case must have a unique numeric identifier, in hierarchical form: X.Y.
Related use cases are grouped in the hierarchy.
Use Case Title

The name of each Use Case is a concise, results-oriented statement, that gives
the goal of it in one simple and easy to understand phrase. The Use Case name
reflects the tasks the user needs to be able to accomplish using the system.
They include an action verb and a noun.
Brief description (user goal satisfied)

Description in one sentence of the goal of the actor when realising the particular
Use Case.
Application area
o Automotive
o Smart living spaces
o Workspaces
o Infotainment
o Healthcare
Priority level
The priority level indicates the relative priority of implementing the functionality
required to allow this use case to be executed. Thus, how high- or low-level is
the specific Use Cases goal. The priority scheme used is the same as the one
used in the software requirements specification. In VERITAS we used a three
priority level scale:
1: Essential High Priority
2: Secondary Average Priority
3: Supportive Low Priority
Primary Actors, Secondary Actors and Other road participants

Actor is anyone or anything with a behaviour, such as a person (identified by
role), a computer system or an organization- it is an external entity that interacts
with the system to achieve a desired goal, anyone or anything that plays a role
in one or more interactions with the system. Actors should have names that
reflect roles.
A primary actor is a stakeholder who or which initiates an interaction with the

system under research to achieve a goal, or is one having a goal requiring the
assistance of the system. A secondary actor is someone with a vested interest
in the behaviour of the system under discussion, also called stakeholder, are
people who use the program, the company that owns it, government regulatory
agencies, etc. Secondary actors might never interact directly with the system.
Secondary actors participate in the processes and can influence the way the
events flow, or they can even be influenced by the way the events flow.
System input (Trigger)

Trigger is the external event that triggers the system and starts the Use Cases.
A 'Trigger' section describes the event that causes the Use Case to be initiated.

This event can be external, temporal or internal. If the trigger is not a simple
true "event" (e.g., the customer presses a button), but instead "when a set of
conditions are met", there will need to be a triggering process that continually
(or periodically) runs to test whether the "trigger conditions" are met: the
"triggering event" is a signal from the trigger process that the conditions are now
met.
System output
The system output is the actual information, service or action that the actor that
has triggered the system receives. The system output identifies the success of
the use case. Even if all the interaction steps between the system and the
relevant actors are realised correctly the system output is the last think that
signalises the use case end, successfully or not. Post-conditions are
guaranteed to be true when the use case ends. The post-conditions validate
that the basic course and all alternate courses successfully achieved the stated
goal of the Use Case.
Interaction steps
A use case is often triggered by a user-initiated event that the system has to
respond to. However, it can also be triggered by a system-initiated event to
which the user responds. But in both cases, the use case follows the
event/response flow, see Figure 6. Each action of the user is followed by a
reaction of the system and both must be explained in detail in order to unfold a
successful Use Case story.
Figure 6: Interaction steps of the scenario anatomy.
2.2 Personas added value

Personas, as will be developed and used in the VERITAS project, are
hypothetical archetypes of actual users (both developers/designers and
beneficiaries). Although they are imaginary, most of them have been defined
taking into account an existing person with its specific (dis)abilities. The aim of
the personas is to make them approachable for all members of a project-team,
so that developers, designers, managers and other stakeholders can develop
empathy for their beneficiaries. The persona can almost become a real person,

which will facilitate all layers in a project team to keep thinking from the user's
perspective, without being influenced by personal biases.
In the context of VERITAS, a number of representative personas will be

created, while also already existing personas as created by the projects
ACCESSIBLE and AEGIS will be adjusted (customised). The personas are
licensed under a Creative Commons Attribution-Share Alike 3.0 License, thus
allowing extension and enrichment of the already existing personas for the
purposes of VERITAS.
2 personas examples have been included in D1.1.1 UCD-based user

requirements extraction. The main structure of the persona consists of:
Profile
o Name: XXXX
o Age:
o Location:
o Marital status:
o Job:
Meet XXXX
o Current situation:
o Technology usage:
o Wishful situation:
In the course of the project, a whole range of personas will be developed for
both the 5 different application areas, as well as the different beneficiaries
groups (from the 5 main categories, including combined impairments).
According to the application domains and the disability type each persona will
also be linked to specific guidelines and standards which may assist the
developer/designer in the development process.
For each Use Case, a set of relevant personas will be identified. These
personas will be mapped with each Use Case and each scenario, as well as,
with each Application Scenario in the next version on the current Deliverable
(D1.7.1.b) on Month 18.

3 Methodology of VERITAS Use Cases extraction

The main issue with extracting the Use Cases for VERITAS was the
development of an adequate methodology to support it. The adopted
methodology follows the time plan of the project so as to have all the required
elements ready on time to structure the Use Cases. So, the Use Cases are
mainly structured based on the outcomes of the D1.1.1 UCD based user
requirements extraction. According to the UCD approach of VERITAS and after
following a series of field studies, literature surveys, interviews and
questionnaires with beneficiaries and stakeholders, which aimed to capture their
user needs and wishes, the project user needs and requirements were finalised.
Also, apart from WP1.1 that formulated the basis for the Use Cases extraction,
the merging of the outcomes derived from A1.3.1, A1.4.1 and A1.5.1 was very
enlightening and helpful. The SoA on existing models that are to be
incorporated in the field of study of VERITAS was another element in this
procedure. Finally, existing rules and standards and their measurements were
taken into account.
In addition to the abovementioned, the major Application Scenarios have

emerged from the extracted Use Cases and they constitute the basis for the
specific application scenarios that will orient the evaluation activities of the
project (in the context of WP3.6, WP3.7 and WP3.8).
Also, the Use Cases, after the finalisation of their primary format from the
Consortium, were assessed and prioritised by a number of users and experts
during the 1st Pan-European Workshop of the Project. The methodology used
and the results that derived from this effort are presented in Chapter 7 of the
current Deliverable.

VERITAS UCD methodology Understanding the end user groups as

A1.1.4 D1.1.1 (M6), D1.1.2 well as their needs & requirements.
(M12), D1.1.3 (M20)
(A1.1.1, A1.1.2)
Iterative & Interactive development

Outcomes of the user needs
A1.1.1 D1.1.1 (M6)
VERITAS
Use Cases
M12, update M18
Outcomes of the benchmarking of
the existing models. VERITAS VERITAS
A1.1.2 105 models , more than Conceptual Application
250 references, D1.1.1 (M6)
Models Scenarios
Outcomes of the industrial D1.7.1a: Use Cases and application scenarios (M12)
needs per sector.
A1.1.3 100 questionnaires,
20 interviews, D1.1.1(M6)
Iterative evaluation by end users in pilot sites (A4.3.2)
(M10)
Virtual user models
WP 1.3, WP1.4, WP1.5,
WP1.6 D1.6.1 D1.7.1b: Use Cases and application scenarios (M18)
Figure 7: VERITAS Use Cases extraction methodology.

Considering Figure 7, VERITAS Use Cases were realised through the steps that
follow:
1st STEP: Define a UC Model (capable of supporting the variety of situations

that VERITAS will support). The model is comprised of:
Template for the UC descriptions (based on the fully-dressed format), in
which the elements that are necessary (according to VERITAS objectives)
should be inserted gradually. The template starts just with the essential (use
cases names, context, and primary actor) and has the possibility of attaching
other sections later and to be changed whenever necessary. In this step, the
important aim is to keep UCs very simple, in order to produce a UCs Index.
Diagrams accomplishing each of the UCs textual descriptions (on the
template). Diagrams are designed with the same capabilities of the template,
i.e., providing the possibility of attaching details later.
2nd STEP: Define the Use Cases Index (comprised of a set of UC names). This
step is achieved before the previous one, even if it comes second at the
methodology. It corresponds to the Use Cases Index (comprised of a set of UC
names) and it is the first level of detail to start writing Use Cases. The reason
why this step comes second, is the need to have a model before (from 1st step).
The model is supported by the methodology presented before and was

developed, increasing gradually its complexity. It is more effective to keep it
very simple in the starting phases and add details later.
Finally, there was a reflection on some criteria for guaranteeing the quality of
the VERITAS Use Cases, which are:
1. Containing all elements: such as UCs aim/scope, the trigger for the UC,
the primary actor and possibly other stakeholders, all the interests of the
stakeholders, preconditions, success and failure conditions.
2. The UC should contain a template with the necessary elements and
diagrams, as well as the UC textual descriptions.
3. The UC should be related to the Activity structure, as defined in the
A1.x.1 matrices.
4. The UC should clearly show under what conditions the VERITAS
functionalities are successful in relation to the problem/goal of the
primary user.
5. The UC should clearly show what the minimal functionalities should be in
relation to the problem/goal of the primary user for successful results.
The structure of the used methodological framework has been used

successfully in many EU projects, such as, ASK-IT IP, OASIS IP and AEGIS IP.

3.1 Correlation with the User Requirements

The thorough research of WP1.1 led to the construction of a consolidated table
of the user requirement that is in detail described in D1.1.1 [24].The user needs
and requirements are separated in a generic category that includes generic
wishes of the users and subareas for the different application domains. The
structure of the user needs and requirements is the following:
Automotive
Requirement on the tools.
Requirement on application development.
Requirement on accessibility requirements.
Smart living
Office workplace
Infotainment
E-Health
The mapping of the user needs and requirements with the VERITAS use cases
is illustrated in the following table.
User Requirement Use Case

1. Have a tool with advanced features, This is not a feature of VERITAS,
applications and commands, since I am an but of the underlying model. It will be
experienced user who works in the supported by VERITAS, if the
engineering field. application in which VERITAS is
running supports it.


2. Have a tool with at least two levels of This is not a feature of VERITAS,
functions: but of the underlying model. It will be
a. basic functions accessible by supported by VERITAS, if the
anyone, application in which VERITAS is
b. advanced functions for running supports it.
engineers or more skilled users.
3. Have a tool with the possibility to switch This is not a feature of VERITAS,
among several types of visualization (i.e. but of the underlying model. It will be
designer view, programmer view). supported by VERITAS, if the
application in which VERITAS is
4. Have a tool with the possibility to have This is not a feature of VERITAS,
resizable instrument boxes or windows. but of the underlying model. It will be
supported by VERITAS, if the
application in which VERITAS is
5. Have a tool that will allow me to design and This is not a feature of VERITAS,
test every domain application, in order to but of the underlying model. It will be
be effectively adopted during the design supported by VERITAS, if the
process. application in which VERITAS is
6. Have a tool that will allow me to create This is not a feature of VERITAS,
macros and commands. In this way expert but of the underlying model. It will be
users may set macros for testing using supported by VERITAS, if the
directly the code, in order to allow less application in which VERITAS is
expert users to conduct the test using user running supports it.
friendly ad hoc commands.
7. Have a tool able to generate code by This is not a feature of VERITAS,
creating or moving graphical objects: so but of the underlying model. It will be
designers will use graphical interface for supported by VERITAS, if the
prototyping and developers will switch to application in which VERITAS is
code view to test the application. running supports it.
8. Have a tool that will allow me to involve the This is reflected in the main scope of
users (beneficiaries) in the development VERITAS. All Use Cases present
process at given stages. how the users can include
beneficiaries at all design stages.
Specifically see UC 1.2.
9. Have a tool that will allow me to involve the This is reflected in the main scope of
elderly and disabled (beneficiaries) in the VERITAS. All Use Cases present
design process at given stages. how the users can include
10. Have a tool that will provide me with All the User model profiles and
suggestions on possible guidelines, consequently the personas, which
standards or regulations on how to solve the users select in order to make an
accessibility issues, with the possibility to accessible design, are connected to
disable them. specific guidelines, standards or
regulations, according to the
disability type and the application
domain the user is making the
design for.


11. Have a tool that would allow me to learn All the User model profiles and
more about usability and accessibility consequently the personas, which
guidelines, standards and problems, since the users select in order to make an
designers and developers are hardly aware accessible design, are connected to
of accessibility problems and existing specific guidelines, standards or
solutions. Short guides, glossaries, regulations, according to the
introductions might be helpful tools to be disability type and the application
included, as well as domain-specific use domain the user is making the
cases databases. design for.
12. Have a tool that will automatically This is not a feature of VERITAS. It
download the updates of accessibility will be supported by VERITAS, if the
guidelines, ISO or other recommendations. application in which VERITAS is
13. Have a tool that will have the ability to This requirement can be fulfilled only
create applications according to certain by the UCs of Category 5
standards, (there must be the possibility to (infotainment). This is generally
switch between a WAI or a WCAG check, fulfilled by connecting the
depending on the application you want to accessibility design with specific
develop. Also in the initial choice of the personas that are tailored to specific
application template, there must be an guidelines and standards will provide
extra menu that allows you to choose the the user with this feature.
standard by which you want to check your
code.
14. Have a tool that will indicate when and why This is reflected to the main scope of
it would be better to involve disabled and VERITAS. All Use Cases present
elderly people in some phases of design how the users can include
process. beneficiaries at all design stages.
15. Have a web based tool. This is not a feature of VERITAS,
but of the underlying tool. VERITAS
will be web based, if the application
in which VERITAS is running is a
web based tool.
16. Have a tool that will indicate in each stage This is reflected in the main scope of
of the design which accessibility VERITAS. All Use Cases present
requirements have to be considered, and how the developers can include
how this can be achieved. beneficiaries at all design stages.
17. Have a tool to support me in including the This is reflected to the main scope of
beneficiaries in the testing phase of the VERITAS. All Use Cases present
development. how the users can include
18. Have a tool that will assist me in the Since VERITAS is running upon
accessible design without being time applications already used by the
consuming than traditional design tools. user, he/she will not need extra
effort or time when using it. In the
contrary, using VERITAS will allow
user not to intermediately test with
beneficiaries early prototypes, fact
that will save them time and effort.
This is reflected in all the Use
Cases.


19. Have a tool that will be seamlessly Since VERITAS is running upon
integrated in the current tool I use and the applications already used by the
design process I follow, with no or little developer, he/she will not need extra
(extra) learning effort. effort or time when using it. This is
reflected in all the Use Cases.
20. Have a tool with clear advantages in using Since VERITAS is running upon
them during the design processes. applications already used by the
user, he/she will not need extra
effort or time when using it. In the
contrary, using VERITAS will allow
user not to intermediately test with
beneficiaries early prototypes, fact
that will save them time and effort.
This is reflected in all the Use
Cases.
21. Have a tool that will allow me to import files This is not a feature of VERITAS. It
from other frameworks, such as Adobe files will be supported by VERITAS, if the
(psd, ai, etc..), CAD files (dwg, dxf, etc..), application in which VERITAS is
Vision Studio files (vcproj, sln, etc..). running supports it. Specifically see
UC 1.3 and UC 1.4.
22. Have a tool that will allow me to select the This is not a feature of VERITAS. It
language to make the application, choosing will be supported by VERITAS, if the
from the most used (Java, C / C + + / C #, application in which VERITAS is
PHP, Javascript). Other languages can be running supports it.
supported.
Automotive:
Tools
1. Have a tool that would cooperate with VERITAS can be embedded in all
the most common used design simulation tools. At the moment we
application in the automotive domain: have tailored it to RAMSIS; see UC
RAMSIS 1.1 and all Category 2 UCs.
Matlab/Simulink
CATIA
SolidWorks
Requirement on application development
1. Have a tool tailored around the most The automotive domain Use Cases,
frequently developed applications in the Category 2, reflect all these sub-
automotive domain, like car interior, domains. Specifically, UCs 2.1.a/b
ADAS, IVIS, Multimedia, Passive and cover the car interior domain and the
Active safety, primary vehicle control. primary vehicle control and UCs
2.3.a/b cover the ADAS, IVIS,
Multimedia, Passive and Active
safety.
2. Have a tool that could suggest controls Each Use Case of Category 2 refers
for relevant domain categories. For the to one or multiple groups of
automotive domain, in particular, beneficiaries. Specifically:
designer and developers would expect Elderly people are addressed
to find control suggestion on these in UCs 2.1.a/b, 2.2.a/b,
categories: Elderly people independent 2.4.a/b.
(living at home), people with motor People with motor
impairments, people with low vision impairments are addressed
impairment. in UCs 2.1.a/b, 2.2.a/b.


People with low vision
impairment are addressed in
UCs 2.3.a/b, 2.4.a/b.
Accessibility requirements
1. Have a tool that includes an up to date All the User model profiles and
library with accessibility guidelines and consequently the personas, which
standards. the developers select in order to
make an accessible design, are
connected to specific guidelines,
standards or regulations according
to the disability type and the
application domain he/she is making
the design for.
2. Have a tool with functionalities that All the User model profiles and
enable the me to check whether the consequently the personas, which
application is consistent with the the developers select in order to
accessibility guidelines and standards: make an accessible design, are
ADAAG for Transportation Vehicles connected to specific guidelines,
USAB Electronic and Information standards or regulations according
Technology to the disability type and the
Accessibility Standards application domain he/she is making
the design for.
USAB for Public Rights-of-Way
3. Have a tool with outputs related to All the User model profiles and
specific guidelines, with a particular consequently the personas, which
focus on mobility and accessibility the developers select in order to
guidelines/standard. make an accessible design, are
the design for.
4. Have a tool that will provide me All the User model profiles and
suggestions, guidelines and possibly consequently the personas, which
templates of experimental designs for the developers select in order to
testing the application being developed make an accessible design, are
with elderly / disabled end users. connected to specific guidelines,
Suggestions and success criteria will be standards or regulations according
related to the disabilities being to the disability type and the
addressed in the specific domain, i.e. application domain he/she is making
Elderly people independent (living at the design for. Additionally, in all
home), people with motor impairments, UCs the outcome is an EARL report,
people with low vision impairment. that presents in detail the results of
the simulation performed.
Smart living spaces
Tools
the most used to design application in simulation tools. At the moment we
Smart living domain: have tailored it to VRfx, ISE and
VRfx AutoCAD; see UC 1.1 and all Category
Solid Edge 3 UCs.
AutoCAD


SketchUp Pro
ISE

2. Have a tool tailored around the most The Smart living spaces domain Use
frequently developed applications in the Cases, Category 3, reflect all these
smart living domain, like interiors, sub-domains. Specifically, UCs
residential buildings, furniture and 3.1.a/b cover the interiors of
facilities, domotic applications. buildings, the furniture and facilities
and UCs 3.2.a/b cover the domotic
applications.
3. Have a tool that would suggest controls Each Use Case of Category 3 refers
smart living domain, in particular, beneficiaries. Specifically:
to find control suggestion on these in UCs 3.2.a/b.
categories: Elderly people independent People with motor
(living at home), people with motor impairments are addressed
impairments, people blind and with low in UCs 3.1.a/b, 3.2.a/b.
vision impairment. People with low vision
impairment are addressed in
UCs 3.2.a/b.
focus on mobility and accessibility the developers select in order to
guidelines/standard. make an accessible design, are
the design for.
ADAAG for Buildings and Facilities connected to specific guidelines,
ADAAG for Building Elements standards or regulations according
Designed for Childrens Use to the disability type and the
USAB Electronic and Information application domain he/she is making
Technology Accessibility Standards the design for.
USAB Telecommunications Act
Accessibility Guidelines
ABA Accessibility Guidelines
focus on devices, buildings accessibility, the developers select in order to
accessibility of living spaces and make an accessible design, are
accessibility standards and connected to specific guidelines,
methodologies. standards or regulations according


the design for.
4. Have a tool that would provide All the User model profiles and
people with low vision impairment. that presents in detail the results of
Office workplace
Tools
office workplace domain: have tailored it to AutoCAD and
a. For the interior design: VRDECO for the interior design
AutoCAD simulation and LOTUS DOMINO for
Autostudio the collaborative tools simulation;
Infowood see UC 1.1 and all Category 4 UCs.
3D Spacer Office Edition
b. For the collaborative tools
VRDECO
LOTUS DOMINO
1. Have a tool tailored around the most The Office workplace domain Use
frequently developed applications in the Cases, Category 4, reflect all these
office workplace domain. The user must sub-domains. Specifically, UCs
be given the chance to select among a 4.1.a/b cover the workspace interior
list of application categories: Workspace design and general layout, the
interior design, general layout and furniture and facilities and UCs
services, signage and information 4.2.a/b cover the services, signage
systems. and information systems.
office workplace domain, in particular, beneficiaries. Specifically:
to find control suggestion on these in UCs 4.2.a/b.
categories: Elderly people dependent People with motor
and independent, people with motor impairments are addressed
impairments, people with low vision in UCs 4.1.a/b.
impairment, people with hearing People with low vision
impairments and people with cognitive impairment are addressed in
impairments. UCs 4.1.a/b.
People with hearing
impairments UCs 4.2.a/b.
People with cognitive
impairments UCs 4.2.a/b.


specific guidelines, including respected consequently the personas, which
libraries. the developers select in order to
make an accessible design, are
the design for.
enable me to check whether the consequently the personas, which
USAB Electronic and Information standards or regulations according
Technology Accessibility Standards to the disability type and the
USAB Telecommunications Act application domain he/she is making
Accessibility Guidelines the design for.
ABA Accessibility Guideline
ADAAG for Buildings and Facilities.
focus on Web accessibility, Buildings the developers select in order to
accessibility, Workstation accessibility make an accessible design, are
and accessibility of living spaces. connected to specific guidelines,
the design for.
people with low vision impairment that presents in detail the results of
Infotainment
1. Have a tool tailored around the most VERITAS can be embedded in all
frequently developed applications in the simulation tools. At the moment it
infotainment domain. The user must be has been tailored to Second Life;
given the chance to select among a list see UC 1.1 and all Category 5 UCs.
of application categories: Applications
for 3D games and social network and
other applications.


infotainment domain, in particular, beneficiaries. Specifically:
to find control suggestion on these in UCs 5.2.
categories: Elderly people dependent People with motor
and independent, people with motor impairments are addressed
impairments, people with low vision in UCs 4.1.a/b.
impairments and people with cognitive impairment are addressed in
impairments. UCs 5.1.
People with hearing
impairments UCs 5.1.
ADAAG for Building Elements connected to specific guidelines,
Designed for Children's Use standards or regulations according
IGDA Accessibility White Paper to the disability type and the
USAB Electronic and Information application domain he/she is making
Technology Accessibility Standards the design for.
USAB Telecommunications Act
Accessibility Guidelines
WAI-ARIA Rich Applications
Web Content Accessibility
Guidelines 1.0 (WCAG 1.0)
Web Content Accessibility
Guidelines 2.0 (WCAG 2.0)
Section 508
Authoring Tool Accessibility
Guidelines (ATAG)
focus on web accessibility and the developers select in order to
accessibility standards and make an accessible design, are
methodologies. connected to specific guidelines,
the design for.


people with low vision impairment that presents in detail the results of
Healthcare
Tools
healthcare domain: have tailored it to DGHome
Adobe suite application; see UC 1.1 and all
DGHome application Category 6 UCs.
3ds Max
1. The tool should be tailored around the The Healthcare domain Use Cases,
most frequently developed applications Category 6, reflect all these sub-
in the e-health domain. The user must domains. Specifically, UCs 6.1 cover
be given the chance to select among a the E-health interfaces for patient
list of application categories: Fixed E- monitoring, UCs 6.2 cover the
health interfaces for patient monitoring, mobile e-health devices for personal
mobile e-health devices for personal care and UCs 6.3 cover the
care and education and motivation education and motivation
applications. applications.
e-health domain, in particular, designer beneficiaries. Specifically:
and developers would expect to find Elderly people are addressed
control suggestion on these categories: in UCs 6.1. 6.2, 6.3.
Elderly people dependent and People with motor
independent, people with motor impairments are addressed
impairments, people with low vision in UCs 6.1, 6.2, 6.3.
impairments, people with cognitive impairment are addressed in
impairments and people with speech UCs 6.1, 6.2, 6.3.
impairments. People with hearing
impairments UCs 6.1, 6.2,
6.3.
People with speech
enable the designer/developer checking consequently the personas, which
whether the application is consistent the developers select in order to
with those guidelines: make an accessible design, are
ABA Accessibility Guidelines standards or regulations according
AAMI HE48:1993, Human factors to the disability type and the
engineering guidelines and preferred application domain he/she is making
practices for the design of medical the design for.
devices


ANSI/AAMI HE75:2009, Human
factors engineering Design of
medical devices
IEC 60601-1-2 - Ed. 3.0 - Medical
electrical equipment.
focus on Accessibility of e-health the developers select in order to
devices and services and accessibility make an accessible design, are
standards and Tools connected to specific guidelines,
the design for.
3. Have a tool that would cooperate with All the User model profiles and
the most used to design application consequently the personas, which
being developed with elderly / disabled the developers select in order to
end users. Suggestions and success make an accessible design, are
criteria will be related to the disabilities connected to specific guidelines,
being addressed in the specific domain, standards or regulations according
i.e. Elderly people independent (living at to the disability type and the
home), people with motor impairments, application domain he/she is making
people with low vision impairment would the design for. Additionally, in all
cooperate with the most used to design UCs the outcome is an EARL report,
application in automotive domain: that presents in detail the results of

4 Use Cases list

On the basis of the aforementioned methodological framework the Use Cases
of VERITAS were extracted and the extended list is presented below. It is
important to highlight that in VERITAS, the users are the developers and
designers of the various application domains of the project, and the
beneficiaries are the elderly and disabled users.
Category 1: Use Framework

UC 1.1: External applications interface.
UC 1.2: Generation of virtual test sample
UC 1.3: Virtual design analysis for desktop simulation
UC 1.4: Virtual design analysis for immersive simulation
Category 2.a: Automotive Category 2.b: Automotive
desktop simulation. immersive simulation
UC 2.1.a: Car interior accessibility UC 2.1.b: Car interior immersive
desktop simulation. simulation.
UC 2.2.a: Motorcycle handling UC 2.2.b: Motorcycle handling
accessibility desktop simulation. immersive simulation.
UC 2.3.a: ADAS/IVIS functionalities UC 2.3.b: ADAS/IVIS functionalities
desktop simulation. immersive simulation.
UC 2.4.a: ARAS/OBIS functionalities UC 2.4.b: ARAS/OBIS functionalities
Category 3.a: Smart living Category 3.b: Smart living
places design places simulation
UC 3.1.a: Interior Design desktop UC 3.1.b: Interior Design immersive
simulation. simulation.
UC 3.2.b: Domotics immersive
UC 3.2.a: Domotics desktop simulation.
simulation.
Category 4.a: Workspaces Category 4.a: Workspaces
UC 4.1.a: Workplace design accessibility
desktop simulation. UC 4.1.b: Workplace design
UC 4.2.a: Collaborative tools immersive simulation.
accessibility desktop simulation.
Category 5: Infotainment
UC 5.1: Accessible metaverses simulation.
UC 5.2: Collaborative games for older people simulation.
Category 6: Health Care
UC 6.1: Remote Patient Monitoring solutions simulation.
UC 6.2: Mobile device for older users interaction with Personal Health solutions
simulation.
UC 6.3: Medical education and health coach application design simulation.
An overview of the VERITAS Use Cases is presented in the following figure.


Category 1: Use Framework UC 2.1.a: Car interior accessibility UC 2.1.b: Car interior immersive
UC 1.1: Generation of virtual test sample desktop simulation. simulation.
UC 1.2: Virtual design analysis for desktop simulation UC 2.2.a: Motorcycle handling UC 2.2.b: Motorcycle handling
UC 1.3: Virtual design analysis for immersive simulation accessibility desktop simulation. immersive simulation.
UC 2.4.a: ARAS/OBIS functionalities UC 2.4.b: ARAS/OBIS functionalities

UC 6.1: Remote Patient Monitoring
Category 3.b: Smart
Category 3.a: Smart
solutions simulation. living places
living places design
simulation
UC 6.2: Mobile device for older users UC 3.1.a: Interior Design UC 3.1.b: Interior Design
interaction with Personal Health desktop simulation. immersive simulation.
solutions simulation. UC 3.2.a: Domotics desktop UC 3.2.b: Domotics
simulation. immersive simulation.
UC 6.3 Medical education and health
coach application design simulation.
Category 4.a: Workspaces Category 4.a: Workspaces

UC 5.1: Accessible metaverses simulation. UC 4.1.a: Workplace design
UC 5.2: Collaborative games for older people accessibility desktop simulation.
UC 4.1.b: Workplace design
simulation. immersive simulation.
UC 4.2.a: Collaborative tools
Figure 8: VERITAS Use Cases overview.

5 Use Cases description

In this Chapter the descriptions of all the Use Cases are analytically presented
in the form of the template illustrated in Annex 1.
5.1 Use Framework

Category 1: Use Framework
UC 1.1: Interface with external applications.
Scenario 1.1.1: Interface for the automotive
domain with RAMSIS.
Scenario 1.1.2: Interface for the smart living
places domain with VRfx.
Scenario 1.1.3: Interface for the domotic
applications domain with ISE.
Scenario 1.1.4: Interface for the workplaces
domain with AutoCAD application.
Scenario 1.1.5: Interface for collaborative tools.
Scenario 1.1.5.1: Interface with LOTUS
DOMINO
Scenario 1.1.5.2: Interface with
VRDECO.
Scenario 1.1.6: Interface for infotainment with
SecondLife.
Scenario 1.1.7: Interface for collaborative games
for elderly with ICToys.
Scenario 1.1.8: Interface for healthcare domain
with DGHome.
UC 1.2: Generation of virtual test sample.
Scenario 1.2.1: Definition of physical
dimensions.
Scenario 1.2.2: Definition of impairments.
UC 1.3: Virtual design analysis for desktop simulation.
Scenario 1.3.1: Assessment of design variant.
Scenario 1.3.2: Identification of optimal design
variant.
UC 1.4: Virtual design analysis for immersive
simulation.
Scenario 1.4.1: Assessment of design variant.
Scenario 1.4.2: Identification of optimal design
variant.

5.1.1 Interface with external applications

Use Case 1.1
No
Use Case Interface with external applications
Title
Brief The user uses an application (RAMSIS, VRfx, ISE, CAD, VRDECO,
description LOTUS DOMINO, SecondLife, ICToys and DGHome) enhanced with
(user goal VERITAS simulation functionality, in order to prepare an accessible
satisfied) design.
Application Smart Personal
area Living HealthCare Infotainment Automotive Workplace
Spaces
Relevant WP ALL SP2 and SP3
Scenario Scenario 1.1.1: Interface for the automotive domain with RAMSIS.
Scenario 1.1.2: Interface for the smart living places domain with VRfx.
Scenario 1.1.3: Interface for the domotic applications domain with ISE.
Scenario 1.1.4: Interface for the workplaces domain with AutoCAD
application.
Scenario 1.1.5: Interface for collaborative tools
Scenario 1.1.5.1: Interface with LOTUS DOMINO.
Scenario 1.1.5.2: Interface with VRDECO.
Scenario 1.1.6: Interface for infotainment with Second Life.
Scenario 1.1.7: Interface for collaborative games for elderly with
ICToys.
Scenario 1.1.8: Interface for healthcare domain with DGHome platform.
Primary Designer/Developer
Actor(s)
Priority level Essential Secondary Supportive
System Scenario 1.1.1: Interface for the automotive domain with RAMSIS.
input VERITAS user model file.
VERITAS Simulation model file for Automotive.
Task file.
CAD file of environment.
Scenario 1.1.2: Interface for the smart living places domain with VRfx.
VERITAS user model file.
VERITAS Simulation models for Smart Living Spaces.
Task file.
Smart Living Spaces design data:
o 3D model data for smart residential building or
apartment.
o Library of smart devices.
o Smart device network devised in design.
o Other relevant data to set up simulation.
Scenario 1.1.3: Interface for the domotic applications domain with ISE.
VERITAS Simulation models for the Domotic Application
Domain.

Task file
ISE file of environment.
3D model data of the domotic environment, .e.g.
apartment.
Library of domotic devices.
Network of domotic devices.
Configuration of domotic devices.
Other relevant data to set up the simulation
Scenario 1.1.4: Interface for the workplaces domain with CAD

application
VERITAS Simulation models for Workplaces.
Task file.
o 3D model data for interior Workplace design.
o Library of accessible building elements.
o Accessible Workplace design.

Scenario 1.1.5.1: Interface with LOTUS DOMINO
VERITAS Simulation models for collaborative tools.
Collaborative tools design data:
o 3D model data for collaborative tools design.
o Library of accessible and assistive interface elements.
Scenario 1.1.5.2: Interface with VRDECO
VERITAS Simulation model file for Workplaces.
Task file.
Scenario 1.1.6: Interface for infotainment with SecondLife.

VERITAS Simulation model file for SecondLife.
Task file.
A number of 2D/3D user interface screens.

ICToys.
VERITAS Environment simulation models for Infotaiment.
The library design follows accurately for the games.
The functional specifications of the game. (The game structure
created for collaborative games)

VERITAS Simulation models for Healthcare Service.
Task file.
Healthcare service data
o Service model.

o Patient model (Vital Statistic, Health Record, Interaction

modality skills).
System Scenario 1.1.1:Interface for the automotive domain with RAMSIS
output A simulated automotive environment ready to realise an
accessible design.
Scenario 1.1.2: Interface for the smart living places domain with VRfx
A simulated smart living places environment ready to realise an
accessible design.
Scenario 1.1.3: Interface for the domotic applications domain with ISE
A simulated domotic applications environment ready to realise
an accessible design.

applications
A simulated workplaces environment ready to realise an
accessible design.

A simulated collaborative tools environment ready to realise an
accessible design.
Scenario 1.1.5.2: Interface with VRDECO
A simulated workplaces environment ready to realise an
accessible design.
Scenario 1.1.6: Interface for infotainment with SecondLife

A simulated infotainment environment ready to realise an
accessible design.

ICToys
A simulated collaborative games environment ready to realise
an accessible design.

A simulated healthcare environment ready to realise an
accessible design.
Interaction Scenario 1.1.1:Interface for the automotive domain with RAMSIS

steps Scenario 1.1.1.a: Desktop simulation.
Step 1 The user runs RAMSIS software.
Step 2 The system presents a blank simulation
environment.
Step 3 The user activates the VERITAS add-on in
RAMSIS.
Step 4 User loads a CAD file of environment.
Step 5 The user loads a VERITAS user model file.
Step 6 The user loads a Task file.
Step 7 The user loads a VERITAS Simulation model
file for Automotive.
Step 8 The system initializes the simulation engine

and displays a simulated environment as defined by the

simulation model, i.e. the virtual objects, an avatar, and
meta information.
Step 9 The system is ready for an accessible design
simulation.
Scenario 1.1.1.b: Immersive simulation
Step 1 The user runs RAMSIS software.
Step 2 The system presents a blank simulation
environment.
RAMSIS.
Step 4 User loads a CAD file of environment.
Step 7 The user loads a VERITAS Simulation model
file for Automotive.
and displays a simulated environment as defined by the
simulation model, i.e. the virtual objects, an avatar, and
meta information.
Step 9 The user connects to the smart devices library
and simulation service.
Step 10 The system acknowledges the successful
connection and displays the available devices.
Step 11 The user loads a smart device network,
prepared with the network editor.
Step 12 The system validates the network against the
library and provides positive feedback on success.
Step 13 The user connects logical devices defined in
the network with vision objects defined in the simulation
model.
Step 14 The system adjusts the vision output
according to the state of the respective devices.
Step 15 The user performs a basic functional
verification of the loaded immersive simulation
simulation.
Scenario 1.1.2: Interface for the smart living places domain with VRfx
Scenario 1.1.2.a: Desktop simulation.
Step 1 The user runs VRfx software.
Step 2 The immersive environment appears
although still blank because it is not defined yet.
VRfx.
Step 4 User loads a VRfx file of environment.
Step 7 The user loads an appropriate simulation
model (as defined in WP2.3/3.2).
and displays a simulated environment as defined in the
simulation models, i.e. the virtual objects, an avatar, and
meta information on how to proceed.

simulation.
Scenario 1.1.2.b: Immersive simulation.
Step 1 The user runs VRfx software.
VRfx.
Step 4 User loads a VRfx file of environment.
simulation models, i.e. the virtual objects, an avatar, and
model.
verification of the loaded immersive simulation.
Step 16 The system is ready for accessible design
simulation.
Scenario 1.1.3: Interface for the domotic applications domain with ISE
Scenario 1.1.3.a: Desktop simulation.
Step 1 The user runs ISE software.
Step 3 The user activates the VERITAS add-on in ISE.
Step 4 The user loads a proper environment file for
ISE.
Step 5 The add-on prompts for a simulation model.
simulation models, i.e. the room, domotic devices, and
simulation.
Scenario 1.1.3.b: Immersive simulation.
Step 1 The user runs ISE software.

Step 3 The user activates the VERITAS add-on in ISE.

Step 4 The user loads a proper environment file for
ISE.
simulation models, i.e. the room, domotic devices, and
model.
simulation.

application
Scenario 1.1.4.1: Desktop simulation.
Step 1 The user runs the CAD package (i.e.
AUTOCAD).
Step 2 The immersive environment appears.
Step 3 The user activates the VERITAS add-on.
Step 4 The user loads a CAD file.
Step 6 User loads Task file.
and displays an immersive environment as defined in
the simulation models, i.e. the virtual objects, an avatar,
and meta information on how to proceed.
Step 9 The user connects to the workplace elements
library and simulation service.
simulation.
Scenario 1.1.4.2: Immersive simulation.
Step 1 The user runs the CAD package (i.e.
AUTOCAD).
Step 3 The user activates the VERITAS add-on.
Step 4 The user loads a CAD file.


Step 9 The user connects to the workplace elements
Step 10 The user loads a collaborative tool design,
already prepared.
Step 11 The system validates the collaborative tool
design against the library and provides positive
feedback on success.
simulation.

Step 1 The user runs the LOTUS DOMINO.
LOTUS DOMINO.
Step 4 The user loads a LOTUS DOMINO file.
Step 8 The user connects to the interface elements
connection and displays the available elements.
Step 10 The user loads a collaborative tool design,
already prepared.
Step 11 The system validates the collaborative tool
design against the library and provides positive
feedback on success.
simulation.
Scenario 1.1.5.2: Interface with VRDECO applications.
Step 1 The user runs the VRDECO package.
VRDECO.
Step 4 The user loads a LOTUS DOMINO file.
Step 5 User loads VERITAS user model file.
Step 7 The user loads a 3D model of the office

environment using the ModelAdaptor interface.

Step 8 The system is ready for accessible design
simulation.
Scenario 1.1.6: Interface for infotainment with Second Life

Step 1 The user runs SecondLife software.
Step 2 The user loads SecondLife user model file
Step 3 The user activates the VERITAS add-on in Second
Life.
Step 4 The user loads a number of 2D screens of the
metaverse application to the ModelAdaptor interface.
Step 5 The user creates interaction tasks with specific 2D
interface elements using the ModelAdaptor interface.
Step 6 The user creates developer assigns interaction tasks
with specific 2D interface elements for the Avatar Appearance
screen using the ModelAdaptor interface.
Step 7 The user loads an appropriate simulation model.
simulation.

ICToys
Step 1 The user runs the game based on ICT.
Step 3 The user activates the VERITAS add-on in ICToys.
Step 4 The user loads a ICToys file.
Step 5 User loads VERITAS user model file.
Step 7 The user loads an appropriate simulation model (as
defined in WP2.4/3.3).
Step 8 The system initializes the simulation engine and
displays an immersive environment as defined in the simulation
models, i.e. the virtual objects, an avatar, and meta information
on how to proceed.
Scenario 1.1.8: Interface for healthcare domain with DGHome

Step 1 The user runs DGH software.
Step 2 The blank desktop simulator appears.
Step 3 The user activates the VERITAS add-on in DGH
Step 4 The user loads a DGH file.
Step 5 The user loads an appropriate user model file.
Step 7 The user loads a simulation model file.
Step 8 The system initializes the simulation engine and
displays a desktop simulation.
simulation.
Connected ALL
UCs
Background Correctly setting up the technical infrastructure and the virtual
info/ reason simulation environment is the basis for performing accessibility
on selection assessments.
and on

assigning
the priority
level
References See WP2.1, WP2.2, WP2.3, and WP3.2 descriptions as well as D2.3.1,
D.2.3.2, and D3.2.1.
5.1.2 Generation of virtual test sample

Use Case 1.2
No
Use Case Generation of virtual test sample
Title
Brief The accessibility of a product design is analysed based on the virtual
description simulation of the user interaction with the design. The simulation
(user goal makes use of virtual user models to represent the user in the virtual
satisfied) environment. Taking the design specifics into account, the user defines
a set of virtual user models (virtual test sample), which will be used for
the later design analysis. In particular the user can specify parameters
related to the physical dimensions of the beneficiary, as well as,
parameters related to physical, cognitive, behavioural, psychological
(dis)abilities.
Spaces
Relevant WP 1.3-1.5, 2.3-2.6, 3.1-3.5
Scenario Scenario 1.2.1: Definition of physical dimensions

The user specifies the body dimensions as stature, sitting height and
corpulence of each virtual user of the test sample. The dimensions are
given with respect to the applications and the needs.
Scenario 1.2.2: Definition of impairments

In addition to the physical parameters the user specifies the impairment
classes (physical, cognitive and psychological), types and the
corresponding parameters for each virtual user of the test sample.
Primary Designer
Actor(s)
System Scenario 1.2.1: Definition of physical dimensions
input Gender, age group, year and nationality.
Body dimension classifications: stature (very short, short,
medium, tall and very tall), corpulence (slim, medium and large
waist) and torso (short, medium and long).

Class (physical, cognitive and/or psychological).
Type.
Other parameters.
System Scenario 1.2.1: Definition of physical dimensions
output Virtual user model file ready for the simulation platform (without
impairment).

Virtual user model file ready for the simulation platform (complete with

impairment).
Interaction Scenario 1.2.1: Definition of physical dimensions

steps Step 1 The user specifies the gender, age group, year and
nationality.
Step 2 The user specifies the body dimension classifications.
Step 3 The user stores the parameters in a virtual user model
file.

Step 1 The user specifies physical dimensions as in scenario
1 or loads dimensions from a virtual user model file.
Step 2 The user specifies impairment class.
Step 3 The user specifies impairment type.
Step 4 The user specifies impairment parameters.
Step 5 The user repeats step 2-4 for additional impairments.
Step 6 The user stores parameter in the virtual user model
file.
Connected UC1.1
UCs CATERGORY 2, 3, 4, 5, 6
Background Virtual user model definition is essential for virtual human design
info/ reason assessment.
on selection
and on
assigning
the priority
level
References
5.1.3 Virtual design analysis
5.1.3.1 Desktop simulation

Use Case No 1.3
Use Case Virtual design analysis for desktop simulation.
Title
Brief The accessibility of a product design is analysed based on the virtual
description simulation of the user interaction with the design. The user specifies the
(user goal virtual user (see UC 1.1), the design (import from external file) and the
satisfied) task. The task defines the interaction of the virtual user with the design
environment. Additionally the interaction is analysed and evaluated
according to specific criteria. This evaluation is finally used to compare
different design variants and identify the optimal solution.

Spaces
Relevant WP 1.3-1.5, 2.3-2.6, 3.1-3.5
Scenario Scenario 1.3.1: Assessment of design variant (desktop).

The user loads a geometrical design environment from an external file.
He/she selects a task from the task model repository file and specifies

the corresponding task objects in the design environment. Then he/she

runs the related simulation model to perform the virtual human design
interaction and to calculate the evaluation rating according to the design.
Scenario 1.3.2: Identification of optimal design variant (desktop).

The user modifies the design geometry or loads an alternative design file
and runs the simulation to achieve an alternatively rating. Through
comparing the ratings he/she identifies the best design alternative.
Primary Designer
Actor(s)
System input Scenario 1.3.1: Assessment of design variant (desktop).

Geometrical design environment file (to external application).
Task from VERITAS task model repository file.
Task objects in the design environment.

Modified design geometry.
Alternative design file.
System Scenario 1.3.1: Assessment of design variant (desktop).

output Design variant evaluation rating.

Evaluation ratings of several design variants.
Design variant with best evaluation results.
Interaction Scenario 1.3.1: Assessment of design variant (desktop).

steps Step 1 The user loads a geometrical design environment file.
Step 2 The user selects task from loaded task model repository
file.
Step 3 The user specifies the corresponding task objects in the
design environment.
Step 4 The user runs the simulation model to perform the
virtual human design.
Step 5 The system calculates the evaluation results according
to the design.

Step 6 The user modifies the design geometry or loads an
alternative design file.
Step 7 The user repeats steps 5&6 for every new design file.
Step 8 The user identifies design variant with best results.
Connected UC 1.1, 1.2

UCs
Background Virtual human design assessment is essentially to achieve accessible
info/ reason product in early design stages.
on selection
and on
assigning the
priority level

References
5.1.3.2 Immersive simulation

Use Case No 1.4
Use Case Virtual design analysis for immersive simulation
Title
Brief In the immersive simulation, the user specifies the virtual user (see UC
description 1.1) and the design (import from external application). The interaction
(user goal simulation and the task are replaced by the real behaviour of the user in
satisfied) the immersive environment. The evaluation of the users interaction is
analogue to the desktop case and can be used for design optimization.
Spaces
Relevant WP 1.3-1.5, 2.3-2.6, 3.1-3.5
Scenario
Scenario 1.4.1: Assessment of design variant (immersive).
The user loads a geometrical design environment from an external
application. Then he/she interacts with the virtual environment and feeds
the virtual human design interaction to calculate the evaluation rating
according to the design.
Scenario 1.4.2: Identification of optimal design variant (immersive).

The user modifies the design geometry or loads an alternative design file
and interacts with the virtual environment to achieve an alternatively
rating. Through comparing the ratings he/she identifies the best design
alternative.
Primary Designer
Actor(s)
System input
Scenario 1.4.1: Assessment of design variant (immersive).
Virtual user model file (see UC 1.1), which fits to users physical
dimensions.
Geometrical design environment file (from external application).

Modified design geometry.
Alternative design file.
System Scenario 1.4.1: Assessment of design variant (immersive).
output Design variant evaluation rating.

Evaluation ratings of several design variants.
Design variant with best evaluation results.
Interaction
steps Scenario1.4.1: Assessment of design variant (immersive).
Step 1 The user loads a virtual user model file.
Step 2 The user loads a geometrical design environment file.
Step 3 The user interacts in the environment and feeds the

virtual human design performance.

Step 4 The system calculates the evaluation results according
to the design.

In addition to scenario 1.4.1:
Step 5 The user modifies the design geometry or loads an
alternative design file.
Step 6 The user repeats steps 3&4 for every new design file.
Step 7 The user identifies design variant with best rating.
Connected UC 1.1, 1.2
UCs
Background Virtual human design assessment is essentially to achieve an accessible
info/ reason product in the early design stages.
on selection
and on
assigning the
priority level
References

5.2 Automotive sector

UC 2.1.a: Car interior accessibility UC 2.1.b: Car interior immersive
desktop simulation. simulation.
UC 2.2.a: Motorcycle handling UC 2.2.b: Motorcycle handling
accessibility desktop simulation. immersive simulation. .
UC 2.4.a: ARAS/OBIS functionalities UC 2.4.b: ARAS/OBIS
desktop simulation. functionalities immersive simulation.
5.2.1 Car interior

UC 2.1.a: Car interior UC 2.1.b: Car interior immersive
accessibility desktop simulation. simulation.
5.2.1.1 Car interior desktop simulation
Use Case No 2.1.a

Use Case Car interior accessibility desktop simulation.
Title
Brief The user realises a desktop simulation to design accessible car interior
description components, for specific type/s of users with disabilities.
(user goal
satisfied)
Application Smart Personal Infotainment Automotive
area Living HealthCare Workplace
Spaces
Relevant WP 2.2, 3.1
Scenario
Scenario 2.1.a.1: Central rear view mirror tuning.
The user wants to design the central rear view mirror of a car, based
upon to the driver's position and characteristics.
Scenario 2.1.a.1.1
The central rear view mirror is reachable by the beneficiary.
Scenario 2.1.a.1.2
The central rear view mirror is not reachable by an elderly
beneficiary.
Scenario 2.1.a.2: Lateral mirror tuning.

The user wants to design the control of the lateral view mirror of a car,
based upon to the driver's position and characteristics.
Scenario 2.1.a.2.1

The remote control of the lateral mirror is reachable by the

beneficiary.
Scenario 2.1.a.2.2
The remote control of the lateral mirror is not reachable by an
elderly beneficiary.
Scenario 2.1.a.3: Hand brake activation/deactivation.

The user wants to design the hand brake of a car, based upon to the
driver's position and characteristics.
Scenario 2.1.a.3.1
The hand brake lever is reachable.
Scenario 2.1.a.3.2
The hand brake lever is not reachable by an elderly beneficiary.
Scenario 2.1.a.3.2.1
The user has not enough force in the arm to activate the
hand brake lever.
The user has not enough force in the arm to deactivate
the hand brake lever.
Scenario 2.1.a.4: Gear changing (manual/automatic).

The user wants to design the gears of a car, based upon to the driver's
position and characteristics.
Scenario 2.1.a.4.1
Changing the manual gear when the lever is reachable.
Scenario 2.1.a.4.2
Changing the manual gear when the lever is not reachable by an
Scenario 2.1.a.4.3
Changing the automatic gear when the gear lever is reachable.
Scenario 2.1.a.4.4
Changing gear-automatic. The gear lever is not reachable by
elderly.
Scenario 2.1.a.5: Accessing interior storage compartments

The user wants to design the interior storage compartments of a car,
based upon to the driver's characteristics.
Scenario 2.1.a.5.1
Taking up an object when the compartment, located in the upper
part of the interior is reachable and can be opened.
Scenario 2.1.a.5.2
Taking up an object when the compartment, located in the upper
part of the interior is not reachable due to upper limb limitations.
Primary Designer
Actor(s)
System input Use Case 1.1:

Scenario 1.1.1
Use Case:1.2
Scenario 2.1 a.1: Central rear view mirror tuning
Scenario 2.1 a.1.1:

User model with no specific limitations (typical).

Scenario 2.1 a.1.2:
User model with upper limb movement limitations.
Scenario2.1 a. 2: Lateral mirror tuning

Scenario 2.1 a.2.1:
Scenario 2.1 a.2.2:
Scenario 2.1 a.3: Hand brake activation/deactivation

Scenario 2.1 a.3.1
Scenario 2.1 a.3.2
User model with specific upper limbs movement limitations.
Scenario 2.1 a.3.2.1
User model with specific upper limb traction force
limitation.
User model with specific upper limb pushing force
limitation.
Scenario 2.1 a.4: Gear changing

Scenario 2.1 a.4.1
Scenario 2.1 a.4.2
User model with upper limbs movement limitations and cannot
reach the gear lever
Scenario 2.1 a.4.3
Scenario2.1 a. 4.4
User model with upper limbs movement limitations.

Scenario 2.1.a.5.1
Scenario 2.1.a.5.2
User model with upper limb movement limitations, such that a
storage compartment located under the roof is not reached.
Use Case:1.3
Scenario 1.3.1
System Scenario 2.1.a.1-4:

output A number of adapted application screens and success criteria, by the
VERITAS Simulation Core Platform, based on the user model selected.
The simulation results indicate if the interaction is successful or not.
An EARL based report on the statistics, deviations from the simulation
models, interaction analysis and overall accessibility of the design.
Interaction
steps Scenario 2.1.a.1: Central rear view mirror tuning
Scenario 2.1 a.1.1:
Step 1 The user executes UC 1.2.
Step 2 The system extracts a user model with no
specific limitations according to the parameters defined in

Step 1.
Step 4 The system illustrates the geometrical
environment and saves the task to be realised.
Step 5 The user runs the simulation of the central rear
view mirror tuning.
Step 6 The system simulates the central rear view mirror
tuning task.
Step 7 - The system provides the simulation results
embedded in RAMSIS interface.
Step 8 - The system provides the user with an EARL
report.
Scenario 2.1 a.1.2:
Step 2 The system extracts an elderly user model with
upper limb impairment according to the parameters
identified in Step 1.
Step 5 The user runs the simulation of the central rear
view mirror tuning.
Step 6 The system simulates the central rear view mirror
tuning task.
report.
Scenario 2.1.a.2: Lateral mirror tuning

Scenario 2.1.a.2.1:
specific limitations according to the parameters identified
in Step 1.
Step 5 The user runs the simulation of the lateral mirror
tuning task.
Step 6 The system simulates the lateral rear view mirror
tuning task.
report.
Scenario 2.1.a.2.2:
Step 2 The system extracts an old elderly user model
with upper limb impairment according to the parameters
Step 5 The user runs the simulation of the lateral rear

view mirror tuning.

Step 6 The system simulates the lateral view mirror
tuning task.
report.
Scenario 2.1.a.3: Hand brake activation/deactivation

Scenario 2.1.a.3.1
in Step 1.
Step 5 The user runs the simulation of the hand brake
activation task.
Step 6 The system simulates the hand brake activation
task.
Step 7 The system provides the simulation results
Step 8 The system provides the user with an EARL
report.
Scenario 2.1.a.3.2
Step 2 The system extracts a female, young elderly user
model, with low height, according to the parameters
activation task.
Step 6 The system simulates the hand brake activation
task.
report.
Step 2 The system extracts a female, young elderly with
low height user model according to the parameters
deactivation task.
Step 6 The system simulates the hand brake
deactivation task.


report.
Scenario 2.1.a.4: Gear changing

Scenario 2.1.a.4.1
in Step 1.
Step 5 The user runs the simulation of the manual gear
changing task.
Step 6 The system simulates the manual gear changing
task.
report.
Scenario 2.1.a.4.2
Step 5 The user runs the simulation of the manual gear
changing task.
Step 6 The system simulates the manual gear changing
task.
report.
Scenario 2.1.a.4.3
in Step 1.
Step 5 The user runs the simulation of the automatic
gear changing task.
Step 6 The system simulates the automatic gear
changing task.
report.
Scenario 2.1.a.4.4


Step 5 The user runs the simulation of the automatic
gear changing task.
Step 6 The system simulates the automatic gear
changing task.
report.
Scenario 2.1.a.5: Accessing storage

Scenario 2.1.a.5.1
in Step 1.
Step 5 The user runs the simulation of reaching the
storage compartment task.
Step 6 The system simulates the task of reaching the
storage compartment.
report.
Scenario 2.1.a.5.2
upper limb limitations according to the parameters
Step 5 The user runs the simulation of the storage
compartment reach.
Step 6 The system simulates the storage compartment
reach task.
report.

X
Y
Figure 9: Axes of the driving position.
Connected UC 1.1, 1.2, 1.3

UCs UC 2.1.b
Background Tuning rear view mirror is one of the primary recommendations in order
info/ reason to guarantee the vehicle safety.
on selection
and on Activating or deactivating hand brake is a necessary action when
assigning immobilising or starting the route of a vehicle.
the priority
level Changing gears is a necessary task to perform driving.
Accessing interior compartment is a relevant convenience function, with

impact on safety both related to workload and distraction during driving
and also to accessing useful objects.
References

5.2.1.2 Car interior immersive simulation
Use Case 2.1.b

No
Use Case Car interior accessibility immersive simulation.
Title
Brief The user realises an immersive simulation to design the car interior for
description beneficiaries with specific types of users with disabilities.
(user goal
satisfied)
Spaces
Relevant 2.2, 3.1
WP
Scenario
Scenario 2.1.b.1: Central rear view mirror tuning
The user wants to design the central rear view mirror of a car, based
upon to the driver's position and characteristics.
Scenario 2.1.b.1.1
The central rear view mirror is reachable by the beneficiary.
Scenario 2.1.b.1.2
The central rear view mirror is not reachable by an elderly
beneficiary.
Scenario 2.1.b.2: Lateral mirror tuning

The user wants to design the lateral mirror of a car, based upon to the
Scenario 2.1.b.2.1
The remote control of the lateral mirror is reachable by the
beneficiary.
Scenario 2.1.b.2.2
The remote control of the lateral mirror is not reachable by an
Scenario 2.1.b.3: Hand brake activation/deactivation

The user wants to design the hand brake of a car, based upon to the
Scenario 2.1.b.3.1
The hand brake lever is reachable.
Scenario 2.1.b.3.2
The hand brake lever is not reachable by elderly.
Scenario 2.1.b.3.2.1
User has not enough force in the arm to activate the
hand brake lever.
User has not enough force in the arm to deactivate the
hand brake lever.
Scenario 2.1.b.4: Gear changing (manual/automatic)

The user wants to design the gears of a car, based upon to the driver's
position and characteristics.
Scenario 2.1.b.4.1

Changing the manual gear when the lever is reachable.

Scenario 2.1.b.4.2
Changing the manual gear when the lever is not reachable by
an elderly beneficiary.
Scenario 2.1.b.4.3
Changing the automatic gear when the gear lever is reachable.
Scenario 2.1.b.4.4
Changing gear-automatic. The gear lever is not reachable by
elderly.
Scenario 2.1.b.5: Interior storage compartments

The user wants to design the nterior storage compartments of a car,
based upon to the driver's position and characteristics.
Scenario 2.1.b.5.1
Taking up an object when the compartment, located in the
upper part of the interior, is reachable and can be opened.
Scenario 2.1.b.5.2
Taking up an object when the compartment, located in the
upper part of the interior is not reachable due to upper limb
limitations.
Primary Designer
Actor(s)
Priority Essential Secondary Supportive
level
System Use Case 1.1:
input Scenario 1.1.1
Use Case:1.2
Scenario 2.1.b.1.1:
Scenario 2.1.b.1.2:
Scenario2.1.b.2: Lateral mirror tuning

Scenario 2.1.b.2.1:
Scenario 2.1.b.2.2:

Scenario 2.1.b.3.1
Scenario 2.1.b.3.2
User model with specific upper limbs movement limitations.
User model with specific upper limb traction force
limitation.
User model with specific upper limb pushing force
limitation.
Scenario 2.1.b.4: Gear changing

Scenario 2.1.b.4.1


Scenario 2.1.b.4.2
User model with upper limbs movement limitations and cannot
reach the gear lever
Scenario 2.1.b.4.3
Scenario2.1.b.4.4
User model with upper limbs movement limitations.
Scenario 2.1.b.5: Accessing interior storage compartments

Scenario 2.1.b.5.1
Scenario 2.1.b.5.2
User model with upper limbs movement limitations, such that a
storage compartment located under the roof is not reached.
Use Case:1.4
Scenario 1.4.1
System Scenario 2.1.b.1-4

output The developer as simulated immersed (disabled or non disabled) user,
identifies possible difficulties and constraints in executing the
perspective. An EARL based report on the statistics, deviations from
the simulation models, interaction analysis and overall accessibility of
the design is also provided to the user.
Interaction
steps Scenario 2.1.b.1: Central rear view mirror tuning
Scenario 2.1.b.1.1:
in Step 1.
environment and connects with the user interaction
tools.
Step 5 The user executes the simulation of the central
rear view mirror tuning task.
Step a- The user is seating in the vehicle and
wants to tune the position of the central rear view
mirror.
Step b The user moves his/her right hand from
the steering wheel up to the central mirror.
Step c The user grasps the rear view mirror.
Step d - The user rotates the mirror to reach a
correct position.
Step e- The user check the position by looking
back through the mirror.
Step f The user releases his/her hand from the
mirrors and moves it back to the steering wheel.
Step 6 The system simulates the ability/disability of the
user model via the interaction tolls the developer uses.
report.

Scenario 2.1.b.1.2:
Step 2 The system extracts a user model with upper
limb movement limitations according to the parameters
of the Step 1.
tools.
wants to tune the position of the central rear view
mirror.
the steering wheel up to the central mirror.
Step c The user cannot reach the rear view
mirror.
Step d- The user releases his/her hand from the
mirrors and moves it back to the steering wheel.
report.

Scenario 2.1.b.2.1:
in Step 1.
tools.
Step 5 The user executes the simulation of the lateral
wants to tune the position of the lateral mirror.
Step b The user moves his/her left hand from
the steering wheel up to the door remote control.
Step c The user grasps the rear view mirror.
Step d - The user moves the button with one
finger to reach a correct position.
Step e- The user check the position by looking
back through the mirrors.
Step f The user releases his/her hand from the
remote control and move it back to the steering
wheel.
report.
Scenario 2.1.b.2.2:


tools.
wants to tune the position of the lateral mirror.
the steering wheel up to the door remote control.
Step c The user cannot reach the door remote
control.
Step d- The user moves his/her hand back to the
steering wheel.
report.

Scenario 2.1.b.3.1
in Step 1.
tools.
Step 5 The user executes the simulation of the hand
brake activation task.
wants to activate or deactivate the hand brake
(parking brake).
Step b The user grasps the hand brake.
Step c The user pushes the release button.
Step d - The user moves down or up the hand
brake (translation x, y).
Step e- The user releases the hand brake and
move his/her hand back to the steering wheel.
report.
Scenario 2.1 a.3.2
specific limitations according to the parameters of the
Step 1.


tools.
(parking brake).
Step d - The user cannot move up the hand
report.
Step 1.
tools.
(parking brake).
Step d - The user cannot move down the hand
report.
Scenario 2.1 a.4: Gear changing

Scenario 2.1 a.4.1
Step 1.
tools.
Step 5 The user executes the simulation of the manual
gear changing task.
Step a- The user is driving the vehicle and wants

to shift the gear.

the steering wheel position down to the gear
shift.
Step c The user grasps the gear shift lever.
Step d The user moves the gear shift lever
(translation x, y).
Step e The user releases the hand from the
lever.
Step f The user moves back the hand toward
the steering wheel.
report.
Scenario 2.1 a.4.2
Step 1.
tools.
Step 5 The user executes the simulation of the manual
gear changing task.
to shift the gear.
Step b The user cannot realise X or Y
translation movements.
Step c The user releases the hand from the
lever.
Step d The user moves back the hand toward
the steering wheel.
report.
Scenario 2.1 a.4.3
Step 1.
tools.
Step 5 The user executes the simulation of the
automatic gear changing task.
to shift the gear.
the steering wheel position down to the gear
shift.
Step c The user grasps the gear shift lever.

Step d The user moves the gear shift lever

(translation x, y).
Step e The user releases the hand from the
lever.
Step f The user moves back the hand toward
the steering wheel.
report.
Scenario 2.1 a.4.4
Step 1.
tools.
Step 5 The user executes the simulation of the
automatic gear changing task.
to shift the gear.
Step b The user cannot realise X or Y
translation movements.
Step c The user releases the hand from the
lever.
Step d The user moves back the hand toward
the steering wheel.
report.

Scenario 2.1 b.52.1:
in Step 1.
tools.
Step 5 The user executes the simulation of the storage
reach task.
wants to reach a storage compartment located
under the roof.
Step b The user moves the right hand from the
steering wheel up to the opening handle of the
storage compartment door.
Step c The user grasps the handle with one
finger.
Step d - The user lowers the door.

Step e- The user checks the position by looking

back through the mirror.
Step f The user introduces the hand in the
compartment in order to take out a pair of
sunglasses.
user model via the interaction tools the developer uses.
report.
Scenario 2.1 b.5.2:
Step 2 The system extracts a user model with relevant
upper limb limitations, according to the parameters
tools.
Step a - The user is seating in the vehicle and
wants to reach a storage compartment located
under the roof.
Step b The user moves the right hand from the
steering wheel towards the opening handle of the
storage compartment door.
Step c The user cannot reach the door remote
control.
Step d - The user moves the hand back to the
steering wheel.
user model via the interaction tools the developer uses.
report.
Z
X
Y
Figure 10: Axes of the driving position.

UCs UC 2.1.a
Background Tuning a rear view mirror is one of the primary recommendations in

info/ reason order to guarantee good vehicle safety.
on selection
and on Activating or deactivating hand brake is a necessary action when
assigning parking or de-parking the vehicle.
the priority

level Changing gears is necessary to perform the driving task.
Accessing interior compartment is a relevant convenience function, with

impact on safety both related to workload and distraction during driving
and also to accessing useful objects such as e.g. sunglasses.
References

5.2.2 Motorcycle
Category 2.b:
Category 2.a: Automotive
Automotive
desktop simulation.
immersive simulation
UC 2.2.b: Motorcycle
UC 2.2.a: Motorcycle handling
handling immersive
simulation.
5.2.2.1 Motorcycle desktop simulation
Use Case 2.2.a.

No
Use Case Motorcycle handling accessibility desktop simulation.
Title
Brief The user realises a desktop simulation to design an accessible
description motorcycle for specific types of users with disabilities.
(user goal
satisfied)
Application Smart Infotainment Automotive
area Living Personal Workplace
Spaces HealthCare
Relevant 1.3, 2.1, 2.2, 2.7, 3.1, 3.6, 3.7, 3.8
WP
Scenario
Scenario 2.2.a.1: Riding position
The user wants to simulate the riders adequate riding position, in order
to design the motorcycle adapted to the users characteristics.
Scenario 2.2.a.1.1
The beneficiary is able to take an adequate position on the
motorcycle.
Scenario 2.2.a.1.2
The beneficiary with upper limb impairment is not able to take
an adequate position on the motorcycle.
Scenario 2.2.a.2: Usage on bumpy road

The user wants to simulate the riders articular response to acceleration
on bumpy roads, in order to design the motorcycle adapted to the
users characteristics.
Scenario 2.2.a.2.1
The beneficiary is able to have adequate articular response.
Scenario 2.2.a.2.2
The young elderly beneficiary with upper limb impairment is not
able to have adequate articular response.
Scenario 2.2.a.3: Central stand

The user wants to simulate the riders ability to place the vehicle on the
centre stand, in order to design the motorcycle adapted to the users
characteristics.
Scenario 2.2 a.3.1
The motorcycle can be placed upon the centre stand from the
beneficiary.

Scenario 2.2 a.3.2

The motorcycle cannot be placed upon the centre stand from an
Primary Designer
Actor(s)
level
Use Case:1.2

Scenario 2.2.a.1.1
Scenario 2.2.a.1.2
User model with upper limb impairment.

Scenario 2.2.a.2.1
Scenario 2.2.a.2.2
User model with upper limb impairment.

Scenario 2.2.a.3.1
Scenario 2.2.a.3.2
Elderly user model.
Use Case:1.3
Scenario 1.3.1
System Scenario 2.2.a.1-3:

VERITAS Simulation Core Platform, based on the user model selected,
the simulation result is indicating if the interaction is successful or not.
Interaction
steps Scenario 2.2.a.1: Riding position
Scenario 2.2.a.1.1
in Step 1.
Step 5 The user runs the simulation of riding position.
Step 6 The system simulates riding position.

report.
Scenario 2.2.a.1.2
limb impairment according to the parameters identified in
Step 1.
Step 5 The user runs the simulation of riding position.
Step 6 The system simulates riding position.
report.

Scenario 2.2.a.2.1
in Step 1.
Step 5 The user runs the simulation of riding on bumpy
road.
Step 6 The system simulates riding on bumpy road.
report.
Scenario 2.2.a.2.2
Step 2 The system extracts an elderly user model
according to the parameters of the Step 1.
Step 3 The user executes UC 1.3
Step 5 The user runs the simulation of riding on bumpy
road.
Step 6 The system simulates riding on bumpy road.
report.

Scenario 2.2 a.3.1
Step 1.


Step 5 The user runs the simulation of placing the
motorcycle upon the centre stand.
Step 6 The system simulates placing the motorcycle
upon the centre stand.
report.
Scenario 2.2.a.3.2
limb impairment according to the parameters of the Step
1.
Step 5 The user runs the simulation of placing the
Step 6 The system simulates the task of placing the
report.

UCs UC 2.2.b
Background The scenarios of the riding position, usage on bumpy roads and placing
info/ reason the motorcycle on the central stand are considered to be the basic ones
on selection for riding a motorcycle. They cover all the basic functionalities of all
and on riders and most of all the elderly riders to which the focus is on.
assigning
the priority
level.
References

5.2.2.2 Motorcycle immersive simulation
Use Case 2.2.b.

No
Use Case Motorcycle accessibility immersive simulation.
Title
Brief The user realises an immersive simulation to assess the accessibility of
description the motorcycle for specific types of users with functional limitations.
(user goal
satisfied)
Spaces HealthCare
Relevant 1.3, 2.1, 2.2, 2.7, 3.1, 3.6, 3.7, 3.8
WP
Scenario Scenario 2.2.b.1: Ridding the motorcycle
The user wants to simulate the riders ability to ride the vehicle, in order
to design the motorcycle adapted to the users characteristics.
Scenario 2.2.b.1.1
The footrest height (central tunnel) allows the passage of the
legs of the beneficiary.
Scenario 2.2.b.1.2
The footrest (central tunnel) is too high to allow the passage of
the leg of the beneficiary.
Scenario 2.2.b.2: Lateral mirror adjustment

The user wants to simulate the riders ability to adjust the position of the
lateral rear view mirror to his/her preferences, in order to design the
motorcycle adapted to the users characteristics.
Scenario 2.2.b.2.1
The lateral rear view mirror is reachable.
Scenario 2.2.b.2.2
The lateral rear view mirror is not reachable by the elderly.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 2.2.b.1: Ridding the motorcycle
Scenario 2.2.b.1.1
Scenario 2.2.b.1.2

Scenario 2.2.b.2.1
Scenario 2.2.b.2.2

System Scenario 2.2. b.1-2

respective. An EARL based report on the statistics, deviations from the
simulation models, interaction analysis and overall accessibility of the
design is also provided to the user.
Interaction Scenario 2.2.b.1.1: Ridding the motorcycle

steps Scenario 2.2.b.1.1
Step 1.
environment and connects with the user interaction tools.
Step 5 The user executes the simulation of getting on
the motorcycle.
Step a - The user moves near the motorcycle and
wants to get on it.
Step b - The user raises his/her leg to overcome
the vehicles footrest.
Step c - The user overcomes the footrest and
rides the motorcycle.
report.
Scenario 2.2.b.1.2
limb impairments according to the parameters of the
Step 1.
Step a - The user moves near the vehicle and
wants to get on it.
Step b - The user raises his/her leg to overcome
the vehicles footrest.
Step c - The user is not able to raise enough
his/her leg to overcome the footrest.
report.
Scenario 2.2.b.1.2: Lateral mirror adjustment

Scenario 2.2.b.2.1
Step 1.


Step 5 The user executes the simulation of tuning the
lateral mirror.
Step a - The user is ridding the motorcycle
(scenario 1) and wants to adjust lateral rear view
mirror position.
Step b - The user moves his/her hand to reach
the mirror.
Step c - The user grasps the mirror.
Step d - The user moves the mirror in the correct
position.
report.
Scenario 2.2.b.2.2
limb impairments according to the parameters of the
Step 1.
Step a - The user is seated on the vehicle and
wants to adjust lateral rear view mirror position
Step b - The user moves his/her hand to reach
the mirror
Step c - The user is not able to reach the mirror
report.
UCs UC 2.2.a
Background The scenarios of the riding the motorcycle and adjusting the lateral
info/ reason mirror cover the main scenarios that the designers of the motorcycles
on selection are interested to implement in order to realise the abilities and
and on disabilities of the users.
assigning
the priority
level.
References

5.2.3 ADAS/IVIS
5.2.3.1 ADAS/IVIS desktop simulation
Use Case No 2.3.a

Use Case Title ADAS/IVIS functionalities in desktop simulation.
Brief The user realises a desktop simulation to create an accessible design
description of ADAS and IVIS functionalities for specific types of users with
(user goal disabilities.
satisfied)
Application Smart Personal Automotive
area Living HealthCare Infotainment Workplace
Spaces
Scenario Scenario 2.3.a.1: On-board navigation system programming

The user wants to design an accessible navigation system integrated in
the vehicle.
Scenario 2.3.a.1.1
The navigation display is reachable.
Scenario 2.3.a.1.2
The navigation display is not reachable by an elderly
beneficiary.
Scenario 2.3.a.1.3
The navigation display is not visible by the beneficiary with
limitations.
The navigation is not visible by the driver because he
cannot rotate enough his/her head.
has visual limitations (tunnel vision).
Scenario 2.3.a.2: Audio system programming and tuning

The user wants to design an accessible audio system.
Scenario 2.3.a.2.1
The audio display is reachable
Scenario 2.3.a.2.2
The audio display is not reachable
Scenario 2.3.a.3: Navigation information accessibility

The user wants to design a navigation system with accessible
informatory content.
Scenario 2.3.a.3.1
The navigation information provided form the navigation both
auditory and on the screen.
Scenario 2.3.a.3.2

The navigation information displayed on the navigation screen

either auditory and on the screen are not legible.
Primary Designer
Actor(s)

Scenario 1.1.1
Use Case:1.2
Scenario 2.3.a.1: On-board navigation system Programming
Scenario 2.3.a.1.1
Scenario 2.3.a.1.2
Elderly user model with upper limp limitations.
Scenario 2.3.a.1.3
User model with upper limp limitations.
User model with visual limitations (tunnel vision).

Scenario 2.3.a.2.1
Scenario 2.3.a.2.1
User model with upper limb limitations.

Scenario 2.3.a.3.1
Scenario 2.3.a.3.2
Elderly user model with low reaction time.
System output Scenario 2.3.a.1-3:

A number of adapted application screens and success criteria, by the
Interaction Scenario 2.3.a.1: On-board navigation system programming
steps Scenario 2.3.a.1.1
in Step 1.
Step 5 The user runs the simulation for reaching the
navigation unit task.
Step 6 The system simulates the reaching the


report.
Scenario 2.3.a.1.2
upper limp limitations according to the parameters
report.
Scenario 2.3.a.1.3
limp limitations according to the parameters identified in
Step 1.
Step 5 The user runs the simulation for seeing the
Step 6 The system simulates the seeing the navigation
unit task.
report.
Step 2 The system extracts a user model with visual
limitations according to the parameters identified in Step
1.
embedded in the RAMSIS interface.
report.


Scenario 2.3.a.2.1
in Step 1.
Step 5 The user runs the simulation of the audio
system programming and tuning task.
report.
Scenario 2.3.a.2.2
limb limitations according to the parameters identified in
Step 1.
Step 5 The user runs the simulation of the audio
system programming and tuning task.
report.

Scenario 2.3.a.3.1
Step 2 The system extracts an user model with no
in Step 1.
Step 5 The user runs the simulation of the navigation
system providing information to the driver.
Step 6 The navigation system providing information to
the driver.
report.
Scenario 2.3.a.3.2
reduced reaction time according to the parameters

Step 5 The user runs the simulation of the navigation
Step 6 The system simulates the task of the navigation
report.
UCs UC 2.2.a
Background During the last decade, Advanced Driver Assistance Systems (ADAS)
info/ reason and In-Vehicle Information Systems (IVIS) development is one of the
on selection main research areas of the automotive industry, aiming to increase
and on safety and comfort of four-wheel vehicles. These new technologies
assigning the have been already introduced in the automotive market and their
priority level evolution is fast and efficient.
An increase in the ADAS and IVIS market penetration is achievable, if
vehicle manufacturers begin to take a more proactive approach to
marketing ADAS systems by including them to the original design of
the vehicle.
Elderly and disable can get great assistant by using ADAS and IVIS at
their vehicles as long as they are designed according to their needs.
References
5.2.3.2 ADAS/IVIS immersive simulation
Use Case 2.3.b

No
Use Case ADAS/IVIS functionalities in immersive simulation.
Title
Brief The user realises an immersive simulation to create an accessible
description ADAS and IVIS design for specific types of users with disabilities.
(user goal
satisfied)
Spaces
Relevant 2.2, 3.1
WP
Scenario Scenario 2.3.b.1: On-board navigation system programming
The user wants to assess the accessibility of dialling an "address" on
the on-board navigation system.
Scenario 2.3.b.1.1
The navigation display is reachable.
Scenario 2.3.b.1.2
The navigation display is not reachable by an elderly

beneficiary.
Scenario 2.3.b.1.3
The navigation display is not visible by the beneficiary.
cannot rotate enough his/her head.
has visual limitations (tunnel vision).
Scenario 2.3.b.2: Audio system programming and tuning

The user wants to assess the accessibility of programming and tuning
the audio system.
Scenario 2.3.b.2.1
The audio display is reachable.
Scenario 2.3.b.2.2
The audio display is not reachable.
Scenario 2.3.b.3: Navigation information accessibility

The user wants to assess the accessibility of the information displayed
by the navigation system to reach a destination.
Scenario 2.3.b.3.1
The navigation information provided form the navigation both
auditory and on the screen are legible.
Scenario 2.3.b.3.2
The navigation information displayed on the navigation screen
either auditory and on the screen are not legible.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 2.3.b.1: On-board navigation system programming
Scenario 2.3.b.1.1
Scenario 2.3.b.1.2
Scenario 2.3.b.1.3
User model with visual limitations.

Scenario 2.3.b.2.1
Scenario 2.3.b.2.2
User model with upper limb limitations.

Scenario 2.3.a.3.1

Scenario 2.3.a.3.2
Elderly user model with reduced reaction time.

Interaction Scenario 2.3.b.1: On-board navigation system Programming
in Step 1.
tools.
Step 5 The user executes the simulation of
programming the navigation system.
wants to dial a new destination on the navigation
display,
the steering wheel up to the navigation display,
Step c The user pushes the buttons or touch
the tactile screen with a finger (several times) to
dial the destination coordinates.
user model via the interaction tolls, the developer uses.
report.
Scenario 2.3.b.1.2
upper limp limitations according to the parameters
tools.
Step 1 - The user is seating in the vehicle and
display
Step 2 The user moves his/her right hand from
the steering wheel up toward the navigation
display
Step 3 The user cannot reach the navigation
display.


report.
Scenario 2.3.b.1.3
limp limitations according to the parameters identified in
Step 1.
tools.
display
Step b The user cannot see the navigation
display because he/she cannot rotate enough
his/her head.
report.
1.
tools.
display.
the steering wheel up toward the navigation
display.
Step c The user cannot see correctly the
information displayed and select the right letters
to dial is destination onto the navigation display.
report.

Scenario 2.3.b.2.1

Step 1.
tools.
wants to tune the audio system
Step a The user moves his/her right hand from
the steering wheel up to the audio display
Step a The user look to the audio display and
pushes the buttons or touch the tactile screen
with a finger(several times) to tune the audio
system
report.
Scenario 2.3.b.2.2
limp limitations according to the parameters of the Step
1.
tools.
wants to tune the audio system
the steering wheel up toward the audio display
Step c The user look to the audio display but
cannot reach it
report.

Scenario 2.3.b.3.1
Step 1.
tools.
Step 1 - The user is driving the vehicle and gets

informed by the navigation system for a right turn

in 100 metres, both auditory and visually.
Step 2 The user sees and applies the
recommendations displayed by the navigation
system.
report.
Scenario 2.3.b.3.2
reduced reaction time according to the parameters of the
Step 1.
tools.
Step 1 - The user is driving the vehicle and gets
informed by the navigation system for a right turn
in 100 metres, both auditory and optically.
Step 2 The user understood the information but
due to the reduced reaction time did not
implement it on time.
report.
UCs UC 2.3.a
Background During the last decade, Advanced Driver Assistance Systems (ADAS)
info/ reason and In-Vehicle Information Systems (IVIS) development is one of the
on selection main research areas of the automotive industry, aiming to increase
and on safety and comfort of four-wheel vehicles. These new technologies
assigning have been already introduced in the automotive market and their
the priority evolution is fast and efficient.
level An increase in the ADAS and IVIS market penetration is achievable, if
vehicle manufacturers begin to take a more proactive approach to
marketing ADAS systems by including them to the original design of
the vehicle.
Elderly and disable can get great assistant by using ADAS and IVIS at
their vehicles as long as they are designed according to their needs.
References

5.2.4 ARAS/OBIS
Category 2.a:
Category 2.b: Automotive
Automotive desktop
immersive simulation
simulation.
UC 2.4.a: ARAS/OBIS UC 2.4.b: ARAS/OBIS
functionalities desktop functionalities immersive
5.2.4.1 ARAS/OBIS desktop simulation
Use Case 2.4.a

No
Use Case ARAS/OBIS functionalities desktop simulation.
Title
description of the ARAS and OBIS for specific types of users with disabilities.
(user goal
satisfied)
Spaces
Relevant 2.2, 3.1
WP
Scenario
Scenario 2.4.a.1: Collision Avoidance system (CAS).
The user wants to design accessible CAS for the motorcycle.
Scenario 2.4.a.1.1: Collision Avoidance system interface
without the right colours to support colour-blindness.
without the correct speech characteristics for hearing
impairments.
Scenario 2.4.a.1.3: Collision Avoidance system that give
warning too late for an elderly beneficiary with reduced reaction
time.
Scenario 2.4.a.2: Navigation

The user wants to assess the accessibility of the navigation system of
the motorcycle.
Scenario 2.4.a.2.1: Navigation system placed out of the field of
vision.
Scenario 2.4.a.2.2: Navigation system without the correct
speech characteristics for hearing impairments.
Scenario 2.4.a.2.3: Navigation system placed at a position that
cannot be reached by elderly.
Primary Designer
Actor(s)
level


Use Case:1.2
Scenario 2.4.a.1: Collision Avoidance system (CAS)
Scenario 2.4.a.1.1
Scenario 2.4.a.1.2
User model with hearing limitations.
Scenario 2.4.a.1.3
Elderly user model with reduced reaction time.

Scenario 2.4.a.2.1
Elderly user model with reduced peripheral Field of vision (FoV).
Scenario 2.4.a.2.2
Scenario 2.4.a.2.3
Elderly user model.
Use Case 1.3

Scenario 1.3.1
System
output Scenario 2.4.a.1-2
A number of adapted application screens and success criteria, by the
Interaction
steps Scenario 2.4.a.1: Collision Avoidance system (CAS)
Scenario 2.4.a.1.1:
1.
Step 5 The user runs the simulation of the CAS giving
information to the user.
Step 6 The system simulates the task of the CAS
giving information to the user.
report.
Scenario 2.4.a.1.2
Step 2 The system extracts a user model with hearing
1.


report.
Scenario 2.4.a.1.3
report.

Scenario 2.4.a.2.1:
Step 2 The system extracts a user model with reduced
peripheral Field of vision according to the parameters
Step 5 The user runs the simulation the task of seeing
the navigation screen.
Step 6 The system simulates the task of seeing the
navigation screen.
report.
Scenario2.4.a. 2.2:
impairment according to the parameters identified in
Step 1.
Step 5 The user runs the simulation of the task where
the navigation gives information to the user about the
route.
Step 6 The system simulates the task where the
navigation gives information to the user about the route.


report.
Scenario 2.4.a.2.3:
according to the parameters identified in Step 1.
Step 5 The user runs the simulation of reaching the
navigation device task.
Step 6 The system simulates of reaching the
navigation device task.
report.

UCs UC2.4.b
Background ARAS and OBIS are the ADAS and IVIS of the motorcycles. Even if
info/ reason ADAS and IVIS have been already introduced in the automotive market
on selection and their evolution is fast and efficient, the application of such
and on technologies in motorcycles (ARAS and OBIS), in order to increase the
assigning safety and comfort of riders, an extremely susceptible road user group,
the priority is currently lacking behind.
level Such technologies should be designed in a way that will not interfere
with the riding task. Motorcycles are very sensitive vehicles and any
unexpected change in their motion could lead to loss of control and
most probably to an accident.
An EU funded project that has just ended and performed research on
the ARAS and OBIS domain is SAFEWRIDER in which ARAS and
OBIS where studied, designed and tested.
References SAFERIDER project ( http://www.saferider-eu.org/ )
5.2.4.2 ARAS/OBIS immersive simulation
Use Case 2.4.b

No
Use Case ARAS/OBIS functionalities immersive simulation.
Title
description of the ARAS and OBIS for specific types of users with disabilities.
(user goal
satisfied)
Spaces
Relevant 2.2, 3.1
WP

Scenario
The user wants to assess the accessibility of the CAS of the
motorcycle.
without the right colours to support colour-blindness.
without the correct speech characteristics for hearing
impairments.
Scenario 2.4.b.1.3: Collision Avoidance system that give
warning too late for an elderly beneficiary with reduced reaction
time.

The user wants to assess the accessibility of the navigation system of
the motorcycle.
Scenario 2.4.a.2.1: Navigation system placed out of the field of
vision.
Scenario 2.4.a.2.2: Navigation system without the correct
speech characteristics for hearing impairments.
Scenario 2.4.a.2.3: Navigation system at a position that cannot
be reached by elderly.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 2.4.b.1: Collision Avoidance system (CAS)
Scenario 2.4.b.1.1
Scenario 2.4.b.1.2
Scenario 2.4.b.1.3
Elderly user model with reduced reaction time
Scenario 2.4.b.2: Navigation

Scenario 2.4.b.2.1
Elderly user model with reduced peripheral Field of vision (FoV).
Scenario 2.4.b.2.2
Scenario 2.4.b.2.3
Elderly user model.
Use Case 1.4

Scenario 1.4.1
System
output Scenario 2.4.b.1-2
The developer as simulated immersed (disabled or non disabled) user,


Interaction
steps Scenario 2.4.b.1: Collision Avoidance system (CAS)
Scenario 2.4.b.1.1:
1.
Step 1- The user rides the motorcycle and wants
to be informed when he/she is too close to the
vehicle in front and the Time to Collision (TTC) is
critical.
Step 2- The user turns the CAS system on.
Step 3- The user starts the route.
Step 4- The system provides the model with
vision signals for the TTC of the street that is
riding on.
Step 5- The user TTC is as low as the critical
limit.
Step 6- The system alerts the model with a red
coloured HMI, with an acoustic tone and with a
haptic alert from the helmet.
Step 7- The user does not understand the
difference of the colours.
Step 6 The system simulates the disability of the user
model via the interaction tolls the developer uses.
report
Scenario 2.4.b.1.2:
1.
critical.
riding on.

limit.
coloured HMI, with an acoustic tone and with
haptic alert at the helmet.
Step 7- The user does not understand the
acoustic signal.
report
Scenario 2.4.b.1.3
critical.
riding on.
limit.
coloured HMI, with an acoustic tone and with
haptic alert at the helmet.
Step 7- The user understands the signals too late
to avoid the other vehicle.
report

Scenario 2.4.b.2.1:
Step 2 The system extracts a user model with reduced
peripheral Field of vision according to the parameters
to be navigated during his/her route.
Step 2- The user turns the navigation system on.

Step 3- The user inserts his/her route origin and

destination.
Step 5- The user provides the model with vision
and audit information to guide him /her through
the route.
Step 6- The user cannot see the navigation
system because it is out of the field of vision.
report
Scenario 2.4.b.2.2:
1.
Step 3- The user inserts his/her route origin and
destination.
vision and audit information to guide him /her
through the route.
Step 6- The user cannot hear the navigation
system because of its low volume.
report.
Scenario 2.4.b.2.3:
Step 3- The system is too far and the model hurts
and cannot reach it.


report.

UCs UC2.4.b
Background ARAS and OBIS are the ADAS and IVIS of the motorcycles. Even if
info/ reason ADAS and IVIS have been already introduced in the automotive market
on selection and their evolution is fast and efficient, the application of such
and on technologies in motorcycles (ARAS and OBIS), in order to increase the
assigning safety and comfort of riders, an extremely susceptible road user group,
the priority is currently lacking behind.
level Such technologies should be designed in a way that will not interfere
with the riding task. Motorcycles are very sensitive vehicles and any
unexpected change in their motion could lead to loss of control and
most probably to an accident.
An EU funded project that has just ended and performed research on
the ARAS and OBIS domain is SAFEWRIDER in which ARAS and
OBIS where studied, designed and tested.
References SAFERIDER project ( http://www.saferider-eu.org/ )

5.3 Smart living places
5.3.1 Interior Design
Category 3.a: Smart Category 3.b: Smart living

living places design places simulation
UC 3.1.a: Interior Design UC 3.1.b: Interior Design
5.3.1.1 Interior Design desktop simulation

Use Case No UC 3.1.a
Use Case Interior Design desktop simulation
Title
Brief The user realises an interior design desktop simulation in order to be
description supported during the design of a home/building environment in relation
(user goal with several issues of accessibility.
satisfied)
Spaces HealthCare
Scenario Scenario 3.1.a.1: In-building navigation accessibility

The user wants to design an accessible for navigation interior of a
building (i.e. stair-step height, inclination of ramps, door width, etc.)
Scenario 3.1 a.1.1
The stair-step height is comfortable for the beneficiary.
Scenario 3.1 a.1.2
The inclination of the ramp is not accessible by a beneficiary with
lower limb impairments in a wheelchair.
Scenario 3.1 a.1.3
The door pass is not accessible by a beneficiary with lower limb
impairments in a wheelchair.
Primary Designer
Actor(s)

Scenario 1.1.1
Use Case:1.2
Scenario 3.1.a.1: In-building navigation accessibility
Scenario 3.1 a.1.1
User model with low limb limitations.
Scenario 3.1 a.1.2
User model with lower limb impairments on a wheelchair.
Scenario 3.1 a.1.3
Use Case:1.3

Scenario 1.3.1
System A number of adapted application screens and success criteria, by the

output VERITAS Simulation Core Platform, based on the user model selected,
Interaction Scenario 3.1.a.1: In-building navigation accessibility
steps Scenario 3.1.a.1.1:
Step 2 The system extracts a user model with low limb
1.
Step 5 The user runs the simulation of climbing on the
stair task.
Step 6 The system simulates of climbing on the stair
task.
embedded in VRfx interface.
report.
Scenario 3.1.a.1.2:
Step 2 The system extracts a user model with lower
limb impairments on a wheelchair according to the
parameters identified in Step 1.
Step 5 The user runs the simulation of climbing on the
ramp task.
Step 6 The system simulates of climbing on the ramp
task.
report.
Scenario 3.1.a.1.3:
lower limb impairments on a wheelchair according to the
parameters of the Step 1.
Step 5 The user runs the simulation of passing through
a door task.
Step 6 The system simulates of passing through a door
task.


report.
UCs UC 3.1.b
Background Interior design and its accessibility is fundamental to guarantee excellent

info/ reason life conditions for disabled and elderly people, since the physical barriers
on selection and barriers due to inaccessible technology often hinder these people
and on during their everyday life. The accessibility has to be involved from the
assigning beginning of the design phase, since a good numbers of possible
the priority obstacles may be easily removed with no great impacts on the whole
level project.
References
5.3.1.2 Interior Design immersive simulation

Use Case No UC 3.1.b
Use Case Interior Design immersive simulation.
Title
Brief The user realises an immersive design simulation in order to be
description supported during the design of a home environment in relation with
(user goal several issues of accessibility.
satisfied)
Spaces HealthCare
Scenario Scenario 3.1.b.1: In-building navigation accessibility

The user wants to design an accessible for navigation interior of a
building (i.e. stair-step height, inclination of ramps, door width, etc.)
Scenario 3.1.b.1.1
The stairs-steps height is not comfortable for the beneficiary.
Scenario 3.1.b.1.2
The inclination of the ramp is not accessible by an elderly
beneficiary with lower limb impairments on a wheelchair.
Scenario 3.1.b.1.3
The door is not accessible by a beneficiary with lower limb
impairments on a wheelchair.
Primary Designer
Actor(s)

Scenario 1.1.1
Use Case:1.2
Scenario 3.1.b.1: In-building navigation accessibility
Scenario 3.1.b.1.1
User model with low limb limitations.
Scenario 3.1.b.1.2


Scenario 3.1.b.1.3
Use Case:1.4
Scenario 1.4.1
System The developer as simulated immersed (disabled or non disabled) user,

output identifies possible difficulties and constraints in executing the respective.
models, interaction analysis and overall accessibility of the design is also
provided to the user.
Interaction Scenario 3.1.b.1: In-building navigation accessibility
steps Scenario 3.1.b.1.1:
Step 2 The system extracts a user model with low limb
1.
Step 5 The user executes the simulation of the climbing
on a stair task.
Step a- The user is walking and needs to climb on
a stair to reach his/her final destination.
Step b The user raises his/her leg trying to reach
the height of the stair step.
Step c The user can barely reach the stair step.
Step d The designed keeps climbing on the stair
but after the 3 first footsteps he/she is feels too
tired and cannot reach the next stair step.
report.
Scenario 3.1.b.1.2:
Step 5 The user executes the simulation of the climbing
on a ramp task.
Step a- The user is moving towards the destination
and needs to climb on a ramp to reach it.
Step b The user tries to climb on the ramp but it
is not possible due to the inclination.
report.
Scenario 3.1.b.1.3:


Step 5 The user executes the simulation of the going
through a door task.
Step a- The user wants to get through a door on
the wheelchair but he/she does not fit from the
door pass.
report.

UCs UC 3.1.a
Background Interior design and its accessibility is fundamental to guarantee excellent

info/ reason life conditions for disabled and elderly people, since the physical barriers
on selection and barriers due to inaccessible technology often hinder these people
and on during their private life. The accessibility has to be involved from the
assigning beginning of the design phase, since a good numbers of possible
the priority obstacles may be easily removed with no great impacts on the whole
level project.
References
5.3.2 Domotics
Category 3.a: Smart Category 3.b: Smart living

living places design places simulation
UC 3.2.a: Domotics desktop UC 3.2.b: Domotics immersive
5.3.2.1 Domotics desktop simulation

Use Case No UC 3.2.a
Use Case Domotics desktop simulation
Title
Brief The user realises a desktop simulation of the domotics application design
description in order create an accessible design.
(user goal
satisfied)
Spaces
Relevant WP

Scenario Scenario 3.2.a.1 Dishwasher door opening (and closing)

Scenario 3.2.a.1.1
The dishwasher door in a proper high for a typical beneficiary to
open (and close) it.
Scenario 3.2.a.1.2
The dishwasher door in to high for a beneficiary with lower limp
impairments, on a wheelchair to open (and close).
Scenario 3.2.a.2 Fridge door opening (and closing)

Scenario 3.2.a 2.1
The fridge door has the proper weight for a typical beneficiary to
open (and close) it.
Scenario 3.2.a.2.2
The fridge door is too heavy a beneficiary with upper limb
impairments to open (and close) it.
Scenario 3.2.a.3 Oven programming and starting

Scenario 3.2.a.3.1
The oven program is accessible for a typical beneficiary to start it.
Scenario 3.2.a.3.2
The oven program is not accessible for a blind or visually
impaired beneficiary to start it.
Scenario 3.2.a.4 Dishwasher loading (and unloading)

Scenario 3.2.a.4.1
The dishwasher has the proper weight for a typical beneficiary to
load (and unload) it.
Scenario 3.2.a.4.2
The dishwasher is too heavy a beneficiary with upper limb
impairments to load (and unload) it.
Scenario 3.2.a.5 Washing machine loading (and unloading)

Scenario 3.2.a.5.1
The washing machine has the proper weight for a typical
beneficiary to load (and unload) it.
Scenario 3.2.a.5.2
The washing machine is too heavy a beneficiary with upper limb
impairments to load (and unload) it.
Primary Designer
Actor(s)

Scenario 1.1.3
Use Case:1.2
Scenario 3.2.a.1 Dishwasher door opening (and closing)
Scenario 3.2.a.1.1
Scenario 3.2.a.1.2
User model with lower limb impairments on a wheelchair

Scenario 3.2.a.2.1


Scenario 3.2.a.2.2
User model with upper limb impairments on a wheelchair

Scenario 3.2.a.3.1
Scenario 3.2.a.3.2
Blind user model or user model with visual impairments

Scenario 3.2.a.4.1
Scenario 3.2.a.4.2
Elderly user model or user model with upper limb movement
limitations

Scenario 3.2.a.5.1
Scenario 3.2.a.5.2
Elderly user model or user model with upper/lower limb
movement limitations
System Scenario 3.2.a.1-5
Interaction Scenario 3.2.a.1 Dishwasher door opening (and closing)
steps Scenario 3.2.a.1.1
in Step 1.
Step 5 The user runs the simulation of the dishwasher
door opening (or closing) task.
Step 6 The system simulates the dishwasher door
opening (or closing) task.
embedded in ISE or VRfx interface.
report.
Scenario 3.2.a.1.2
Step 2 The system extracts a user model with lower limb
impairments on a wheelchair according to the parameters


report

Scenario 3.2.a.2.1
in Step 1.
Step 5 The user runs the simulation of the fridge door
Step 6 The system simulates the fridge door opening (or
closing) task.
report.
Scenario 3.2.a.2.2
closing) task.
report
Scenario 3.2.a.3.1
in Step 1.
Step 5 The user runs the simulation of the oven
programming and starting task.
Step 6 The system simulates the oven programming

and starting task.

report.
Scenario 3.2.a.3.2
Step 2 The system extracts a blind user model or a user
model with visual impairments according to the
and starting task.
report.

Scenario 3.2.a.4.1
in Step 1.
loading (or unloading) task.
Step 6 The system simulates the dishwasher loading (or
unloading) task.
report.
Scenario 3.2.a.4.2
Step 2 The system extracts an elderly user model or a
user model with upper limb impairments according to the
unloading) task.
report.


Scenario 3.2.a.4.1
in Step 1.
Step 5 The user runs the simulation of the washing
machine loading (or unloading) task.
Step 6 The system simulates the washing machine
report.
Scenario 3.2.a.4.2
user model with upper/lower limb impairments according
to the parameters identified in Step 1.
report.

UCs UC 3.2.a
Background It is important to consider accessibility requirements for disabilities and

info/ reason elderly people in domotics in order to guarantee an efficient and
on selection satisfactory daily use of household appliances as dishwasher, fridge,
and on oven, washing machine.
assigning In particular dishwasher and fridge door physical handling is a primary
the priority necessary action for the use of the appliance.
level Dishwasher and washing machine accessibility is necessary for loading
and unloading tasks.
The selection of oven program and its starting is a crucial action for the
use of this appliance.
References

5.3.2.2 Domotics immersive simulation

Use Case No UC 3.2.b
Use Case Domotics immersive simulation
Title
Brief The user realises an immersive simulation to create an accessible
description design of the domotics application, i.e. household appliance (e.g.
(user goal washing machine or oven) for specific types of users with disabilities.
satisfied)
Spaces HealthCare
Relevant WP
Scenario Scenario 3.2.b.1 Dishwasher door opening (and closing)

Scenario 3.2.b.1.1
The beneficiary can open (and close) the dishwasher door.
Scenario 3.2.b.1.2
A beneficiary with lower limb impairments on a wheelchair cant
open (and close) the dishwasher door.
Scenario 3.2.b.2 Fridge door opening (and closing)
Scenario 3.2.b.2.1
The beneficiary can open (and close) the fridge door.
Scenario 3.2.b.2.2
A beneficiary with lower limb impairments on a wheelchair cant
open (and close) the fridge door.
Scenario 3.2.b.3 Oven programming and starting
Scenario 3.2.b.3.1
The beneficiary can select the oven program and start it.
Scenario 3.2.b.3.2
A blind beneficiary or a beneficiary with visual impairments cant
select the oven program and start it.
Scenario 3.2.b.4 Dishwasher loading (and unloading)
Scenario 3.2.b.4.1
The beneficiary can load (and unload) the dishwasher.
Scenario 3.2.b.4.2
Elderly or user with upper limb movement limitations cant load
(and unload) the dishwasher.
Scenario 3.2.b.5 Washing machine loading (and unloading)
Scenario 3.2.b.5.1
The beneficiary can load (and unload) the washing machine.
Scenario 3.2.b.5.2
Elderly or user with upper/lower limb movement limitations cant
load (and unload) the washing machine.
Primary Designer
Actor(s)


Scenario 1.1.3
Use Case:1.2
Scenario 3.2.b.1 Dishwasher door opening (and closing)
Scenario 3.2.b.1.1
Scenario 3.2.b.1.2
Scenario 3.2.b.2.1
Scenario 3.2.b.2.2
Scenario 3.2.b.3.1
Scenario 3.2.b.3.2
Blind user model or user model with visual impairments.
Scenario 3.2.b.4.1
User with no specific limitations (typical).
Scenario 3.2.b.4.2
Elderly user or user with upper limb movement limitations.
Scenario 3.2.b.5.1
Scenario 3.2.b.5.2
Elderly user model or user model with upper/lower limb
movement limitations.
identifies possible difficulties and constraints in executing the planned
tasks. An EARL based report on the statistics, deviations from the
Interaction Scenario 3.2.b.1 Dishwasher door opening (and closing)

in Step 1.


door opening (or closing) task
Step a The user is near the dishwasher.
Step b The user moves his/her right (or left) hand
in order to grasp the door handle.
Step c The user grasps the door handle.
Step d The user pulls the door handle.
Step e The user releases his/her hand from the
door handle once the door is completely opened.
report.
Scenario 3.2.b.1.2
Step a The user is seating near the dishwasher.
Step c The user cannot reach the door handle.
Step d The user cannot pull the door handle.
report.

Scenario 3.2.b.2.1
in Step 1.
opening (or closing) task
Step a The user is near the fridge.
Step c The user grasps the door handle.
Step d The user pulls the door handle.
closing) task.


report.
Scenario 3.2.b.2.2
Step a The user is seating near the fridge.
Step c The user cannot reach the door handle.
Step d The user cannot pull the door handle.
closing) task.
report
Scenario 3.2.b.3.1
in Step 1.
Step a The user is in front of the oven
in order to grasp the oven programming knob.
Step c The user rotate the knob in order to select
oven temperature.
programming knob.
Step f The user moves his/her right (or left) hand
in order to grasp the oven timer knob.
Step g The user rotates the knob in order to
select warning time.
Step h The user releases his/her hand from the
timer knob.
and starting task.
report.
Scenario 3.2.b.3.2
Step 2 The system extracts a blind user model or a user
model with visual impairments according to the


Step a The user is in front the oven.
in order to grasp the oven programming knob.
Step c The user doesnt know if s/he grasped the
programming knob or the timer one.
Step h The user releases his/her hand from the
unknown knob.
and starting task.
report.

Scenario 3.2.b.4.1
in Step 1.
loading (or unloading) task
Step a The user is near the dishwasher.
Step b The user grasps the door handle.
Step c The user pulls the door handle.
Step d The user releases his/her hand from the
Step e The user put items in the dishwasher.
Step f The user grasps the dishwasher door.
Step g The user closes the dishwasher door.
unloading) task.
report.
Scenario 3.2.b.4.2
user model with upper limb impairments according to the
loading (or unloading) task
Step a The user is near the dishwasher
Step b The user grasps the door handle
Step c The user pulls the door handle
Step d The user cant completely open the door


unloading) task.
embedded in the ISE interface.
report.

Scenario 3.2.b.4.1
in Step 1.
Step a The user is in front of the washing
machine.
Step e The user put items in the washing
machine.
Step f The user grasps the washing machine
door.
Step g The user closes the washing machine
door.
report.
Scenario 3.2.b.4.2
user model with upper/lower limb impairments according
Step a The user is near the washing machine.
Step e The user cant put items in the washing
machine.
embedded in the ISE interface.


report.

UCs UC 3.2.b
Background It is important to consider accessibility requirements for disabilities and

info/ reason elderly people in domotics in order to guarantee an efficient and
on selection satisfactory use of system and machines (e.g. household appliances) to
and on every type of users. In particular, command reachability, physical parts
assigning handling and user-interface usability have to be considered as a
the priority significant factors that could impact on accessibility and could affect
level machine usage for disable users.
References

5.4 Workspaces
Category 4.a: Workspaces desktop Category 4.b: Workspaces

simulation immersive simulation
UC 4.1.a: Workplace design accessibility
desktop simulation. UC 4.1.b: Workplace design
UC 4.2.a: Collaborative tools accessibility immersive simulation.
desktop simulation.
5.4.1 Workplace design

Category 4.b:
Category 4.a: Workspaces
Workspaces
UC 4.1.a: Workplace design UC 4.1.b: Workplace design
accessibility desktop simulation. immersive simulation.
5.4.1.1 Workplace design desktop simulation
Use Case 4.1.a

No
Use Case Workplace design accessibility using desktop simulation.
Title
Brief The user realises a desktop simulation in order to create an accessible
description workplace design for beneficiaries with various types of disabilities and
(user goal elderly.
satisfied)
Spaces
Relevant 2.4, 3.3
WP
Scenario Scenario 4.1.a.1: Office accessibility.
The user wants to design an accessible pathway from the entrance of
the workspace to the main working room.
Scenario 4.1 a.1.1
The pathway from the entrance of the workspace to the main
working room is accessible by the beneficiary.
Scenario 4.1 a.1.2
working room is not accessible by a blind beneficiary.
Scenario 4.1.a.2: Printer and closet accessibility.

The user wants put the printer and the closets at an accessible
location.
Scenario 4.1 a.2.1
The location of the printer and the closets is accessible by the
beneficiary.
Scenario 4.1 a.2.2
The location of the printer and the closets is not accessible by a

Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 4.1.a.1: Office accessibility.
Scenario 4.1 a.1.1
Scenario 4.1 a.1.2
Blind user model.
Scenario 4.1 a.2.1
Scenario 4.1 a.2.2
Use Case:1.3
Scenario 1.3.1
System Scenario 4.1 a.1-2:
Interaction Scenario 4.1.a.1: Office accessibility.
steps Scenario 4.1 a.1.1
in Step 1.
Step 5 The user runs the simulation of the walking on
the pathway, from the entrance of the workspace to the
main working room, task.
Step 6 The system simulates of the walking on the
pathway from the entrance of the workspace to the main
working room task.
embedded in AutoCAD interface.
report.
Scenario 4.1 a.1.2
Step 2 The system extracts a blind user model
Step 5 The user runs the simulation of the pathway

from the entrance of the workspace to the main working

room task.
Step 6 The system simulates of the pathway from the
entrance of the workspace to the main working room
task.
report.

Scenario 4.1.a.2.1
in Step 1.
Step 5 The user runs the simulation of using the
printer and then reaching the closet task.
Step 6 The system simulates the task of using the
printer and then reaching the closet.
report.
Scenario 4.1.a.2.2
limb limitations on a wheelchair according to the
Step 6 The system simulates the task of using the
printer and then reaching the closet.
report.
Connected Output to UC 4.2, UC 5.1 and UC 5.2
UCs
Background Workplace accessibility is fundamental for the successful integration of

info/ reason disabled and elderly people in the working environment, since the
on selection physical barriers and barriers due to inaccessible technology often
and on hinder these peoples integration into the workforce. Even people who
assigning are not disabled or elderly may suffer from musculoskeletal, vision and
the priority other problems due to a bad design. The accessibility has to be
level assessed from the design phase, since some obstacles may not be
easily removed after the actual construction of the workplace.

References Mueller, J. (2001). "Office and Workplace Design". In W.F.E.Preiser

and E. Ostroff, (Eds.) Universal Design Handbook. McGraw-Hill, New
York.
Review of accommodation strategies in the workplace for persons with
mobility and dexterity impairments: Application to criteria for universal
design. In Journal Technology and Disability, Publisher IOS Press
ISSN 1055-4181, Issue Volume 19, Number 4 / 2007
5.4.1.2 Workplace design immersive simulation
Use Case UC 4.1.b

No
Use Case Workplace design immersive simulation.
Title
Brief The user realises an immersive simulation in order to create an
description accessible workplace design for beneficiaries with various types of
(user goal disabilities and elderly.
satisfied)
Spaces
Relevant 2.4, 3.3
WP
Scenario Scenario 4.1.b.1: Office accessibility.
The user wants to assess the accessibility of the pathway from the
entrance of the workspace to the main working room.
Scenario 4.1.b.1.1
working room is accessible by the beneficiary.
Scenario 4.1.b.1.2
working room is not accessible by a blind beneficiary.
Scenario 4.1.b.2: Printer and closet accessibility.

The user assesses the accessibility of the location of the printer and the
closets.
Scenario 4.1.b.2.1
The location of the printer and the closets is accessible by the
beneficiary.
Scenario 4.1.b.2.2
The location of the printer and the closets is not accessible by a
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 4.1 a.1.1

Scenario 4.1 a.1.2

Blind user model.
Scenario 4.1 a.2.1
Scenario 4.1 a.2.2
Use Case:1.4
Scenario 1.4.1
System Scenario 4.1 b.1-2
Interaction Scenario 4.1.b.1: Office accessibility.
in Step 1.
Step 5 The user executes the simulation of the walking
on the pathway, from the entrance of the workspace to
the main working room, task.
Step a The user enters the main entrance of
the office.
Step b The user enters the lift.
Step c The user pusses the button of the 2nd
floor.
Step d The user exits the lift.
Step e The user walks through a corridor.
Step f The user enters the door of the room.
Step k The user walks to the office seat.
Step l The user sits and turns on the PC.
report.
Scenario 4.1.b.1.2
Step 2 The system extracts a blind user model
Step a The user enters the main entrance of
the office.
Step b The user uses the lift.
Step c The user walks through a corridor.

Step b The user enters the lift.

Step c The user pusses the button of the 2nd
floor.
Step d The user cannot find the right button.
report.

Scenario 4.1.b.2.1
in Step 1.
Step 5 The user executes the simulation of using the
Step a The user sends a document for printing.
Step b There is a message that the printer is
out of paper.
Step c The user goes to the paper storage area
and gets paper, which it feeds in the printing tray.
Step d The document is printed.
Step e The user gets a dossier from the upper
shelf of a closet.
Step f - The user gets the printed document from
the printer and classifies it in the dossier.
Step g The user stores the dossier in the same
shelf.
report.
Scenario 4.1.b.2.2
limb limitations seating on a wheelchair, according to the
Step 5 The user executes the simulation of using the
Step a The user sends a document for printing.
Step b There is a message that the printer is
out of paper.
Step c The user goes to the paper storage area
to get paper.
Step d The user cannot reach the paper
storage area to get paper because it is too high.


report.
Connected Output to UC 4.2, UC 5.1 and UC 5.2
UCs
Background Workplace accessibility is fundamental for the successful integration of

info/ reason disabled and elderly people in the working environment, since the
on selection physical barriers and barriers due to inaccessible technology often
and on hinder these peoples integration into the workforce. Even people who
assigning are not disabled or elderly may suffer from musculoskeletal, vision and
the priority other problems due to a bad design. The accessibility has to be
level assessed from the design phase, since some obstacles may not be
easily removed after the actual construction of the workplace.
References Mueller, J. (2001). "Office and Workplace Design". In W.F.E.Preiser and
E. Ostroff, (Eds.) Universal Design Handbook. McGraw-Hill, New York.
Review of accommodation strategies in the workplace for persons with
mobility and dexterity impairments: Application to criteria for universal
design. In Journal Technology and Disability, Publisher IOS Press ISSN
1055-4181, Issue Volume 19, Number 4 / 2007
5.4.2 Collaborative tools

Category 4: Workspaces
UC 4.2: Collaborative tools accessibility simulation.
5.4.2.1 Collaborative tools desktop simulation
Use Case 4.2.a

No
Use Case Collaborative tools accessibility desktop simulation.
Title
Brief The user realises a desktop simulation in order to create accessible
description design for the collaborative tools, for beneficiaries with various types of
(user goal disabilities and elderly.
satisfied)
Spaces
Relevant 2.4, 3.3
WP
Scenario Scenario 4.2.a 1: Accessibility of distance collaborative working
tool.
The user assesses the accessibility of a distance collaborative working
tool.
Scenario 4.2.a.1.1
Uploading a file and selecting a document for online editing.
The design of the tools is accessible by the beneficiary.
The design of the tools is not accessible for an elderly
beneficiary.

Scenario 4.2.a.1.2
Creating a new discussion and posting an item.
The design of the tools is accessible by the beneficiary.
beneficiary with cognitive impairments.
Scenario 4.2.a. 2: Accessibility of teleconferencing tool

The user uses a teleconference tool to realise a teleconference.
The design of the teleconferencing tool is accessible by
the beneficiary.
beneficiary with hearing impairments.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 4.2.a 1: Accessibility of distance collaborative working
tool.
Scenario 4.2.a.1.1
Elderly user model.
Scenario 4.2.a.1.2
Elderly user model with cognitive limitations.
Elderly user model with hearing limitations.
Use Case:1.3
Scenario 1.3.1
System Scenario 4.2 a.1-2:

Interaction Scenario 4.2.a 1: Accessibility of distance collaborative working

steps tool.
Scenario 4.2.a.1.1 Uploading a file and selecting a document
for online editing.
in Step 1.
Step 5 The user runs the simulation of uploading a file
and selecting a document for online editing task.
Step 6 The system simulates uploading a file and
selecting a document for online editing task.
embedded in LOTUS DOMINO or VRDECO interface.
report.
Step 5 The user runs the simulation of the Uploading a
file and selecting a document for online editing task.
Step 6 The system simulates the Uploading a file and
selecting a document for online editing task.
report.
Scenario 4.2.a.1.2 Creating a new discussion and posting an

item.
in Step 1.
Step 5 The user runs the simulation of creating a new
discussion and posting an item task.
Step 6 The system simulates the creating a new
report.


cognitive limitations according to the parameters
Step 5 The user runs the simulation of creating a new
Step 6 The system simulates the creating a new
report.

in Step 1.
teleconference tool task.
Step 6 The system simulates the using the
report.
hearing limitations according to the parameters identified
in Step 1.
Step 6 The system simulates using the teleconference
tool task.
report.
Connected Input from UC 4.1, Output to UC 5.1 and UC 5.2

UCs
Background Internet based collaboration tools are constantly gaining the interest of
info/ reason workers all around the work, as they save time lost in travelling between

on selection meeting locations. Guidelines for web accessibility exist since long, but
and on they mainly focus on informatory sites and not on collaborative
assigning applications. Thus, this is an area which needs to be further surveyed.
the priority These tools have recently attracted the attention from the wide public,
level therefore this UC has been assigned a lower priority level.
References http://www.imsglobal.org/accessibility/accessiblevers/sec7.html
http://www.imsglobal.org/accessibility/accessiblevers/sec6.html
Web Content Accessibility Guidelines 1.0
Comments

5.5 Infotainment
Category 5.a: Infotainment

UC 5.1: Accessible metaversers simulation.
UC 5.2: Collaborative games for older people simulation.
5.5.1 Metaverses
Category 5.a: Infotainment

5.5.1.1 Metaverses desktop simulation
Use Case 5.1

No
Use Case Accessible metaverses desktop simulation
Title
Brief The user realises a desktop simulation of the metaverse UI and
description interaction methods in order to check several issues of accessibility, like
(user goal the ability to use input devices and to receive feedback from output
satisfied) devices as well as multimodal support for both. Several typical
scenarios are used to check accessibility. Models of people with various
types of disabilities and elderly are used.
Spaces
Relevant 2.4, 3.3
WP
Scenario Scenario 5.1.1: UI Design accessibility
The user wants to design accessible User Interface.
Scenario 5.1.1.1
The User Interface design is accessible for a beneficiary with no
limitation (typical).
Scenario 5.1.1.2
The User Interface design is not accessible for a beneficiary with
visual limitation.
Scenario 5.1.2: Application Control and Feedback

The user wants to design accessible application control and feedback.
Scenario 5.1.2.1
The application control and its feedback is accessible for a
beneficiary with no limitation (typical).
Scenario 5.1.2.2
The application control and its feedback is not accessible for an
elderly beneficiary with cognitive limitations.
Scenario 5.1.3: 3D Metaverse Environment Navigation

The user wants to design accessible navigation in a 3D Metaverse
environment.

Scenario 5.1.3.1
The navigation in a 3D Metaverse environment is accessible for
a beneficiary with no limitation (typical).
Scenario 5.1.3.2
The navigation in a 3D Metaverse environment is not accessible
for a beneficiary with upper limb limitations.
Scenario 5.1.4: Inter-user Interaction

The user wants to design accessible inter-user interaction.
Scenario 5.1.4.1
The inter-user interaction is accessible for a beneficiary with no
limitation (typical).
Scenario 5.1.4.2
The inter-user interaction is not accessible an elderly beneficiary
with cognitive limitations.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 5.1.1: UI Design accessibility
Scenario 5.1.1.1
Scenario 5.1.1.2
Scenario 5.1.2.1
Scenario 5.1.2.2
Scenario 5.1.3.1
Scenario 5.1.3.2
User model with upper limb limitations,
Scenario 5.1.4.1
Scenario 5.1.4.2
Use Case:1.3
Scenario 1.3.1
System Scenario 5.1.1-4:

output A number of adapted application screens and success criteria, provided
by the VERITAS Simulation Core Platform, based on the user model
selected and the simulation result, indicating if the interaction is
successful or not.

Interaction Scenario 5.1.1: UI Design accessibility

steps Scenario 5.1.1.1
Step 2 The system extracts a user model with no specific
limitations according to the parameters identified in Step 1.
Step 3 The user loads a multiverse 3D environment.
Step 4 The system illustrates the multiverse 3D environment
and saves the task to be realised.
Step 5 The user runs the simulation of entering username and
password, entering the metaverse, accessing the Avatar
appearance menu, selecting specific Shapes for Body and Head
to customize the avatar, saving the avatar, accessing the
inventory screen, loading a new 3D object to the inventory and
closing the inventory screen.
Step 6 The system simulates the task of entering username
and password, entering the metaverse, accessing the Avatar
Step 7 - The system provides the simulation results embedded
in Second Life interface.
Step 8 - The system provides the user with an EARL report.
Scenario 5.1.1.2
Step 5 The user runs the simulation of entering username and
password, entering the metaverse, accessing the Avatar
Step 6 The system simulates the task of entering username
and password, entering the metaverse, accessing the Avatar

Scenario 5.1.2.1

Step 3 The user loads the metaverse application and logs on

to the metaverse server.
Step 4 The system illustrates the metaverse application and
saves the task to be realised.
Step 5 The user runs the simulation of accessing the in-world
menu, selecting Create from the menu, creating a new box,
scaling the box to 200% size, rotating the box 90 degrees on the
x,y and z axes and moving the box 1 meter right, up and
forward.
Step 6 The system simulates the task of accessing the in-
world menu, selecting Create from the menu, creating a new
box, scaling the box to 200% size, rotating the box 90 degrees
on the x,y and z axes and moving the box 1 meter right, up and
forward.
Scenario 5.1.2.2
cognitive limitations according to the parameters identified in
Step 1.
Step 3 The user loads the metaverse application and logs on
to the metaverse server.
Step 4 The system illustrates the metaverse application and
saves the task to be realised.
Step 5 The user runs the simulation of accessing the in-world
menu, selecting Create from the menu, creating a new box,
scaling the box to 200% size, rotating the box 90 degrees on the
x,y and z axes and moving the box 1 meter right, up and
forward.
Step 6 The system simulates the task of accessing the in-
world menu, selecting Create from the menu, creating a new
box, scaling the box to 200% size, rotating the box 90 degrees
on the x,y and z axes and moving the box 1 meter right, up and
forward.

Scenario 5.1.3.1
Step 5 The user runs the simulation of moving the avatar to a
specific visible location inside the 3D environment, moving the
avatar to a specific location where a positional sound comes
from, interacting with a dynamic 3D object e.g. a door to a
house in order to open it and interacting with a 3d object with
embedded media.
Step 6 The system simulates the task of moving the avatar to

a specific visible location inside the 3D environment, moving the

embedded media.
Scenario 5.1.3.2
Step 2 The system extracts a user model with upper limb
Step 5 The user runs the simulation of moving the avatar to a
specific visible location inside the 3D environment, moving the
embedded media.
Step 6 The system simulates the task of moving the avatar to
a specific visible location inside the 3D environment, moving the
embedded media.

Scenario 5.1.4.1
Step 5 The user runs the simulation of initiating chat with
another user inside the 3D environment using the modalities
available, using emotion animations provided by the multiverse
application using the modalities available and contenting with
the other user.
Step 6 The system simulates the of initiating chat with another
user inside the 3D environment using the modalities available,
using emotion animations provided by the multiverse application
using the modalities available and contenting with the other
user.
Scenario 5.1.4.2

cognitive limitations according to the parameters identified in

Step 1.
Step 5 The user runs the simulation of initiating chat with
another user inside the 3D environment using the modalities
available, using emotion animations provided by the multiverse
application using the modalities available and contenting with
the other user.
Step 6 The system simulates the of initiating chat with another
user inside the 3D environment using the modalities available,
using emotion animations provided by the multiverse application
using the modalities available and contenting with the other
user.
Connected
UCs 2.2, 3.1
Background Using metaverses as a communication, entertainment and educational

info/ reason tool has enabled people of all ages, abilities and backgrounds to forego
on selection their true identities, handicaps and discriminations posed to them in the
and on physical world, bringing a new sense of equality when they interact with
assigning other people online. To that end, metaverses like Second Life are an
the priority important tool to assess accessibility for diverse groups of people with
level different accessibility requirements. However, not being an essential,
everyday function like employment, mobility and health care relegates
this category to Secondary status.
References Antonacci, D., & Moderass, N. (2005, February 16). Second Life: The
educational possibilities of a massively multiplayer virtual world
(MMVW)
http://www.metaversejournal.com/2008/09/19/second-life-is-my-
wheelchair/
http://www.metaversehealth.com/category/featured/
Prisco, G. Future Evolution of Virtual Worlds as Communication
Environments, - Online Worlds: Convergence of the Real and the
Virtual, pp. 279-288, Springer, 2010
5.5.2 Collaborative games
UC 5.2: Collaborative games for older people

simulation.

5.5.2.1 Collaborative games desktop simulation
Use Case 5.2.

No
Use Case Collaborative games desktop simulation
Title
Brief The user of the VERITAS simulation platform wishes to perform a
description simulation of a specific game. To do so the system should provide the
(user goal means for selecting the target user population details (group,
satisfied) disabilities) loading the game design to the simulation platform and
conducting the simulation.
Spaces
Relevant 3.4
WP
Scenario Scenario 5.2.1: Game Location Accessibility
The user wants to design accessible physical place where the game is
displayed.
Scenario 5.2.2: Game Controls Accessibility
The user wants to design accessible game controls.
Scenario 5.2.3: Game Display Settings Accessibility
The user wants to design accessible game input/output.
Scenario 5.2.4: Multiplayer Mode Accessibility
The user wants to design accessible game for more than one player.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 5.2.1: Game Location Accessibility
Elderly user model.
Elderly user model.
Elderly user model.
Elderly user model.
Use Case:1.3
Scenario 1.3.1
System Scenario 5.2.1- 4:


Interaction Scenario 5.2.1: Game Location Accessibility

steps Step 1 The user executes UC 1.2.
Step 2 The system extracts an elderly user model according to
the parameters identified in Step 1.
Step 4 The system illustrates the simulation environment.
Step 5 The user requests the simulation of the task of getting
into a room, avoiding obstacles and taking a seat in front of the
game setup.
Step 6 The system simulates the task of getting into a room,
avoiding obstacles and taking a seat in front of the game setup.
Step 7 The system provides the simulation results embedded
in CAD or VRDECO interface.
Step 8 The system provides the user with an EARL report.

Step 5 The user requests the simulation of the task of
expanding the game controls and using them.
Step 6 The system simulates the task of expanding the game
controls and using them.
in the ICToys interface.

Step 5 The user requests the simulation of the task of
responding to the game feedback by making a new game move.
Step 6 The system simulates the task of getting into a room,
avoiding obstacles and taking a seat in front of the game setup.

Step 2 The system extracts two elderly user models according
Step 5 The user requests the simulation of the task scenarios
5.2.1, 5.2.2 and 5.2.3 for both the models in the same time.
Step 6 The system simulates the tasks for both the models.


UCs
Background This use case is important for allowing designers and developers to
info/ reason view whether their developed design performs smoothly on the
on selection simulation platform and therefore is ready for moving to the actual
and on design checking via the usage of VERITAS virtual user models.
assigning
the priority
level
References Charness, N., Schaie, C.W. (2003). Impact of Technology on

Successful Aging. Springer Publishing Company.
Czaja, SJ. (1996). Interface design for older adults. In Ozok AF. (Ed.).
Advances in a lied ergonomics, 262-265. Istanbul-West Lafayette:
USA Publishing.
Fisk, A.D., Rogers, W. A., Charness, N., Czaja, S. J. and Sharit, J.
(2004). Designing for older adults: Principles and Creative Human
Factors Approaches. CRC Press.
Hendrix, C.C., Sakauye, K.M. (2001). Teaching elderly individuals on
computer use. Journal of Gerontological Nursing, 27 (6), 47-56.

5.6 Health Care

UC 6.2: Mobile device for older users interaction with Personal Health
solutions simulation.
UC 6.3: Medical education and health coach application design
simulation.
5.6.1 Remote Patient Monitoring

5.6.1.1 Remote Patient monitoring desktop simulation
Use Case 6.1

No
Use Case Remote Patient Monitoring solutions desktop simulation.
Title
Brief The user wants to design accessible applications for Remote Patient
description Monitoring service for specific types of users with disabilities.
(user goal
satisfied)
Spaces
Relevant 2.6
WP
Scenario
Scenario 6.1.1: Wearing and removing the bodys sensors
The user wants to design accessible bodys sensors. More specifically,
if the patient can grasp the wearable sensor and put it on and then if the
sensor can be worn or not and if it is positioned properly on the body.
Scenario 6.1.1.1
The user can grasp the sensor and put on properly.
Scenario 6.1.1.2
The user can grasp the sensor but is not capable to handle and
put on properly.
Scenario 6.1.1.3
The user cannot grasp the sensor.
Scenario 6.1.2: Set-up of the Remote Monitoring System

The user wants to assess the accessibility of the instructions that are
show on the users personal screen.
Scenario 6.1.2.1

The simulator shows that the procedure can be followed and

completed.
Scenario 6.1.2.2
The simulator shows that the procedure cannot be executed by
the elderly user.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 6.1.1: Wearing and removing the bodys sensors
Scenario 6.1.1.1
Scenario 6.1.1.2
Elderly user model with slight cognitive limitations.
Scenario 6.1.1.3

Scenario 6.1.2.1
Scenario 6.1.2.2
User model with upper limb movement and visual limitations.
System
output Scenario 6.1.1:
An EARL report on the ease of handling of the sensors used by the
elderly user for the measurement of his/her physiological parameters
Scenario 6.1.2:
An EARL report on the accessibility of the Patient Remote Monitoring
solution in terms of set up procedure guided by the instructions
provided by the personal mobile device of the elderly user.
Interaction
steps Scenario 6.1.1: Wearing and removing the bodys sensors
Scenario 6.1.1.1
in Step 1.
Step 5 The user runs the simulation of wearing and
removing the bodys sensors task.
Step 6 The system simulates the task of wearing and
embedded in DGHome platform interface.


report.
Scenario 6.1.1.2
slight cognitive limitations according to the parameters
report.
Scenario 6.1.1.3
Step 1.
embedded in the DGHome platform interface.
report.

Scenario 6.1.2.1
Step 1.
Step 5 The user runs the simulation of understanding
and following the instructions that are show on the users
personal screen task.
Step 6 The system simulates understanding and
following the instructions that are show on the users
report.

Scenario 6.1.2.2
Step 2 The system extracts a user model upper limb
movement and visual limitations according to the
Step 5 The user runs the simulation of understanding
and following the instructions that are show on the users
Step 6 The system simulates the of understanding and
following the instructions that are show on the users
report.
Figure 11: Body sensors

Connected UC6.1.b, UC6.1.c; UC6.2.a, UC6.2.b, UC6.2.c
UCs
Background This use case has been considered as primary since remote patient
info/ reason monitoring represents an effective approach for a change in healthcare
on selection from treatment to prevention.
and on The acceptance by the patients is of primary importance for the
assigning adherence to the monitoring program; therefore it is of high priority to
the priority design solutions enhancing the unobtrusiveness, the accessibility and
level the ease of use of the proposed solutions.
References -
5.6.2 Mobile device solution simulation
Category 6.a: Health Care


5.6.2.1 Mobile device solution simulation
Use Case 6.2

No
Use Case Mobile device for older users interaction with Personal Health solutions
Title simulation.
Brief The user wants to design a accessible mobile device (or a tablet PC) to
description be used by people with specific types of disabilities to interact with their
(user goal Personal Health system.
satisfied)
Spaces HealthCare
Relevant 2.6
WP
Scenario
Scenario 6.2.1: Handling the device
The user wants to assess the accessibility of grasping the device and
being able to handle it.
Scenario 6.2.1.1
The user can grasp and handle his/her mobile device.
Scenario 6.2.1.2
Scenario 6.2.1.2.1
User can grasp the device but he is not capable to handle
It.
Scenario 6.2.1.2.2
User is unable to grasp the mobile device.
Scenario 6.2.2: Interaction with the touch screen

The user wants to assess the accessibility of the interaction between
the beneficiary and the mobile device by using its Graphic User
Interfaces and by touching the screen with a finger and/or a stylus pen.
Scenario 6.2.2.1
The interaction through the touch screen is accessible for the
user.
Scenario 6.2.2.1
The user cannot interact with the device.
Scenario 6.2.2.1.1
User can see and understand the icons and the menu
visualized on the screen but his/her fingers do not have
enough force to touch and press the screen.
Scenario 6.2.2.1.2
User is unable to view the various items of the menu on the
screen.
Scenario 6.2.3: Interaction with the voice (input and/or output

interface)
The user wants to assess the accessibility of the interaction between
the beneficiary and the mobile device by using the voice as input
interface (voice control) and to have the texts on the screen read by a
voice (vocal output through a text-to-speech system) .
Scenario 6.2.3.1
The voice control is accessible for the user
Scenario 6.2.3.2

The user cannot interact with the voice

Scenario 6.2.3.2.1
User has speech problems and cannot give a vocal
command
Scenario 6.2.3.2.2
User has hearing problems
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 6.2.1: Handling the device
Scenario 6.2.1.1
Scenario 6.2.1.2
Scenario 6.2.1.2.1
Scenario 6.2.1.2.2
User model with upper limb limitations
Scenario 6.2.2: Interaction with the touch screen
Scenario 6.2.2.1
Scenario 6.2.2.1
Scenario 6.2.2.1.1
Elderly user model with Parkinson disease.
Scenario 6.2.2.1.2
User model with visual limitations
Scenario 6.2.3: interaction with the voice (input and/or output

interface)
Scenario 6.2.3.1
Scenario 6.2.3.2
Scenario 6.2.3.2.1
User model with speech limitations.
Scenario 6.2.3.2.2
Use Case:1.3
Scenario 1.3.1
Interaction Scenario 6.2.2: Interaction with the touch screen
steps Scenario 6.2.2.1


in Step 1.
Step 5 The user runs the simulation of grasping and
handling the mobile device.
Step 6 The system simulates the grasping and
handling the mobile device task.
report.
Scenario 6.2.2.1
Scenario 6.2.2.1.1
Step 2 The system extracts an elderly user with
report.
Scenario 6.2.2.1.2
Step 1.
report.
Scenario 6.2.3: Interaction with the voice (input and/or output

interface)
Scenario 6.2.3.1


Step 5 The user runs the simulation of the task for
interaction with the device with the voice.
Step 6 The system simulates the task for interaction
with the device with the voice.
report.
Scenario 6.2.3.2
Scenario 6.2.3.2.1
speech limitations according to the parameters identified
in Step 1.
report.
Scenario 6.2.3.2.2
hearing limitations according to the parameters identified
in Step 1.
report.
Connected UC6.2.b, UC6.2.c

UCs
Background This use case has been considered as primary due to the importance of
info/ reason the accessibility of the personal device of the elderly as main interface
on selection to interact with the ICT world and its applications including the Personal
and on Health System.
assigning
the priority
level
References

5.6.3 Medical education and health coach

UC 6.3: Medical education and health coach application
simulation.
Figure 12: Health care coaching application standard use cases.
5.6.3.1 Medical education and health coach desktop simulation
Use Case 6. 3
No
Use Case Medical Education and health coach application.
Title
Brief The user wants to design an accessible Health Coach application with
description particular Contact Caregiver functionalities, for elderly people.
(user goal
satisfied)
Spaces
Relevant 2.6
WP
Scenario
Scenario 6.3.1: Exchanging messages with the doctor

The user wants to assess the accessibility of the coaching application.

The specific aim is to validate the accessibility of the user interface to
contact the doctor through e-mail and to receive back a message from
him/her.
Scenario 6.3.1.1
The user is able to exchange messages with his/her doctor.
Scenario 6.3.1.2
The user does not have enough force to write the message by
using the virtual keyboard of his/her touch screen device.
Scenario 6.3.1.3
The user is unable to read the keys of his/her keyboard and to
write the message.
Scenario 6.3.2: Searching for medical news

The user wants to assess the accessibility of searching in the Health
Coach application for information on a new therapy.
Scenario 6.3.2.1
The user is able to search and read the news.
Scenario 6.3.2.2
The user cannot use the application.
Scenario 6.3.2.3
User is unable to write the searching keyword.
Scenario 6.3.2.4
The searched information is retrieved but the user is unable to
read the visualized text.
Scenario 6.3.3: Giving warnings to the user

The user wants to assess the accessibility of the Health Coach service
suggestions to the beneficiary.
Scenario 6.3.3.1
The warning is received and well understood.
Scenario 6.3.3.2
Scenario 6.3.3.2.1
User cannot hear the audio signal informing about the
receipt of the message.
Scenario 6.3.3.2.2
User cannot read the text of the warning message.
Primary Designer
Actor(s)
level
Use Case:1.2
Scenario 6.3.1: Exchanging messages with the doctor
Scenario 6.3.1.1
Scenario 6.3.1.2
User with upper limb movement limitations.
Scenario 6.3.1.3
User with visual limitations.

Scenario 6.3.2.1
Scenario 6.3.2.2
User with cognitive limitations.
Scenario 6.3.2.3
User with upper limb movement limitations.
Scenario 6.3.2.4

Scenario 6.3.3.1
Scenario 6.3.3.2
Scenario 6.3.3.2.1
User with hearing limitations.
Scenario 6.3.3.2.2
Use Case:1.3
Scenario 1.3.1

Interaction
steps Scenario 6.3.1: Exchanging messages with the doctor
Scenario 6.3.1.1
in Step 1.
Step 5 The user runs the simulation of the exchanging
messages with the doctor task.
Step 6 The system simulates the exchanging
report.
Scenario 6.3.1.2


report.
Scenario 6.3.1.3
1.
report.

Scenario 6.3.2.1
in Step 1.
Step 5 The user runs the simulation of searching for
medical news.
Step 6 The system simulates searching for medical
news task.
report.
Scenario 6.3.2.2
Step 2 The system extracts a user model with
medical news.
news task.


report.
Scenario 6.3.2.3
medical news.
news task.
report.
Scenario 6.3.2.4
visual limitations according to the parameters identified
in Step 1.
medical news.
news task.
report.

Scenario 6.3.3.1
in Step 1.
Step 5 The user runs the simulation of hearing and
understanding the guidance of the Health Coach.
news task.
report.
Scenario 6.3.3.2


1.
news task.
report.
Scenario 6.3.3.2.1
1.
news task.
report.
Connected UC6.2 and UC 6.3.b and UC6.3.c
UCs
Background This use case has been considered as primary since a prevention
info/ reason strategy in healthcare is highly linked to a program of medical
on selection education and adherence to healthier lifestyles.
and on
assigning
the priority
level
References N/A

6 Use Cases Prioritisation

The prioritisation of the Use Cases is an important procedure in the extraction of
the final detailed Use Cases. As a matter of fact, the Use Cases titles, which are
presented in the current document, are the ones resulting from multiple iterative
internal prioritisations, as well as, from external prioritisation from users and
beneficiaries out of the project.
The Use Cases have initially received a priority level from the technical partners
of the Consortium, who have also identified the critical scenarios. Also, the
Users & Stakeholders needs have pinpointed the most important Use Cases in
an indirect but critical manner. Finally, the last prioritisation phase was realised
during the First Pan-European Workshop and User Forum meeting of
VERITAS, where various experts and beneficiaries were informed about the
project and shared their opinion on the Use Cases with each other and with the
Consortium.
6.1 VERITAS User Forum and Workshop

The 1st VERITAS Pan-European Users and Beneficiaries Forum and the 1 st
Pan-European Workshop of VERITAS took place on the 29 th and 30th of
November 2010 at the Faculty of Electrical Engineering, Czech Technical
University, in Prague, Czech Republic.
The aim of the 1st Pan-European Workshop and User Forum meeting was to
gather stakeholders, experts and users, in order to inform them about the
project concept and objectives, to disseminate the project preliminary findings
and finally introduce and prioritise the projects Use Cases. In more detail the
objectives of the Workshop and User Forum meeting were the following:
To disseminate the aim, objectives and targeted developments of
VERITAS to the experts and the users.
To provide early information on project developments and retrieve
stakeholders feedback.
To trigger stakeholders interest in order to be actively involved in the
project progress and developments throughout its duration.
To discuss the preliminary Use Cases of the project and get the
stakeholders opinion and prioritise the Use Cases.
In the User Forum, 41 designer and developers, as well as people with

disabilities and older people that will be the main users and beneficiaries of the
VERITAS system were invited and participated. The agenda of the Use Forum
is attached in the Annex 2 of the current document.

st
Figure 13: Shot of the 1 Pan-European User Forum of VERITAS.
In the Workshop, there were 49 participants (7 represented the beneficiaries

and 42 were designer and developers) specialised in accessibility. The agenda
of the Workshop is attached in the Annex 3 of the current document.
Details on the two events have been noted in the minutes, available on the
project website (www.veritas-project.eu).
6.2 Methodology
In order for the participants to understand and prioritise the Use Cases of the
project, the meeting was divided in two main parts:
Part 1: Presentation of the project and the Use Cases.
Part 2: Prioritisation of the Use Cases.
Part 1: Presentation of the project and the Use Cases.

It is a fact that the Use Cases of a project, with so many fields of interest and
also that much specialization, are various and complex. To this end, the
presentation of the Use Cases to the User Forum was very simple and easy to
follow from non experts to this field. The most important Use Cases were
presented, covering of course all the fields of the project and the presentation
consisted mostly of pictures rather than text.
Part 2: Prioritisation of the Use Cases.

Distribution of the Prioritisation Template. (Annex 4)
Filling in the template individually from the participants, with the
assistance of Consortium members.
Preliminary prioritisation of the Use Cases.
o The participants were asked to rate first all the Use Cases in order
to have the TOP priority ones, and then prioritise the scenarios

within each Use Case, in order to have the TOP priority Scenarios
within each Use Case.
Discussion between the external participants about their 3 top rated
priority Use Cases.
Extrapolation of relevant results and summative outcomes.
During the individual prioritisation phase a template was used that is presented
in the Annex 4, of the current document. The completion of the template was
done individually, so the stakeholders would not be affected by each other. In
this way each stakeholder expressed his/her personal opinion about each Use
Case depending on their expertise and role.
Figure 14: Illustration of the methodology followed for the VERITAS Use Cases prioritisation.
6.3 Results
6.3.1 User Forum
The use Cases were prioritised form the experts and the stakeholders with a
mark from 1 to 3. 1 stands for the top priority Use Case and 3 for the less
important priority Use Case. After the completion of both phases of part 2 of the
meeting, the results were gathered and the top priorities Use Cases were
extracted.
The top ranked Use Cases, that received the most 1 marks, are the following
4:
Use Case 2.1
Car interior accessibility simulation.
Use Case 3.1
Smart living spaces interior design simulation.

Use Case 6.1

Remote patient monitoring solutions simulation.
The ranking of all the Use Cases is illustrated in the figure below.
35 UC 1.1
UC 1.2.a
30 UC 1.2.b

UC 2.1.a/b
Prioritisation 25
UC 2.2.a/b
Score

UC 2.3.a/b
20
UC 2.4.a/b

UC 3.1.a/b
15
UC 3.2.a/b

UC 4.1.a/b
10
UC 4.2.a/b

UC 5.1.a/b
5
UC 5.2.a/b

UC 6.1.a/b
0
UC 6.2.a/b
Use Cases
UC 6.3.a/b
Chart 1: Use Cases prioritisation, sum of priority grades.
The top priority Use Cases are also illustrated in the chart below that shows the
Use Cases with the most 1 priority marks. From the chart below it is obvious
that the participants of the Use Forum believe that the UC 3.1 for the smart
living spaces interior design simulation is the most important. This was also
apparent in their comments available at the Use Forum minutes.
16 UC 1.1
UC 1.2.a
14 UC 1.2.b

UC 2.1.a/b
Prioritisation
12

UC 2.2.a/b
Score

UC 2.3.a/b
10

UC 2.4.a/b
8
UC 3.1.a/b

UC 3.2.a/b
6
UC 4.1.a/b

UC 4.2.a/b
4
UC 5.1.a/b

UC 5.2.a/b
2

UC 6.1.a/b
0
UC 6.2.a/b
Use Cases
UC 6.3.a/b
Chart 2: Use Cases prioritisation, Use Cases with grade 1.
The charts that follow present the prioritisation of the scenarios within each Use
Case. The top priority scenarios are the ones with the lower summative score.

35
Scenario 1: Central rear
30 mirror tuning
Prioritisation 25
Scenario 2: Lateral mirror
Score 20 tuning
15
Scenario 3: Hand brake
10 activation/deactivation
5
Scenario 4: Gear changing
0
Use Case 2.1
Chart 3: Scenarios prioritisation, Use Cases 2.1.
35
Scenario 1: Riding
30 position.
Prioritisation 25
Score 20 Scenario 2: Usage on
15 bumpy roads (comfort
& safety).
10
5 Scenario 3: Central
stand.
0
Use Case 2.2
30,5
Scenario 1: On-board
30 navigation system
Prioritisation
programming
Score
29,5
29 Scenario 2: AUDIO
system programming
and tuning
28,5
Use Case 2.3
28 Scenario 1: Collision
Avoidance system
Prioritisation 27
(CAS)
Score
26 Scenario 2:
25 Navigation
Use Case 2.4

25
Scenario 1: In-
20
building navigation
Prioritisation
15 accessibility
Score
10
Scenario 2:
5 Appliances
0 accessibility
Use Case 3.2
30 Scenario 1: In office
25 navigation
accessibility
Prioritisation 20
Score Scenario 2: Printer
15 and closet
10 accessibility
5 Scenario 3: E-mail
software
0 accessibility.
Use Case 4.1
27 Scenario 1:
26 Accessibility of
distance
Prioritisation 25 collaborative
Score
24 working tool.
Scenario 2:
23
Accessibility of
22 teleconferencing
tool
21
Use Case 4.2
25
Scenario 1: UI Design
24
Prioritisation 23
Scenario 2: Accessibility of
Score
22 3D UI Elements
21 Scenario 3: 3D Metaverse
20 Environment Navigation
19 Scenario 4: Inter-user
Use Case 5.1
Interaction

30 Scenario 1: Game
25 Controls
Accessibility
Prioritisation 20 Scenario 2: Game
Score Display Settings
15
Accessibility
10 Scenario 3:
Multiplayer Mode
5
Accessibility
0
Use Case 5.2
22,5 Scenario 1:
Wearing and
22 removing the
Prioritisation
Score
bodys sensors
21,5 Scenario 2: Set-up
of the Remote
21 Monitoring
System
20,5
Use Case 6.1
28 Scenario 1:
27 Handling mobile
device
Prioritisation 26
Score 25 Scenario 2:
24 Interaction with the
touch screen
23
22 Scenario 3:
interaction with the
21
Use Case 6.2 voice (input and/or
output interface).

35 Scenario 1:
30 Exchanging
messages with the
Prioritisation 25
doctor
Score 20 Scenario 2:
15 Searching for
medical news
10
5 Scenario 3: Giving
0 warnings to the user
Use Case 6.3
For the top priority Use Cases and scenarios are the following:
Use Case 2.1: Car interior accessibility simulation.
Scenario 2.1.3: Handbrake activation/reactivation.
Use Case 3.1: Interior Design simulation.
Interior design simulation.
Use Case 6.1: Remote Patient Monitoring solutions simulation.
Set-up of the Remote Monitoring System.
6.3.2 Workshop
During the 1st Pan-European Workshop of VERITAS, the Use Cases were
prioritised by the experts with marks from 1 to 3, 1 for the top priority Use Case
and 3 for the less important priority Use Case. After the completion of both
phases of part 2 of the meeting, the results were gathered and the top priority
Use Cases were extracted.
The top ranked Use Cases are the ones that received the most 1 mark and
they are the following 3:
Use Case 2.1
Use Case 3.1
Interior Design simulation.
Use Case 6.1
Remote Patient Monitoring solutions simulation.
The ranking of all the Use Cases is illustrated at the figure below.

40 UC 1.1
UC 1.2.a
35 UC 1.2.b

UC 2.1.a/b
Prioritisation
30
UC 2.2.a/b
Score
25
UC 2.3.a/b

UC 2.4.a/b
20
UC 3.1.a/b

UC 3.2.a/b
15
UC 4.1.a/b
10
UC 4.2.a/b

UC 5.1.a/b
5
UC 5.2.a/b

UC 6.1.a/b
0
UC 6.2.a/b
Use Cases

UC 6.3.a/b
Chart 15: Use Cases prioritisation, sum of priority grades.
The top priority Use Cases are also illustrated in the chart below that shows the
Use Cases with the most 1 priority marks. From the chart below it is obvious
that the participants of the User Forum believe that the UC 3.1 for the smart
living spaces interior design simulation is the most important.
14 UC 1.1
UC 1.2.a
12 UC 1.2.b

UC 2.1.a/b
Prioritisation 10
UC 2.2.a/b
Score

UC 2.3.a/b
8
UC 2.4.a/b

UC 3.1.a/b
6
UC 3.2.a/b

UC 4.1.a/b
4
UC 4.2.a/b

UC 5.1.a/b
2
UC 5.2.a/b

UC 6.1.a/b
0
UC 6.2.a/b
Use Cases
UC 6.3.a/b
Chart 16: Use Cases prioritisation, Use Cases with grade 1.
The charts that follow present the prioritisation of the scenarios within each Use
Case. The top priority scenarios are the ones with the lower summative score.
40
Scenario 1: Central rear
mirror tuning
30
Prioritisation
Scenario 2: Lateral
Score
20 mirror tuning
10
activation/deactivation
0 Scenario 4: Gear
Use Case 2.1
changing

40
Scenario 1: Riding
39 position.
Prioritisation 38
Score Scenario 2: Usage on
37
bumpy roads
36 (comfort & safety).
35 Scenario 3: Central
stand.
34
Use Case 2.2
35
Scenario 1: On-
34
board navigation
Prioritisation 33 system
Score 32 programming
31
Scenario 2: AUDIO
30
system
29 programming and
28 tuning
Use Case 2.3
35 Scenario 1: Collision
Avoidance system
Prioritisation
30 (CAS)
Score
Scenario 2:
25 Navigation
Use Case 2.4
29
28 Scenario 1: In-
building navigation
Prioritisation 27 accessibility
Score
26
25
Scenario 2:
24 Appliances
accessibility
23
Use Case 3.2

50 Scenario 1: In office
navigation
40
accessibility
Prioritisation
Score 30 Scenario 2: Printer
and closet
20
accessibility
10 Scenario 3: E-mail
software
0 accessibility.
Use Case 4.1
34,5 Scenario 1:
34 Accessibility of
33,5 distance
Prioritisation
collaborative
Score 33
working tool.
32,5 Scenario 2:
32 Accessibility of
31,5 teleconferencing
tool
31
Use Case 4.2
40 Scenario 1: UI Design
30
Prioritisation Scenario 2: Accessibility of
Score 20 3D UI Elements
10 Scenario 3: 3D Metaverse
Environment Navigation
0
Use Case 5.1 Scenario 4: Inter-user
Interaction
42 Scenario 1: Game
Controls Accessibility
40
Prioritisation Scenario 2: Game
Score 38
Display Settings
36 Accessibility
Scenario 3:
34 Multiplayer Mode
Accessibility
32
Use Case 5.2

27,5 Scenario 1:
Wearing and
27 removing the
Prioritisation
bodys sensors
Score
26,5 Scenario 2: Set-up
of the Remote
26 Monitoring System
25,5
Use Case 6.1
27,5 Scenario 1: Handling

mobile device
27
Prioritisation
Score Scenario 2: Interaction
26,5 with the touch screen
26 Scenario 3: interaction
with the voice (input
25,5 and/or output
Use Case 6.2
interface).
40 Scenario 1: Exchanging
messages with the
30 doctor
Prioritisation Scenario 2: Searching
Score for medical news
20
Scenario 3: Giving
10 warnings to the user
0
Use Case 6.3
From the top priority Use Cases and priority scenarios are the following:
Use Case 2.1: Car interior accessibility simulation.
Scenario 2.1.1: Central rear mirror tuning.
Use Case 3.1: Interior Design simulation.
Use Case 6.1: Remote Patient Monitoring solutions simulation.
Set-up of the Remote Monitoring System.

6.3.3 Conclusions
The consensus on the results of the Workshop and the User Forum is obvious
from the above charts. The Use Cases that were pinpointed from this procedure
are the ones that will definitely be implemented at the pilot sites of VERITAS
and will be enriched in the Application scenarios that are described in detail in
Chapter 7 of the current Deliverable.
These Use Cases are:

Use Case 2.1
Use Case 3.1
Use Case 6.1
Remote patient monitoring solutions simulation.
Additionally, consensus among the two groups (Use Forum and Workshop) is
also apparent considering the lower ranked Use Cases, those ranked with most
3 marks. These are the following 3:
Use Case 2.2
Motorcycle handling accessibility desktop/immersive
simulation.
Use Case 2.3
ADAS/IVIS functionalities desktop/immersive simulation.
Use Case 2.4
ARAS/OBIS functionalities desktop/immersive simulation.
In the motorcycle domain, these results are quite self-explanatory, considering

the fact that there were no representatives from the motorcycle domain,
unfortunately neither at the Use Forum, nor at the Workshop. Additionally,
people tend to act discriminatively when the issue comes to people with
disabilities riding a motorcycle. Nevertheless, we should not forget that since an
individual enters the riders society he/she does not easily abandon this habit.
So, the riders of today are the young elderly riders of tomorrow. To this end,
designing an accessible motorcycle for the young elderly might not be a high
priority target of today, but it is an upcoming need of tomorrow, which could be
fulfilled even before it is generated.
Considering the ADAS/IVIS and ARAS/OBIS devices and systems, they are in a
very immature domain of automotive industry, according the market penetration,
the ITS domain. The beneficiaries, most of the times, are not familiar with these
terms, except from the navigation system. In the car domain, some ADAS and
IVIS already exist in the market, but with low penetration due to their innovation
and cost, i.e. Adaptive cruise control (ACC), Navigation, Collision avoidance
system (Pre-crash system), etc.). The same stands for the motorcycle ARAS
and OBIS domain, which has even lower penetration in the market and is a field
which is still under development. Nevertheless, omitting this application domain
from the accessible design, would lead to discrimination and to a new exclusion
of the elderly and disabled from emerging applications.

7 Application scenarios
On the basis of the aforementioned Use Cases, the final step of this Deliverable
is to develop some Application Scenarios that will contain a number of Use
Cases and will be presented in a more descriptive way, like narratives. Upon
these scenarios the pilot scenarios of WP 3.6 Iterative Pilots and Pilots
Planning, 3.7 Pilots for developers and 3.8 Pilots for end-users will be based
and they will also orient the evaluation activities of the project. The Application
Scenarios developed in the current document may be reformulated or enriched
in the context of D 3.6.1, D3.7.41 and D3.8.1, which will present the final pilot
plans, when the needs of the pilots will be more discrete and mature.
At the current stage of the project and the Use Cases development, we have
mainly developed Application Scenarios for the users of VERITAS, meaning
developers and designers. In the final version of the Use Cases, Deliverable
1.7.1.b, Application Scenarios for the beneficiaries will also be presented. The
Application Scenarios for the beneficiaries will, horizontally, go on all the
application domains and present how a disabled user goes through different
situations from the car to the home and office environment.
To this end, 5 major application scenarios have been developed for the users.
These Application Scenarios which are provided below, consist of sub-
scenarios, and include also the relevant user profile in each case.
Application Scenario 1
Connected Use Cases/Scenarios:

UC 2.1.a: Car interior accessibility desktop simulation.
Scenario 2.1.a.1: Central rear view mirror tuning
Scenario 2.1.a.2: Lateral mirror tuning
Scenario 2.1.a.3: Hand brake activation/deactivation
Scenario 2.1.a.4: Gear changing (manual/automatic)
UC 2.1.b: Car interior immersive simulation
Scenario 2.1.b.4: Gear changing (manual/automatic)
UC 2.3.a: ADAS/IVIS functionalities desktop simulation.
Scenario 2.3.a.1: On-board navigation system programming
UC 2.3.b: ADAS/IVIS functionalities immersive simulation.
Scenario 2.3.b.1: On-board navigation system programming

Combined usage:
User Profile 1: Paul has a company specialised in adjusting vehicles for use by
people with disabilities. His team has extensive expertise in this field; however
they still do depend heavily on personalisation case by case since every user
has a different set of needs. He therefore works together with driver
rehabilitation specialists who perform comprehensive evaluations to identify the
adaptive equipment most suited to the needs of the driver with disabilities.
User Profile 2: John is a designer of cars in an automotive company. John also
owns a car that has designed himself as well as, his parents. Johns father, who
is an elderly, started to lose his strength and is having difficulties in very basic
activities during driving. This has concerned John, who started thinking how to
embed accessibility issues in his design and making the cars accessible to all.
User Profile 3: Katia is a designer of ADAS and IVIS for an ITS company that
is developing the systems for the automotive company where John works.
Target beneficiaries groups:
Elderly beneficiaries
Beneficiaries with upper limb impairments
Beneficiaries with visual impairments
Beneficiaries with hearing impairments
Combined-sub-scenario 1:
Paul is having a very difficult time, especially these years of economic crisis, to
find and pay all these beneficiaries in order to get measurements to implement
in his models. The needs of the users are changing and in order to catch up, he
has to update his models constantly. In order to create and simulate his
designs, Paul is using CAD files in RAMSIS environment. As a RAMSIS
subscriber, he gets lots of information about the news in this market.
Specifically in the latest newsletter of RAMSIS, he read about an application-
add on to RAMSIS, which includes user models with disabilities and elderly.
Paul was excited, since he understood from the very beginning that this was
exactly what he was looking for. Paul downloaded VERITAS and opened
RAMSIS software. He loaded VERITAS user model file with upper limb
impairments by entering the specific parameters that he was asked for from the
application, loaded the task file/s for getting in and out of the car as well as
accessing the storage compartment, loaded VERITAS Simulation model file for
Automotive and finally he opened the CAD file with his design. Paul realised
that the model was corresponding perfectly in the environment and it was
executing the task like the real users he was doing pilots with all these years.
The black spots of his design were immediately identified from VERITAS and
presented to him during the simulation, as well as in an EARL report in the end.

Figure 15: Automotive simulation example of driving posture/position.
John and Paul know each other for many years, since they have studied
together in the University. Johns concern about integrating accessibility in the
car interior design guided him to call John, in order to get assistance for the
accessibility features of a car, and be introduced into the accessibility domain of
the automotive sector. Paul, who is already familiar with VERITAS,
recommended John to use this application, which would assist him in creating
accessible interiors and since he already uses both CAD and RAMSIS, it would
be a piece of cake to handled. After Pauls advice, John decided to try
assessing the accessibility of an old design he had done with VERITAS. Due to
his recent experience with his father, John was more interested to see how an
elderly, like his father, is experiencing some basic driving functionality, like the
tuning the central rear view mirror and lateral mirror, activating and deactivating
the hand brake and changing gears. To this end, John opened the RAMSIS
software, activated the VERITAS add-on in RAMSIS, loaded VERITAS elderly
user model file by entering the specific parameters that he was asked for from
the application, loaded the task file/s that he wanted his model to realise, loaded
VERITAS Simulation model file for Automotive and finally he opened the CAD
file with his design. As soon as John started the simulation, he couldnt believe
that the model was actually executing all the tasks he wanted to assess, exactly
like his father would, having the same difficulties and constraints. Every time the
user model had an issue with the task that was executing John was notified and
in the end the system also provided him with an EARL report. John had ready
started fixing his design and run the simulation again!

Figure 16: Automotive simulation example of handbrake release, gear changing and
looking at the right mirror.
While John was playing with VERITAS simulation assessing almost all his old
designs, Katia entered his office. When she saw VERITAS simulation she was
amazed and eager to try it on her own designs. Katia and John decided that
when he had the optimum design for his (meaning his target beneficiaries)
needs he would ask from Katia to embed the navigation system that she is
working on the last year. Two days later, Paul appeared, excited with the fact
that he was able to come to an optimum design so quickly and asked from Katia
to come to his office. The two of them embedded Katias design in Johns car in
a CAD file. Katia, in contradiction to John was more interested in seeing how
people with mild visual and hearing impairments would experience the system
she has designed. John liked that idea, because he had never considered these
user groups as his targets before. As the simulation was running, Katia realised
that although she had devoted so much time and effort to her design, many
accessibility issues were occurring during the simulation, which she could have
avoided if she had started using VERITAS from the beginning of the design
process.
Figure 17: Automotive simulation example of handbrake release, gear changing and
looking at the right mirror.
John proposed to Katia to try the immersive simulation, in order to understand

better the constraints of the beneficiaries. Katia agreed. After having the
permission of their administrator and being sure that they have all the
interaction tools they needed John and Katia were ready to try the immersive
simulation. First John wore all the interaction tools and wanted to act like an
elderly user with slight upper limb impairment. During the simulation he tried to

tune the central rear view mirror and lateral mirror, activate and deactivate the
hand brake and change gears. No accessibility barriers occur and he was very
proud of his design. Continuing, John wanted to try a more severe situation of
the upper limb and realised that some tasks were impossible for him to realise.
Then, Katia started another simulation as a user with slight hearing and visual
impairments. She tried to dial an address on the on-board navigation system
and to use the information displayed by the navigation system to reach a
destination. She understood that some audit information from the navigation
were not clearly perceived by her and that the system was out of the field of
vision for a person with a reduced peripheral field of vision.
Figure 18: Automotive immersive simulation example the driving task.
Application Scenario 2
Relevant Use Cases/Scenarios:
UC 2.2.a: Motorcycle handling accessibility desktop simulation.
UC 2.2.b: Motorcycle handling immersive simulation.
Scenario 2.2.b.1: Get on the vehicle
UC 2.4.a: ARAS/OBIS functionalities desktop simulation.
UC 2.4.b: ARAS/OBIS functionalities immersive simulation.
Scenario 2.4.b.1: Collision Avoidance system (CAS)

Combined usage:
User Profile 4: Mark is a motorcycle designer who works for a firm that
develops motorcycles for commercial use. He and his team have extensive
expertise in this field but they have recently received commends from their firm
administration about creating a motorcycle that better fits the needs of the
young elderly society. This target group is expanding more and more, but
unfortunately their needs and parameters are no yet included in the design
process. Mark, as well as his all team, are very worried about how to involve
these users characteristics in the design process.
User Profile 5: George is an ARAS and OBIS designer for motorcycles. He
works in the R&D department of Marks firm and he is a motorcycle rider. Due to
the fact that ARAS and OBIS are very new to the market he is interested in
embedding accessibility features in them, so as to be accessible from the
beginning, without the need to be properly adopted for young elderly and
disabled beneficiaries, later on.
Elderly
Beneficiaries with hearing imp impairments
Mark is very worried about how to embed the needs of the young elderly in the
design of the motorcycles. As a designer he has limited knowledge about the
needs, wants and abilities of the specific target group. So, he and his team have
started a thorough research about how they can achieve this target. During their
research they read about VERITAS system and find out that it can be easily
embedded in the programs and applications they already use for the design of
their products. In order to avoid the costly and time consuming method of
including users in their design process, they decided to try VERITAS, which
since it is open source it would not have sufficient cost to their firm. Mark
wanted to try this first and then share it with the rest of his team, so he
downloaded VERITAS and opened RAMSIS software. He loaded VERITAS
young elderly user model file and tried first to simulate the tasks that he
believes the most basic for a motorcycle rider. So, he decided to check the
accessibility of the riding position, as well as the accessibility of putting the
motorcycle on the central stand, for an old design of his. Mark loaded VERITAS
Simulation model file for Automotive and finally he opened the CAD file with his
old design. Mark saw that the simulation was of a very good quality, showing all
the constraints that the user model of the young elderly was facing while it was
executing the task. The simulation and its results were a very good start for
Mark and his team to start developing a new design of an accessible
motorcycle. The iterative evaluation of this design would lead them to the
optimum solution with the minimum cost.

Motorcycle Path and reference
Y Coordinate [m]
0
20
40
60
0 5 10 15 20 25 30
Time [s]
Steering torque [Nm]

50 Pphi
Dphi
Figure 19: Motorcycle simulation scenarios examples. 0

Pn
Dn
Ddelta
Dpsi
Steering Tau
Combined-sub-scenario 2: -50
0 5 10 15 20 25 30
Time [s]
As a motorcycle designer, but also a rider, Mark is very consistent about the safety
Roll Angle[deg] 50 Roll
Target
-Target+Roll
while designing a motorcycle, issue which rises also in the case of young elderly riders.
0
In order to understand the way the elderly riders handle the motorcycle while riding in
-50
risky situations he decide to simulate the riding on bumpy roads task with VERITAS.
0 5 10 15
Time [s]
20 25 30
Executing this simulation, Mark realised that this user group, lacking of strength, acts
differently than the typical riders in such conditions. To this end he decided that the
interaction of the rider with the motorcycle should be further studied by him and his
team, through a variation of designs which would be simulated with VERITAS.
In another office of the same building there was George, who had more or less the
same worries with Mark. As George was trying to create an accessible design for the
ARAS/OBIS devices, he considered that his design would be more efficient if he
collaborated with a motorcycle designer. This triggered him to go and visit Mark. When
George visited Marked and shared his thoughts with him, Mark was excited. Mark
presented VERITAS to George and enhanced him to work with his team in order to
embed ARAS/OBIS in the initial design of the motorcycle for the young elderly. George
agreed and a couple of weeks later they had an initial integrated design. George was
very interested in the Collision Avoidance System he has developed which is very
innovative and also in the Navigation system for motorcycles. With VERITAS George
had the opportunity to simulate how the user would interact with the CAS and the
navigation system, even if he was suffering from various slight disabilities.
Application Scenario 3 Smart living places & workplaces &

domotics & collaborative tools
UC 3.1.a: Interior Design desktop simulation.
Scenario 3.1.a.1: In-building navigation accessibility
UC 3.1.b: Interior Design immersive simulation.
Scenario 3.1.b.1: In-building navigation accessibility
UC 3.2.a: Domotics desktop simulation.
Scenario 3.2.a.1 Dishwasher door opening (and closing)


UC 3.2.b: Domotics immersive simulation.
Scenario 3.2.b.1 Dishwasher door opening (and closing)
UC 4.1.a: Workplace design accessibility desktop simulation.
UC 4.1.b: Workplace design immersive simulation.
Scenario 4.1.b.1: Office accessibility.
UC 4.2.a: Collaborative tools accessibility desktop simulation.
Scenario 4.2.a 1: Accessibility of distance collaborative working tool.
Combined usage:
User Profile 6: Robert is managing an architect office in downtown Brussels,
and is specialised in the design and architecture of public buildings. For this, he
also works together with a Belgian construction company that is specialized in
constructing accessible buildings. This year they asked him to design a
rehabilitation centre for tetraplegics and people with various upper and lower
limb disabilities. This is a challenge for Robert since is such a building the
accessible navigation is not enough, also accessible domotic application must
be installed and maybe rooms for socialisation inspired from the modern
workplaces.
User Profile 7: Margaret is a developer of tools for computer software designed
to help people involved in a common task achieve their goals (collaborative
tools). Margaret is working with Roberts design company to assist them in
integrating the potential of the intelligent workplace with the principle of Design
for All, and thus develop a new concept for workplace design - moving the
current mindset away from the "individual" thinking, that tends to alter basic
designs, towards including from the outset the maximum number of naturally
diverse human beings in the design and planning process.
Tetraplegic beneficiaries (wheelchair user)
Beneficiaries with lower limb impairments
Blind beneficiaries
Robert is used to design accessible building, as this is introduced from the
relevant legislation about all the building designs that have to be designed and
constructed fully accessible for all groups of citizens. While standard measures
and design concept are known to Robert, he is using VERITAS into the office
common practices for a year now. After several trials with VERITAS it proved
that errors in the design were drastically reduced and that potential bottlenecks
were highlighted even before blueprints were produced. The entire architecture

and design group makes use of AutoCAD. This programme has VERITAS
integrated, thus ensuring that the staff did not have to acquire new skills, but
could continue working with their familiar programs. Since applying VERITAS,
modifications afterwards hardly occurred. And if they did occur, then they were
relatively minor changes that did not touch the overall building concept. Another
benefit has been that the time from first rough design to final design has been
substantially smoothened and streamlined, while also shortened considerably.
In addition, it has given his office a good reputation, thus getting an increasing
number of contracts. Robert and his team have used VERITAS desktop and
immersive simulation many times in the past to simulate an elderly or a disabled
navigating in the building they have been designing.
Figure 20: Smart living spaces, interior simulation example of entering the kitchen
Additionally to his typical design, this time Robert had to design and assess the
accessibility of domestic applications like the dishwasher, the fridge, the oven
and the washing machine. To achieve this Robert had to collaborate with Anna,
who is a designer of white goods. Anna gave to Robert her designs so he could
embed them to his initial designs and assess their accessibility and usability
with various user groups. Robert run the simulation of the integrated design with
beneficiaries who are elderly, have upper limb impairments, lower limb and
visual impairments, executing task like opening the dishwasher door, opening
the fridge door, programming the oven, etc..

Figure 21: Smart living spaces, interior simulation example of using the kitchen.
Robert finally had to design some spaces for socializing, both in real time and
remotely. To this end, Robert designed one big space with desks, computers,
couches, printers, closets and storeroom for which he was inspired from the
design of buildings he had design for workspaces. Robert run the simulation of
the integrated design with beneficiaries who are elderly, have upper limb
impairments, lower limb and visual impairments.
Figure 22: Smart living spaces, interior simulation example of a workplace.
Margaret was asked from Robert to install some collaborative tools in the
rehabilitation centre he is designing, after its construction. Margaret was very
positive on this proposal but she decided that accessibility features should be
also embedded in her collaborative tools, in order to be accessible for the
elderly and disabled that would use them. To this end she used VERITAS
simulation in her designs in order to identify accessibility barriers. Margaret
thought the most useful tools that she could start with are the distance
collaborative working and the teleconference tool. Thus, Margaret would also
benefit since she would increase the target group of her company and she

would contribute in making the workplaces more innovative and more

accessible to all ages and abilities so that everyone can contribute at an equal
level.
During the design process Robert decided that it would be helpful for him and
his team to realise also immersive simulation of their design with VERITAS
project. To this end, Robert created an integrated design with all the
components that are needed for his scope, including the building design, the
workplace design and the domotics design. He thought that even if he did not
have a VR lab, constructing one and buying all the interaction tools he needed
for the simulation, would cost him less than including real users to test his
construction and even less if he had to implement changes to his design after
constructing it.
Figure 23: Smart living spaces interior, immersive simulation example of the
construction.
Application Scenario 4 Infotainment

UC 5.1.a: Accessible metaverses desktop simulation.
Scenario 5.1.1: UI Design accessibility
UC 5.2.a: Collaborative games for older people desktop simulation.
Scenario 5.2.1: Game Location Accessibility
Combined usage:
User Profile 8: Karen is a game developer specialised on developing games
mainly oriented to specific groups of people with disabilities. In a new project he
has been requested to develop a game that was visible and distinguishable
by visually and hearing impaired people, as well as for people with slight

cognitive impairments. Karens team has already undertaken a project about

collaborative games for elderly and they are looking for a way to develop the
optimum accessible design with the less cost and effort.
Elderly beneficiary
Beneficiaries with motor impairments
Beneficiaries with cognitive impairments
Karen and her team, in order to achieve the task for visible and
distinguishable game for visually and hearing impaired people, as well as for
people with slight cognitive impairments, she decided to embed VERITAS in the
design process, enabling her team of developers to have a good idea of how
their interfaces are perceived by the target user groups. After designing a first
prototype of the game, Karen run a simulation of it in the VERITAS simulation
platform to get a first glance on how the target users would perceive the UI
design, the application control and feedback and the 3D metaverse environment
navigation. After detecting design deficiencies Karen utilized the multimodal
interfaces manager to present the content in different forms better perceivable
by the users with disability and then test the game in the VERITAS simulation
platform with a set of virtual users that cover a wide range of the target user
groups. Using VERITAS, the team of developers only compiles a draft version
of the game when they have been able to address all issues identified by
VERITAS, and this for the different disability groups.
Figure 24: Infotainment simulation examples.
Karen has recently discovered VERITAS when she was asked to design a collaborative
game for elderly. When designing this game for elderly she also had to check the
physical disabilities of elderly in controlling the game. So, Karen simulated the
accessibility of the game controls, the game display settings and the multiplayer mode.

Figure 25: Elderly collaborative games simulation examples.
Application Scenario 5- Healthcare

UC 6.1: Remote Patient Monitoring solutions desktop simulation.
Scenario 6.1.1: Wearing and removing the bodys sensors.
Scenario 6.1.2: Set-up of the Remote Monitoring System.
UC 6.2: Mobile device for older users interaction with Personal
Health solutions desktop simulation.
Scenario 6.2.1: Handling the device.
Scenario 6.2.2: Interaction with the touch screen.
Scenario 6.2.3: Interaction with the voice (input and/or output interface).
UC 6.3: Medical education and health coach application design.
Scenario 6.3.1: Exchanging messages with the doctor.
Scenario 6.3.2: Searching for medical news.
Scenario 6.3.3: Giving warnings to the user.
Combined usage:
User Profile 9: James is the lead designer for a company specialised in
designing and producing interfaces for a wide variety of ehealth applications,
either for fixed interfaces (wall mounted) or for mobile applications. Mobile e-
health (M-health) applications and services are a growing market for the
company, and James oversees that any interfaces that are deployed for these
ehealth applications meet the accessibility standards defined within VERITAS.
Recently, Jamess team was asked by an AIDS organisation to design an
accessible infusion pump interface that had to address the needs of people that
due to illness have an increased number of disabilities, ranging from mobility to
cognitive impairments both for a mobile and for a health coach application.

Elderly beneficiary
Beneficiaries with cognitive impairments
Beneficiaries with Parkinson disease

James had to fulfil the tasks that he was asked to do and for that he used
VERITAS, because otherwise this would have been a cumbersome task, with
considerable demanding time and additional testing. Using VERITAS, James
simulated how the users would handle the mobile device, interact with the touch
screen and interact with voice, features that he considers prerequisites for an
accessible design. Additionally, he also simulated the interaction of the user
with the Health Coach application that he has developed, simulating how the
user would exchange messages with the doctor, search for medical news and
give warnings to the beneficiaries. By using VERITAS, James and his team
developed an auditory guidance with a simple interface that makes the device
accessible to a variety of users, including those who have visual impairments,
are deaf and those how have motor deficits.
Figure 26: Healthcare simulation examples.

8 Conclusions
The current Deliverable provides a detailed presentation of the first version of
the VERITAS Use Cases. The Use Cases presented in the current Deliverable
have emerged from a thorough methodological framework, many refinements
from all the project partners and the prioritisation phase through the Workshop
and the Use Forum of VERITAS. The final version of the Use Cases is going to
be issued in Month 18 of the project and it will contain all the definite Use Cases
descriptions, their UMLs, their connection to the personas and the final
application scenarios both for the users and the beneficiaries.
Following a methodological framework, which has already been implemented

with success in other complex IP projects, like ASK-IT and AEGIS, we ended up
in 24 Use Cases titles, clustered per application domain. Namely the Use Cases
are the following:
UC 1.1: External applications interface.
UC 1.3: Virtual design analysis desktop simulation
UC 1.4: Virtual design analysis immersive simulation
UC 2.1.a/b: Car interior accessibility desktop/immersive simulation.
UC 2.2.a/b: Motorcycle handling accessibility desktop/immersive simulation.
UC 2.3.a/b: ADAS/IVIS functionalities desktop/immersive simulation.
UC 2.4.a/b: ARAS/OBIS functionalities desktop/immersive simulation.
UC 3.1.a/b: Interior Design desktop/immersive simulation.
UC 3.2.a/b: Domotics desktop/immersive simulation.
UC 4.1.a/b: Workspace design accessibility desktop/immersive simulation.
UC 4.2: Collaborative tools accessibility simulation.
UC 5.2: Collaborative games simulation.
UC 6.2: Mobile device solution simulation.
UC 6.3: Medical education and health coach simulation.
These Use Cases are accompanied with various, more detailed scenarios
where specific beneficiaries (user models) are executing specific tasks in order
for the designer/developer to create an accessible design for specific user
groups.
The aforementioned Use Cases have been prioritized both from the Consortium
and external experts and beneficiaries. 3 categories of prioritisation were set:
-Essential
-Secondary
-Supportive
Thus, each Use Case description encloses a level of prioritisation. The
essential and secondary UCs are the ones that have to be tested in the pilots
of SP3, while the supportive ones will be tested only if the specific UC is not
covered/tested through another UC. Nevertheless, there were no Use Cases
that were identified as supportive, neither from the Consortium, nor the
external experts and beneficiaries. Additionally, we were leaded to 19 essential
and 5 secondary Use Cases.

Essential Use Cases Secondary Use Cases

UC 1.1: External applications interface. UC 2.3.a/b:
UC 1.2: Generation of virtual test sample ADAS/IVIS
functionalities
UC 1.3: Virtual design analysis desktop
desktop/immersive
simulation
simulation.
UC 1.4: Virtual design analysis immersive
UC 2.4.a/b:
simulation
ARAS/OBIS
UC 2.1.a/b: Car interior accessibility functionalities
desktop/immersive simulation. desktop/immersive
UC 2.2.a/b: Motorcycle handling accessibility simulation.
desktop/immersive simulation. UC 5.1: Accessible
UC 3.1.a/b: Interior Design desktop/immersive metaverses
UC 3.2.a/b: Domotics desktop/immersive
simulation.
UC 4.1.a/b: Workspace design accessibility
desktop/immersive simulation.
UC 4.2: Collaborative tools accessibility
simulation
UC 5.2: Collaborative games simulation.
UC 6.1: Remote Patient Monitoring solutions
simulation.
UC 6.2: Mobile device solution simulation.
UC 6.3: Medical education and health coach
simulation.
Table 2: Essential and secondary Use Cases table.
Additionally to the Use Cases, another part of this Deliverable is the Application
Scenarios. At this moment Application Scenarios only for the
developers/designers have been created, where the Application Scenario for
the beneficiaries are to be included in the updated version of the current
Deliverable. Specifically, 5 Application Scenarios have been extracted by a mix
of Use Cases, including users from all the application domains, namely the
automotive, the smart living spaces, the workplaces, the infotainment and the
healthcare. In these Application Scenarios all the essential Use Cases are
merged in a series of narratives which illustrate real users interacting with the
VERITAS tool. In the Application Scenarios, even if developers are the main
actors, all the types of beneficiaries are covered, namely:
Elderly beneficiaries: Application Scenarios 1, 2, 4, 5.
Beneficiaries with upper limb impairments: Application Scenarios 1, 2, 3,
5.
Beneficiaries with visual impairments: Application Scenarios 1, 3, 4, 5.
Beneficiaries with hearing impairments: Application Scenarios 1, 2, 4, 5.
Beneficiaries with lower limb impairments (including tetraplegic
wheelchair users): Application Scenarios 3.
Beneficiaries with cognitive impairments (including Parkinson disease
users): Application Scenarios 4, 5.

Reference
[1] Report of the Inclusive Communications (INCOM) subgroup of the

Communications Committee (COCOM) COCOM04-08.
[2] Alistair Cockburn, Use cases, ten years later, Paper, Originally
published in STQE magazine, Mar/Apr 2002, available at:
http://alistair.cockburn.us/Use+cases,+ten+years+later
[3] Kurt Bittner, Ian Spence, Use Cases Modelling, Book, Boston, Mass.
[u.a.] : Addison-Wesley, 2006.
[4] A. Fantechi, S. Gnesi, G. Lami and A. Maccari Applications of linguistic

techniques for use case analysis. In Requirements Engineering, Springer
London Volume 8, Number 3 / 2003.
[5] Ruth Malan, Dana Bredemeyer, ARCHITECTURE RESOURCES For

Enterprise Advantage, Bredemeyer Consulting White Paper, 2001,
available at: http://www.bredemeyer.com/pdf_files/functreq.pdf
[6] Craig Larmen, Applying UML and patterns: an introduction to object-

oriented analysis and Design and the Unified Process, Chapter 6 by Ben
Stein, Use Case Model: writing requirements in context , available at:
http://www.sis.pitt.edu/~gray/INFSCI1024/references/UseCasesLarmanC
hp06.pdf
[7] Ivan Jacobson, Object Oriented Software Engineering: A Use Case

Driven Approach, Book, 1992
[8] Ivan Jacobson, Pan-Wei NG, Aspect-Oriented Software Development

with Use Cases, Book, Addison-Wesley, 2005
[9] Wikipedia, Domain Model Definition and Description, available at:

http://en.wikipedia.org/wiki/Domain_model
[10] Doug Rosenberg, Matt Stephens, Book Use Case Object

Modelling with UML, APRESS, 2007.
[11] Lee, Jonathan and Nien-Lin Xue. Analyzing User Requirements by

Use Cases: A Goal-Driven Approach. IEEE Software. v.16 n.4
July/August 1999. p92-100.
[12] Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley

Longman, Q3 2000, available at:
http://seal.ifi.uzh.ch/fileadmin/User_Filemount/Vorlesungs_Folien/SOPR
A/SS05/weuc_extract.pdf
[13] Lorenz, Mark. Object-Oriented Software Development: A Practical

Guide. PTR Prentice Hall. Englewood Cliffs, NJ. 1993.

[14] Alistair Cockburn, Structuring use cases with goals,1997,

available at:
http://alistair.cockburn.us/Structuring+use+cases+with+goals
[15] ORACLE, An Oracle White Paper, Getting Started with the Use
Cases Modelling, March 2005
[16] Anabela Simes, Ana Gomes, Evangelos Bekiaris, ASK-IT Project

Deliverable 1.1.2 Use cases, May 2006
[17] M. Panou, E. Bekiaris, OASIS Project, Deliverable 3.1.1 Use

cases and application scenarios for mobility and smart workplaces,
January 2008.
[18] Evangelos Bekiaris, Maria Gemou, GIS project, Deliverable

1.1.3 Use cases and application scenarios, September 2008.
[19] Ferg Stephen, Whats wrong with use cases?, 2003, available at
http://www.ferg.org/papers/ferg--whats_wrong_with_use_cases.html
[20] Alistair Cockburn, Basic Use Case Template, 1996
[21] By David M. Rubin, Uses of Use Cases, Methodologies and

Practices White Paper, Softstar Research, Inc., 1998
[22] Microsoft Office Visio details, http://office.microsoft.com/en-

us/visio/
[23] Steven Swafford, article Use Cases and Their Importance,

January 2006.
[24] Mariya Goranova Valkova, Karel Van Isacker, Andrean Lazarov

(MCA), Eleni Chalkia (CERTH/HIT), Alberto Paludet, Mauro Da Lio,
Mariolino De Cecco (UNITN), Nikolaos Partarakis (FORTH), Francesco
Palma, Giuseppe Varalda (CRF), Wirsching Hans-Joachim (HS), Ana
Navarro, Juan Naranjo (ITACA), Vitaliy Kolodyazhniy (COAT), Maria de
las Mercedes Fernandez-Rodriguez (UPM), Tamara Aguilar (AIJU),
Nicola Cofelice, Dirk Roesems, Stijn Donders (LMS), Caterina Calefato
(RE: Lab), Luca Minin (RE: Lab), VERITAS D1.1.1, UCD-based user
requirements extraction.

ANNEX 1: VERITAS Use Cases Template

Use Case
No
Use Case <indicating the goal>
Title
Brief <a longer statement of the goal>
description
(user goal
satisfied)
Application Smart Living Personal Workplace
area Spaces HealthCare Infotainment Automotive
Relevant
WP
Scenario <i.e. what the user has to accomplish; can be more than one>
Primary
Actor(s)
level
System
input
System <i.e. what should be the systems functionality, as reaction to the user actions>
output
Interaction Provide here a detailed list of user-system dialogue steps that would realise the
steps scenario in question
Scenario 1
<Step 1 the user wants to
Step 2 the system >
Scenario 2

Scenario 3

Scenario 4

Connected <Input from other UCs, output to other UCs>
UCs
Background
info/ reason
on selection
and on
assigning
the priority
level
References

ANNEX 2: VERITAS User Forum agenda

VERITAS 1st Pan-European User
Forum
Virtual and Augmented Environments and
Realistic User Interactions To achieve Embedded
Accessibility DesignS
29th November 2010, Prague, Czech Republic
Time Topic Speaker

The VERITAS project at a
13.30 14.00 Fraunhofer IAO
glance
Why User Involvement is
14.00 14.15 AGE Platform Europe
important
Presentation of Use cases
14.15 15.00 HIT and MCA
and user scenarios
15.00 15.30 Coffee break
Discussion in two groups (end
users and beneficiaries) on Coordinated by AGE, HIT,
15.30 16.30
generic use cases and user and MCA
scenarios
Joint meeting of the two Coordinated by HIT, AGE
16.30 17.00
groups on conclusions and MCA
17.00 Wrap-up and goodbye AGE Platform Europe

Evaluation Form
I am:
a developer /designer
a beneficiary older people
a beneficiary people with disabilities
Please indicate for each question to what extent you agree or disagree
and use a scale of 1 to 4 whereby:
1 =totally disagree; 2 = disagree; 3 = agree; 4 = totally agree
This user forum was interesting for me

1 2 3 4
The presented topics were interesting and relevant

1 2 3 4
The general organisation and venue of the user forum was good
1 2 3 4
Enough supporting material was provided

1 2 3 4
The user forum did not last too long

1 2 3 4
The presentations were clear

1 2 3 4
I would like to participate in similar events in future

1 2 3 4
How were you informed about the user forum?
............................................................................................................................
............................................................................................................................
Your recommendations:
............................................................................................................................
............................................................................................................................
Please give the completed form back to the user forum responsibles
upon your departure. Thank you for your cooperation!

ANNEX 3: VERITAS Workshop agenda





ANNEX 4: VERITAS Use Cases Prioritisation

Template
Accessible and Assistive ICT
VERITAS
Virtual and Augmented Environments and Realistic User
Interactions To achieve Embedded Accessibility DesignS
247765
Template for the Use Cases prioritisation

Name:
Profession:
Organisation:
Country:
e-mail:

Use Cases presentation
Use Framework
Scenario 1.1.1: Definition of physical dimensions
The designer specifies the body dimensions as stature,

sitting height and corpulence of each virtual user of the test
sample. The dimensions are given with respect to gender,
age, year and nationality.
the designer specifies the impairment classes (physical,

cognitive and psychological), types and the corresponding
parameters for each virtual user of the test sample
UC 1.2.a: Virtual design analysis desktop simulation
Scenario 1: Assessment of design variant
The designer
loads a geometrical design environment from an

external system-application
selects a task from the task model repository
specifies the corresponding task objects in the

design environment.
UC 1.2.b: Virtual design analysis immersive simulation
Scenario 1: Assessment of design variant
The designer
loads a geometrical design environment from an

external system-application
defines the interactive
defines interaction tools will be used

Automotive
Scenario 1: Central rear mirror tuning
The designer wants to assess if the design of the car allows

the driver to personalize the orientation of the central rear
view mirror.
For a typical beneficiary.
For a beneficiary with upper limp impairment.
Scenario 2: Lateral mirror tuning
The developer wants to assess if the design of the car

allows driver to personalize the orientation of lateral
mirrors.
For a beneficiary with upper limp impairments.
Scenario 3: Hand brake activation/deactivation
The designer wants to assess if the design of the car allows

the driver to engage or disengage the hand brake.
For a beneficiary who is a male, tall and young.
For a female, young elderly with low height.
The developer wants to assess if the design of the car

allows driver to personalize the orientation of lateral
mirrors.
UC 2.2.a/b: Motorcycle handling accessibility desktop/immersive

simulation.
Scenario 1: Riding position.
The designer wants to assess if the rider is able to take an

adequate position on the vehicle.

For a beneficiary with upper limp impairment.
Scenario 2: Usage on bumpy roads (comfort).
The developer wants to assess the comfort of the vehicle

on bumpy roads.
For a young elderly with slight motor problems.
UC 2.2.a/b: Motorcycle handling accessibility desktop/immersive

simulation.
Scenario 3: Central stand.
The designer wants to assess if the rider is able to place

the vehicle on its center stand.
For a young elderly with week body structure.
UC 2.3.a/b: ADAS/IVIS functionalities desktop/immersive simulation.
Scenario 1: On-board navigation system programming
The designer wants to assess if the navigation display is

reachable.
For a female with low height and (i.e.. Chinese

woman)
Scenario 2: AUDIO system programming and tuning
The developer wants to assess if the audio system is

accessible.
For a beneficiary with slight hearing impairment.
UC 2.4.a/b: ARAS/OBIS functionalities desktop/immersive simulation.
Scenario 1: Collision Avoidance system (CAS)
The designer wants to assess the accessibility of the

HMI of the CAS.

For a beneficiary with colour blindness.
Scenario 2: Navigation
The developer wants to assess if the navigation system

is in the field of vision of the rider.
For a beneficiary with tunnel vision

Smart Living Spaces

UC 3.1.a/b: Interior Design desktop/immersive simulation.
Scenario 1: In-building navigation accessibility
The designer wants to assess if the interior design of a

building is accessible for navigation (i.e. stairs-steps height,
inclination of ramps, doors width, etc.)
For a beneficiary with lower limp impairments.
For a tetraplegic.
UC 3.2.a/b: Domotics desktop/immersive simulation.
Scenario 1: In-building navigation accessibility
The designer wants to assess if the user-interface for

remotely monitoring and controlling of appliances.
For an elderly with low vision.
Scenario 2: Appliances accessibility
The designer wants to assess if a kitchen appliance is

accessible.
For an elderly with cognitive impairments.

Workspaces
UC 4.1.a/b: Workspace design accessibility desktop/immersive
simulation.
Scenario 1: In office navigation accessibility
The designer wants to assesses the accessibility of the

pathway from the entrance to the room.
For a tetraplegic.
Scenario 2: Printer and closet accessibility

printer location and closets
UC 4.1.a/b: Workspace design accessibility desktop/immersive

simulation.
Scenario 3: E-mail software accessibility.

email software.
For a beneficiary with colour blindness.
For a beneficiary with cognitive impairments.
UC 4.2.a/b: Collaborative tools accessibility desktop/immersive

simulation.
Scenario 1: Accessibility of distance collaborative working tool.

HMI of a collaborative working tool.

For a beneficiary with visual impairments.
Scenario 2: Accessibility of teleconferencing tool
The designer wants to assesses the accessibility of

teleconferencing tool.
For a beneficiary with heating impairments.

Infotainment
UC 5.1.a/b: Accessible metaverses desktop/immersive simulation.
The designer wants to assesses the accessibility of the 2D

UI Design.
Scenario 2: Accessibility of 3D UI Elements
The designer wants to assesses the accessibility of 3D UI

Elements
Scenario 3: 3D Metaverse Environment Navigation
The designer wants to assesses the accessibility of the 3D

metaverse environment navigation.
Scenario 4: Inter-user Interaction

Inter-user Interaction.


2D UI Design.
Scenario 2: Accessibility of 3D UI Elements
The designer wants to assesses the accessibility of 3D

UI Elements
UC 5.2.a/b: Collaborative games desktop/immersive simulation.
Scenario 1: Game Controls Accessibility
The designer wants to assesses the accessibility of game

controls accessibility
Scenario 2: Game Display Settings Accessibility

game display settings accessibility.
For a beneficiary with visual impairments
UC 5.2.a/b: Collaborative games desktop/immersive simulation.
Scenario 3: Multiplayer Mode Accessibility
The designer wants to assesses the accessibility of

Multiplayer Mode Accessibility

Healthcare
UC 6.1.a/b: Remote Patient Monitoring solutions desktop/immersive
simulation.
Scenario 1: Wearing and removing the bodys sensors
The designer wants to assesses if the design of the

wearable sensors (shape, size, fixing mechanism) allows
the elderly to handle them and to fix them in the right
position.
For a beneficiary with upper limb impairments.
Scenario 2: Set-up of the Remote Monitoring System
The designer wants to assesses if the tutorial provided to

the user on the screen of his mobile device allows the user
to execute the right sequence of operations for the set up of
the Remote Monitoring System.
UC 6.2.a/b: Mobile device solution desktop/immersive simulation.
Scenario 1: Handling mobile device
The designer wants to assesses if the user can grasp the

device and if it is able to handle it.
Scenario 2: Interaction with the touch screen
The designer wants to assesses if the user can interact

with the touch screen.

UC 6.2.a/b: Mobile device solution desktop/immersive simulation.
Scenario 3: interaction with the voice (input and/or output

interface).
The designer wants to assesses if the user can interaction

with the voice.
For a beneficiary with speech impairments.
UC 6.3.a/b: Medical education and health coach desktop/immersive

simulation.
Scenario 1: Exchanging messages with the doctor
The designer wants to assesses if the user is able to

exchange messages with his doctor .
For an young elderly.
For an old elderly.
Scenario 2: Searching for medical news
The designer wants to assesses if the user is able to

search and read the news.
UC 6.3.a/b: Medical education and health coach desktop/immersive

simulation.
Scenario 3: Giving warnings to the user
The designer wants to assesses if the warnings given to

the user are accessible.

In the context of VERITAS an effort is being done in order to prioritise the

extracted use cases in order to fit the users expectations. To this end we kindly
ask all users to help us go through this effort by giving us their valuable opinion.
The stakeholders that are involved in the VERITAS project are the elderly and
disabled.
The following tables are to be filled in having an overall estimation of the all the
Use Cases by a grade, as follows:
1: High Priority
2: Average Priority
3: Low Priority
Also the comments pro and con to the respective use cases could be noted.
Priority Reaso Reaso

(1,2,3) ns pro ns con
Category 1- Use Framework
UC 1.2.a: Virtual design analysis desktop
simulation
UC 1.2.a: Virtual design analysis immersive
simulation
Priority Reaso Reaso

(1,2,3) ns pro ns con
Category 2- Automotive desktop simulation
UC 2.1 Car interior accessibility simulation
Scenario 1: Central rear mirror tuning
Scenario 2: Lateral mirror tuning

activation/deactivation

UC 2.2 Motorcycle handling accessibility
simulation
Scenario 1: Riding position.
Scenario 2: Usage on bumpy roads (comfort).
Scenario 3: Central stand.
UC 2.3: ADAS/IVIS functionalities simulation

Scenario 1: On-board navigation system
programming
Scenario 2: AUDIO system programming and
tuning

UC 2.4: ARAS/OBIS functionalities simulation
Scenario 1: Collision Avoidance system (CAS)
Scenario 2: Navigation
Priority(1,2, Reason Reason

3) s pro s con
Category 3- Smart living places design
UC 3.1 Interior Design simulation.
Scenario 1: In-building navigation
accessibility
UC 3.2 Domotics desktop/immersive
simulation
Scenario 1: In-building navigation
accessibility
Scenario 2: Appliances accessibility
Reasons
Priority(1,2,3) Reasons pro con
Category 4- Workspaces
UC 4.1 Workplace design
accessibility simulation.
Scenario 1: In office navigation
accessibility
Scenario 2: Printer and closet
accessibility
Scenario 3: E-mail software
accessibility.
UC 4.2 Collaborative tools
accessibility simulation
distance collaborative working
tool.
teleconferencing tool
Reasons
Priority (1,2,3) Reasons pro con
Category 5- Infotainment
UC 5.1 Accessible metaverses
simulation.
Scenario 2: Accessibility of 3D UI
Elements
Scenario 3: 3D Metaverse
Environment Navigation

Reasons
Category 5- Infotainment
Scenario 4: Inter-user Interaction
UC 5.2 Collaborative games for
older people desktop simulation.
Scenario 1: Game Controls
Accessibility
Scenario 2: Game Display
Settings Accessibility
Scenario 3: Multiplayer Mode
Accessibility
Reasons
Category 6- Health Care
UC 6.1 Remote Patient
Monitoring solutions simulation.
Scenario 1: Wearing and
removing the bodys sensors
Scenario 2: Set-up of the Remote
Monitoring System
UC6.2 Mobile device for older
users interaction with Personal
Health solutions desktop
simulation
Scenario 1: Handling mobile
device
Scenario 2: Interaction with the
touch screen
Scenario 3: interaction with the
voice (input and/or output
interface).
UC6.3 Medical education and
health coach application design.
Scenario 1: Exchanging
messages with the doctor
Scenario 2: Searching for medical
news
Scenario 3: Giving warnings to the
user

Missing Use Cases
Avoided or under condition Use Cases

Veritas d1.7.1 Final

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Veritas d1.7.1 Final

Uploaded by

Copyright:

Available Formats

Accessible and Assistive ICT

Final version of VERITAS Use Cases and

Deliverable No. D1.7.1.a

Authors Eleni Chalkia, Evangelos Bekiaris, (CERTH/HIT),

Dissemination Level: Pu (Public)

File Name: VERITAS_D1.7.1_final

Project start date and 01 January 2010, 48 Months

Version History table

2 Creating a 2nd Draft by implementing the Review commends. August

3 Receiving and implementing comments and input from the partners

December 2010 iii CERTH/HIT

December 2010 iv CERTH/HIT

7 Application scenarios............................................................. 153

December 2010 v CERTH/HIT

December 2010 vi CERTH/HIT

ADAS Advanced Driver Assistance Systems

ARAS Advanced Rider Assistance Systems

CAS Collision Avoidance system

DOM Domain Object Model

EARL Evaluation and Report Language

ICT Information and communication technologies

IVIS In-Vehicle Information System

OBIS On-Board Information System

SoA State of the Art

UCD User Centred Design

VRDECO VR-based DEsign COordination

December 2010 vii CERTH/HIT

December 2010 1 CERTH/HIT

December 2010 2 CERTH/HIT

December 2010 3 CERTH/HIT

have undergone several refinements by partners and external users and

1.1 The Use Cases concept

Use Cases were initially presented by Ivar Jacobson in 1967 as usage

1.1.1.1 Use Cases and system functional requirements

December 2010 4 CERTH/HIT

1.1.1.2 Use Cases in the problem domain model

Figure 1: Domains within a project where Use Cases can be implemented.

To create a domain-model means, in a sense, to construct a dictionary of words

December 2010 5 CERTH/HIT

The domain-model provides an infrastructure for the requirements-gathering

December 2010 6 CERTH/HIT

Figure 3: Use Cases Model.

1.1.1.3 Use Cases Value

December 2010 7 CERTH/HIT

Figure 4: Use Cases hub & spoke scheme.

December 2010 8 CERTH/HIT

2 The VERITAS Use Cases methodological

2.1 Use Cases descriptions

Those descriptions require a template to provide a systematic methodology.

The fully-dressed format is characterized by:

A simple and typical fully-dressed template is presented below [20], together

December 2010 9 CERTH/HIT

2.1.1 Scenarios and Goals

December 2010 10 CERTH/HIT

Figure 5: Striped trousers scenarios succeed or fail.

A Use Case is a collection of related success and failure scenarios that

Scenarios and Use Cases go until goal success or abandonment.

Scenario: a sequence of interactions happening under certain conditions,

Use Case: a collection of possible scenarios between the system under

2.1.2 Other Use Cases Elements

Use Case Title

December 2010 11 CERTH/HIT

Brief description (user goal satisfied)

Primary Actors, Secondary Actors and Other road participants