=Paper=
{{Paper
|id=None
|storemode=property
|title=Embedding Requirements in Design Rationale to Deal Explicitly with User eXperience and Usability in an “Intensive” Model-Based Development Approach
|pdfUrl=https://ceur-ws.org/Vol-617/MDDAUI2010_Paper08.pdf
|volume=Vol-617
}}
==Embedding Requirements in Design Rationale to Deal Explicitly with User eXperience and Usability in an “Intensive” Model-Based Development Approach==
https://ceur-ws.org/Vol-617/MDDAUI2010_Paper08.pdf
Embedding Requirements in Design Rationale to Deal
Explicitly with User eXperience and Usability in an “intensive”
Model-Based Development Approach
Célia Martinie, Jeff Ladry, David Navarre, Philippe Palanque & Marco Winckler
IRIT - University Paul Sabatier
118, route de Narbonne, 31062 Toulouse Cedex 9, France
{martinie, ladry, navarre, palanque, winckler}@irit.fr
in Air Traffic Management Systems [5] explicitly requires
ABSTRACT
Requirements engineering for interactive systems remains a traceability to be addressed in respect of all software
cumbersome task still under-supported by development requirements (p. 11 edition 0.2).
processes. Indeed, in the field of HCI, currently the most This position paper addresses the problem of traceability of
common practice is to perform user testing to assess the requirements for model-based approaches. It tackles the
compatibility between the designed system and its intended problem by providing an extension to a notation TEAM and
user. Other approaches such as scenario-based design its associated tool DREAM which have previously been
[14,16], promote a design process based on the analysis of presented in [9]. The current contribution makes it possible
the actual use of a technology in order to design new to relate design options with functional and non functional
technologies better supporting users’ tasks. However, these requirements. While other approaches such as SCRAM [16]
approaches do not provide any support for a) the definition focus on requirements identification, our approach is
of a set of requirements that have to be fulfilled by the intended for supporting the traceability of such identified
system under design and b) as a consequence for assessing requirements within interactive systems models. As an
which of these requirements are embedded in the system example we show how two different interaction techniques
and which ones have been discarded. This position paper modeled using ICOs [11] satisfy different functional and
proposes a notation and a tool for addressing precisely these non-functional requirements. While the approach could
two challenges. These elements are integrated within a address any kind of requirements, we put the emphasis on
more global approach aiming at providing notations and Usability and User eXperience.
tools for supporting a rationalized design of interactive Next section quickly presents the basic principles of the
systems following a model-based approach. TEAM notation and the extensions that have been made to
include information related to requirements. They will then
Keywords be used in the third section on a case study for comparing
Model-based UI design, requirements, interaction the two interaction techniques with respect to requirements
technique, design rationale, user experience, usability. providing ways of answering two fundamental questions: 1)
INTRODUCTION Which current design (among the many ones available
Traceability of choices and systematic exploration of following a prototyping phase for instance) satisfies a given
options is a critical aspect of the development processes in requirement and 2) What is the exhaustive list of
the field of safety critical systems. Some software standards requirements fulfilled by a particular design.
such as DO 178 B [15] (which is widely used in the EXTENSION OF THE TEAM MODEL AND NOTATION
aeronautical domain) require the use of methods and The TEAM notation (Traceability, Exploration and
techniques for systematically exploring design options and Analysis Method) and its CASE tool DREAM (Design
for increasing traceability of design decisions. However, Rationale Environment for Argumentation and Modeling)
such standards only define what should be done and has been proposed in [9] to support the exploration of
provide no information on how such goals can be reached options and traceability of choices during the development
by designers. Recent work in the field of software process of interactive safety critical systems.
engineering has been trying to provide solutions to that
problem and a collection of papers on that topic can be TEAM notation
found in [4]. One of the remaining problems pointed out by The TEAM notation is based on Question Option Criteria
many contributions, such as chapters 1, 19 and 20, is that Design Rationale notation introduced by MacLean and al.
requirements are poorly or even not addressed. However, [10]. QOC notation allows to list the available options for a
Requirements Engineering (which is the first phase of the design interrogation and to trace the selection of an option
development process) provides input to all the subsequent with regards to a list of relevant criteria. The TEAM
phases and must be dealt with adequately. Indeed, ESARR notation is an extension of QOC that enables the recording
(Eurocontrol Safety Regulatory Requirement) on Software
Pre-proceedings of the 5th International Workshop on Model Driven Development of Advanced User Interfaces (MDDAUI 2010): Bridging between User Experience and UI
Engineering, organized at the 28th ACM Conference on Human Factors in Computing Systems (CHI 2010), Atlanta, Georgia, USA, April 10, 2010.
Copyright © 2010 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. Re-publication of material from this volume requires
permission by the copyright owners. This volume is published by its editors.
29
(in an exhaustive manner) of much information produced move an icon onto the trash icon. When the system detects
during design meetings. Such information can be: that the icon file has entered a 2 centimeters circle area
The questions that have been raised, around the trash icon, the user has 2 seconds to drop the file
icon on the trash, or the trash icon will move to another
The design options that have been investigated and the
location on the display. More sophisticated techniques
ones that have been selected,
could be easily modeled using our approach but this is
The evaluation performed for the different options, beyond the scope of the position paper. The second
The collection of factors that have been taken into interaction technique is a speech and click interaction where
account and how they relate to evaluation criteria, the user utters “delete” and clicks on the icon to be deleted.
The task models corresponding to options The Speech & Click and enriched Drag & Drop options,
The resulting scenarios among other design choices, are going to be evaluated
Besides this recording of information, an important feature according to the initial requirements for the application.
is to record design decisions and relate them to selected One having an important impact is the one requiring the
factors. interaction technique to be tolerant to interruptions (for
more details see [17]).
This notation and associated tool can then leverage the
design rationale process for several interactive applications Presentation
and help engineers in deciding to reuse or not conception An initial list of these requirements gathers functional needs
choices when facing an already experienced issue. and non-functional ones (mainly Usability and User
eXperience). An extract of the set of usability requirements
Adding requirements to the TEAM notation for this user interface are (“u” stands for usability
In the earlier version, the notation did not allow to express requirement):
the needs and requirement. But this is required from the
designers’ extensive work to trace back for the selected Ru1-The application shall support one interruption
options what were the requirements met. In addition, this every 10 seconds
lack of relationship prevents designers from exploiting Ru3-The application shall allow the user to clean the
requirements for the generation of options and/or to take desktop in less than 30 seconds
into account requirements aspects when designing an The set of user experience requirements for this user
option. We have thus added requirements as an explicit interface are (“ux” stands for user experience):
entity in the TEAM notation and in the DREAM tool. Rux1-80% of the users shall find the application easy
Several requirements are represented in Figure 1 (grey to use
rectangles with a folded corner on the top left hand side)
Rux2-80% of the users shall find that interacting with
but the content of the figure will only be described in the
this application is surprisingly different
next section. As far as HCI aspects are concerned this
addition is very important as it makes it possible to Given this list of requirements, evaluation criteria are
explicitly represent contributing factors to usability and defined and linked to appropriate factors. The different
User eXperience (UX) and thus assess the relevance of questions, options and design paths with regards to elected
design options to them. The requested usability criteria are consigned within the DREAM design rationale
requirements relate to the efficiency and effectiveness tool. Figure 1 gives an overview of the design options
factors of the system from an ISO 9241-11 perspective [8]. linked to requirements and evaluation criteria. Due to space
The requested user experience requirements relate to the constraints, the schema has been shrunk, but several display
pragmatic quality and stimulation hedonic quality factors of techniques for the tool are currently being studied for big
the system from a Hassenzahl perspective [6]. This specific and complex diagrams. Rectangles show the requirements,
aspect will be detailed in the next section through a case rounded-shape squares contain the design questions that
study. have been asked, right-angle triangles on the right side
describe factors and the other triangles describe criteria.
CASE STUDY Each question has several possible options to address the
The application we chose allows a user to remove a set of issue. For instance, as far as the interruption is concerned
icons on a computer screen. It has first been used and (“How to display interruptions?”), the interruption can be
presented by Maurice H. ter Beek and al. to evaluate the displayed as a “pop-up window” or as a “small icon
“Resilience of interaction techniques to Interrupts” [17]. In blinking” on one side of the display. In the TEAM mode,
order to represent design choice and design rationale we the connection between these options and the four criteria
consider two different interaction techniques for performing “File deletion error rate”, “Time to clean desktop”,
that task. The first interaction technique only uses a mouse- “Perceived manipulability” and “Perceived originality”
based one while the second is multimodal as it uses speech represents the relative impact of the option. The strong link
additionally. The first interaction technique is an enriched between the option “small icon blinking” and the “time to
drag and drop interaction, with which the user is able to clean desktop” criterion shows that it favors that criterion.
30
Figure 1. Design Rationale overview from a design session output with DREAM
The right-hand side of the diagram makes explicit the this approach is effective if the number of modeled and
relationship between criteria and factors. Factors prototyped options is balanced with the modeling and
correspond to desired characteristics of the system namely prototyping cost. To help in comparing the two remaining
“Usability” and “User eXperience”. They are in turn interaction techniques, models of these interactions have
decomposed into sub-factors; two out of the three been built and embedded in the DREAM diagram as
classical ones for usability i.e. “effectiveness” and indicated by the paperclip symbol at the bottom-right of
“efficiency” and two for “User eXperience” i.e. each option. ICO models of the two interaction techniques
“Pragmatic quality” and “Hedonic Quality Stimulation”. are built and assessed (Enriched Drag and Drop technique
ICO model detailed in Figure 2), with respect to both
Design options modeling “user experience” and “usability” factors. These models
One of the issues that remain to be solved is how to assess are then verified and prototyped by means of PetShop
the options with respect to the connected criteria. For tool. Effectiveness can be verified and performance
instance, how to identify if the option “Mouse and evaluation technique can be used to assess time
Speech” for the interaction technique is better than the performance for instance. Due to space constraints this is
option “Enriched Drag and Drop” with respect to the not detailed here. Usability tests can be performed on the
criterion “Time to clean desktop”. In order to address that prototypes with the building of the application while
problem we propose to apply a model-based approach and performance evaluation can be done on the model only.
to define for each option a detailed behavioral description. For the user experience aspects, using the prototyped
For that purpose we use the ICO notation [11], but other options, an evaluation has been performed with
ones such as [2 or 6] would also be applicable. ICO AttrakDiff tool [7] to rate the selected criteria. Paperclip
notation stands for Interactive Cooperative Objects and is symbols on “perceived manipulability” and “perceived
a formal notation to describe interactive systems. It is originality” criteria represent the fact that such results are
based on object-oriented design pattern and high-level stored in the design rationale model. Furthermore, to help
Petri nets. The PetShop associated tool [1 and 13] allows in checking this coverage and to ensure that one or more
editing the ICO model and prototyping the associated evaluation criteria are not missing, the tool allows linking
interface at the same time (this aspect is detailed in [12]). the requirements to criteria.
The DREAM diagram shows that a third design option,
speech only, had initially been suggested and that this Interpretation and benefits
option does not fulfill all the non-functional requirements, Once the design options have been assessed, DREAM
even before having prototyped or modeled it. The model makes it easy to perceive which one (if any) has
modeling of an option has a cost indeed and the gain of received the best evaluation.
31
REFERENCES
1. Bastide, R., Navarre, D., and Palanque, P. 2002. A model-based tool
for interactive prototyping of highly interactive applications. In CHI
'02 Extended Abstracts on Human Factors in Computing Systems
(Minneapolis, Minnesota, USA, April 20 - 25, 2002). CHI '02.
ACM, New York, NY, pp. 516-517.
2. Coninx, K., Cuppens, E., De Boeck, J. & Raymaekers, C., 2007,
Integrating Support for Usability Evaluation into High Level
Interaction Descriptions with NiMMiT . In: Interactive Systems:
Design, Specification, and Verification. 2007, Springr Verlag
LNCS, pp. 95-108.
3. DREAM web site: Internet Resource
http://ihcs.irit.fr/dream/index.html , accessed Jan 2010.
4. Dutoit, A.H., McCall, R., Mistrík, I., Paech, B., Rationale
Management in Software Engineering: Concepts and Techniques,
Rationale Management in Software Engineering, p. 1.
5. ESARR 6. EUROCONTROL Safety Regulatory Requirement.
Software in ATM Systems. Edition 1.0.
http://www.eurocontrol.int/src/public/standard_page/esarr6.html
(2003)
Figure 2. ICO model of Enriched Drag & Drop 6. Hassenzahl, M. The thing and I: understanding the
In addition it makes it explicit for this option which relationship between user and product. In M.Blythe, C. Overbeeke,
AF Monk, & PC Wright (Eds.),
requirements it fulfils. Coming back to the importance of Funology: From Usability to Enjoy-ment. Dordrecht: Kluwer, 2003,
requirement engineering, DREAM diagram is a critical pp. 31-42.
help to argue about, to select an option as well as to trace 7. Hassenzahl, M. - Internet Resource
back the rationale underlying this selection. In our http://www. attrakdiff.de, accessed Jan 2010.
example, we see at a glance that the “Mouse and Speech” 8. ISO DIS 9241-11 (1996) Ergonomic requirements for office work
option is the best rated and that it fulfills the entire set of with visual display terminals (VDT) - Part 11 Guidance on usability.
non-functional requirements. The final choice then 9. Lacaze, X., Palanque, P., Barboni, E., Bastide, R., Navarre, D.,
belongs to the various stakeholders who have additionally From DREAM to Reality : Specificities of Interactive Systems
direct access to the related requirements which, in turn, Development With Respect to Rationale Management, Rationale
cannot be ignored. Furthermore, all the necessary Management in Software Engineering, pp.155-170.
information about the designed interactive system can be 10. MacLean, Allan; Young, Richard M.; Bellotti, Victoria M. E., and
Moran, Thomas P. Questions, Options, and Criteria: Elements of
gathered and synthesized in one diagram. From a designer Design Space Analysis. Lawrence Erlbaum Associates; 1991; 6, pp.
perspective, it can help to share conception ideas and 201-250.
materials. From another participant involved in the 11. Navarre, D., Palanque, P., Ladry, J., and Barboni, E. 2009. ICOs: A
implementation and/or deployment process, it can be seen model-based user interface description technique dedicated to
as an entry point to the designed system. interactive systems addressing usability, reliability and scalability.
ACM Trans. Comput.-Hum. Interact. 16, 4 (Nov. 2009), pp. 1-56.
CONCLUSION 12. Palanque P., Ladry J., Navarre D. and Barboni E. High-Fidelity
This position paper argues that various models are useful Prototyping of Interactive Systems can be Formal too 13th
for the design of interactive systems as they can International Conference on Human-Computer Interaction (HCI
complement each other and correspond to the needs of International 2009) San Diego, CA, USA.
different stakeholders. We have presented a model-based 13. PetShop web site: Internet Resource http://ihcs.irit.fr/petshop,
approach for description within and single diagram accessed Jan 2010.
requirements, design questions, design options, criteria 14. Rosson, M.B. & Carroll, J.M. 2002. Usability Engineering:
Scenario-Based Development of Human-Computer Interaction. San
and factors. This structured set of information supports Francisco: Morgan Kaufmann.
different activities such as requirements traceability,
15. RTCA. Software Considerations in Airborne Systems and
design choices decision support and the traceability of Equipment Certification, DO-178B RTCA, Washington D.C. 1992
design choices decisions. We have also presented how
16. Sutcliffe A. & Ryan M. Experience with SCRAM, a SCenario
detailed behavioral description of advanced interaction Requirements Analysis Method, in Proceedings of the 3rd
techniques such as “Enriched drag and drop” or “speech International Conference on Requirements Engineering: Putting
and click” can be integrated within that framework to Requirements Engineering to Practice, April 1998, pp. 164-173.
provide additional benefits. Of course such “intensive” 17. Ter Beek, M. H., Faconti G. P., Massink, M., Palanque P., Winckler
model-based approaches require tools to support model M. Resilience of interaction techniques to Interrupts: A Formal
construction, analysis, simulation, interpretation and Model-Based Approach. In proc. of Human-Computer Interaction
(INTERACT 2009), Uppsala, Sweeden, Vol. 1, Springer-Verlag,
reuse. The CASE tools supporting TEAM and ICO LNCS 5726, p. 494-509.
notation are publicly available [3 and 13] and are a corner
stone of the applicability of the approach.
32