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