Requirements engineering for interactive systems remains a cumbersome task still under-supported by development processes. Indeed, in the field of HCI, currently the most common practice is to perform user testing to assess the compatibility between the designed system and its intended user. Other approaches such as scenario-based design [14,16], promote a design process based on the analysis of the actual use of a technology in order to design new technologies better supporting users' tasks. However, these approaches do not provide any support for a) the definition of a set of requirements that have to be fulfilled by the system under design and b) as a consequence for assessing which of these requirements are embedded in the system and which ones have been discarded. This position paper proposes a notation and a tool for addressing precisely these two challenges. These elements are integrated within a more global approach aiming at providing notations and tools for supporting a rationalized design of interactive systems following a model-based approach.
INTRODUCTION
Traceability of choices and systematic exploration of
options is a critical aspect of the development processes in
the field of safety critical systems. Some software standards
such as DO 178 B [
This position paper addresses the problem of traceability of
requirements for model-based approaches. It tackles the
problem by providing an extension to a notation TEAM and
its associated tool DREAM which have previously been
presented in [
Next section quickly presents the basic principles of the TEAM notation and the extensions that have been made to include information related to requirements. They will then be used in the third section on a case study for comparing the two interaction techniques with respect to requirements providing ways of answering two fundamental questions: 1) Which current design (among the many ones available following a prototyping phase for instance) satisfies a given requirement and 2) What is the exhaustive list of requirements fulfilled by a particular design.
EXTENSION OF THE TEAM MODEL AND NOTATION
The TEAM notation (Traceability, Exploration and
Analysis Method) and its CASE tool DREAM (Design
Rationale Environment for Argumentation and Modeling)
has been proposed in [
TEAM notation
The TEAM notation is based on Question Option Criteria
Design Rationale notation introduced by MacLean and al.
[
The design options that have been investigated and the ones that have been selected,
The collection of factors that have been taken into account and how they relate to evaluation criteria,
This notation and associated tool can then leverage the
design rationale process for several interactive applications
and help engineers in deciding to reuse or not conception
choices when facing an already experienced issue.
Adding requirements to the TEAM notation
In the earlier version, the notation did not allow to express
the needs and requirement. But this is required from the
designers’ extensive work to trace back for the selected
options what were the requirements met. In addition, this
lack of relationship prevents designers from exploiting
requirements for the generation of options and/or to take
into account requirements aspects when designing an
option. We have thus added requirements as an explicit
entity in the TEAM notation and in the DREAM tool.
Several requirements are represented in Figure 1 (grey
rectangles with a folded corner on the top left hand side)
but the content of the figure will only be described in the
next section. As far as HCI aspects are concerned this
addition is very important as it makes it possible to
explicitly represent contributing factors to usability and
User eXperience (UX) and thus assess the relevance of
design options to them. The requested usability
requirements relate to the efficiency and effectiveness
factors of the system from an ISO 9241-11 perspective [
CASE STUDY
The application we chose allows a user to remove a set of
icons on a computer screen. It has first been used and
presented by Maurice H. ter Beek and al. to evaluate the
“Resilience of interaction techniques to Interrupts” [
Presentation An initial list of these requirements gathers functional needs and non-functional ones (mainly Usability and User eXperience). An extract of the set of usability requirements for this user interface are (“u” stands for usability requirement):
Ru1-The application shall support one interruption every 10 seconds Ru3-The application shall allow the user to clean the desktop in less than 30 seconds The set of user experience requirements for this user interface are (“ux” stands for user experience):
Rux1-80% of the users shall find the application easy
to use
Rux2-80% of the users shall find that interacting with
this application is surprisingly different
Given this list of requirements, evaluation criteria are
defined and linked to appropriate factors. The different
questions, options and design paths with regards to elected
criteria are consigned within the DREAM design rationale
tool. Figure 1 gives an overview of the design options
linked to requirements and evaluation criteria. Due to space
constraints, the schema has been shrunk, but several display
techniques for the tool are currently being studied for big
and complex diagrams. Rectangles show the requirements,
rounded-shape squares contain the design questions that
have been asked, right-angle triangles on the right side
describe factors and the other triangles describe criteria.
Each question has several possible options to address the
issue. For instance, as far as the interruption is concerned
(“How to display interruptions?”), the interruption can be
displayed as a “pop-up window” or as a “small icon
blinking” on one side of the display. In the TEAM mode,
the connection between these options and the four criteria
“File deletion error rate”, “Time to clean desktop”,
“Perceived manipulability” and “Perceived originality”
represents the relative impact of the option. The strong link
between the option “small icon blinking” and the “time to
clean desktop” criterion shows that it favors that criterion.
The right-hand side of the diagram makes explicit the
relationship between criteria and factors. Factors
correspond to desired characteristics of the system namely
“Usability” and “User eXperience”. They are in turn
decomposed into sub-factors; two out of the three
classical ones for usability i.e. “effectiveness” and
“efficiency” and two for “User eXperience” i.e.
“Pragmatic quality” and “Hedonic Quality Stimulation”.
Design options modeling
One of the issues that remain to be solved is how to assess
the options with respect to the connected criteria. For
instance, how to identify if the option “Mouse and
Speech” for the interaction technique is better than the
option “Enriched Drag and Drop” with respect to the
criterion “Time to clean desktop”. In order to address that
problem we propose to apply a model-based approach and
to define for each option a detailed behavioral description.
For that purpose we use the ICO notation [
Interpretation and benefits Once the design options have been assessed, DREAM model makes it easy to perceive which one (if any) has received the best evaluation. In addition it makes it explicit for this option which requirements it fulfils. Coming back to the importance of requirement engineering, DREAM diagram is a critical help to argue about, to select an option as well as to trace back the rationale underlying this selection. In our example, we see at a glance that the “Mouse and Speech” option is the best rated and that it fulfills the entire set of non-functional requirements. The final choice then belongs to the various stakeholders who have additionally direct access to the related requirements which, in turn, cannot be ignored. Furthermore, all the necessary information about the designed interactive system can be gathered and synthesized in one diagram. From a designer perspective, it can help to share conception ideas and materials. From another participant involved in the implementation and/or deployment process, it can be seen as an entry point to the designed system.
CONCLUSION This position paper argues that various models are useful for the design of interactive systems as they can complement each other and correspond to the needs of different stakeholders. We have presented a model-based approach for description within and single diagram requirements, design questions, design options, criteria and factors. This structured set of information supports different activities such as requirements traceability, design choices decision support and the traceability of design choices decisions. We have also presented how detailed behavioral description of advanced interaction techniques such as “Enriched drag and drop” or “speech and click” can be integrated within that framework to provide additional benefits. Of course such “intensive” model-based approaches require tools to support model construction, analysis, simulation, interpretation and reuse. The CASE tools supporting TEAM and ICO notation are publicly available [3 and 13] and are a corner stone of the applicability of the approach.