Comparing and Reconciling Usability-Centered and Use Case-Driven Requirements Engineering Processes

C o m p a r i n g and R e c o n c i l i n g U s a b i l i t y - C e n t e r e d and U s e C a s e - D r i v e n

R e q u i r e m e n t s E n g i n e e r i n g P r o c e s s e s

A. Seffah, R. Djouab and H. Antunes

Department of Computer Science, Concordia University

1455 de Maisonneuve Boulevard W. Montreal, Quebec, Canada H3G 1 M8

Telephone: (514) 8 4 8 - 3 0 2 4 - Mail: [email protected]

Abstract

During the two last decades, the human- computer interaction community has developed a large variety o f techniques and tools for gathering, specifying and validating usability requirements including user characteristics, tasks, work environment as well as usability goals such as effectiveness, efficiency and user satisfaction. Unfortunately, even i f their importance are accepted by software developers, they are not yet cost-effectively integrated into software engineering methodologies. This paper presents the rationale for our ACUDUC approach by identifying the different issues for enhancing the use case-driven software requirements approach with RESPECT, one o f the most advanced frameworks for user-centered requirements. Beyond this specific example (use cases and RESPECT), our investigations aim to reconcile user-centered and use case-driven requirements engineering and to cross-pollinate software engineering and usability engineering.

1. Introduction

Our work investigates how to integrate concerns for usability into the software development lifecycle. Many definitions of usability and frameworks for its engineering exist, making sometimes usability a confusing concept [2, 12, and 4]. According to ISO 9241 and ISO 9126 standards, two different definitions for usability are proposed.

The first one advocates a process-oriented approach to usability, whereby usable interactive systems are achieved as the result o f a human- centered design process. Usability as a high-level quality objective is defined in the ISO 9241-11

standard as: "The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context o f use". ISO 9241-11 support the following activities related to the user-centered design process:

Specification o f usability goal and metrics as well as evaluation against these requirements. (See ISO 9241-11 and ISO/IEC 14598-1)

Definition of activities necessary in the development lifecycle for achieving quality in use. The standard provides a framework for applying human-centered design and evaluation techniques, and is intended to supplement existing lifecycle models. In the second one, a product-oriented approach, usability is seen as one relatively independent contribution to software quality. Usability is defined in this way in ISO/IEC 9126 as: ",4 set o f attributes o f an interactive system that bear on the effort needed f o r use and on the individual assessment o f such use by a stated or implied set o f users". This definition can be used o specify details of the look and feel as well as the behavior of the user interface.

Our proposed ACUDUC (Approach Centered on Usability and Driven by Use Cases) is process- oriented framework that aims to unite:

The use case-driven requirements process defined in the object-oriented software engineering methodology [8] and recently reengineered as part as of the Unified sot%ware development Process (UP) [7], and The user-centered requirements process defined in the RESPECT framework (REquirements SPECification in Telematics [11]. The RESPECT process is a concrete

implementation o f the ISO 13407 standard on human-centered design process for interactive systems.

2. B a c k g r o u n d and Related W o r k

The following investigations show that the philosophy o f the use case-driven software development a p p r o a c h [7] is highly compatible with the user-centered requirements techniques o f usability engineering. Most o f them suggest specific, yet powerful, enhancements to the use case-driven software development approach, particularly in the user requirements and usability specification chapters.

Artim [ 1 ] emphasizes the role o f task analysis by providing a user-centric view o f a suite o f applications, and then emphasizes use cases by providing each application with a method o f exploring user-system interaction and describing system behavior. Jarke [9] points out that scenarios are used in sotiware engineering as intermediate design artifacts in an expanded goal-driven change process. They provide a task- oriented design decomposition that can be used from many perspectives, including usability trade-off, iterative development and manageable software design object models. Mayhew [12] describes the overall usability engineering lifecycle and highlights some challenges that should be addressed for its effective integration in the object-oriented software engineering approach proposed by Jacobson [8]. Constantine [4] suggests that use ease specifiers first prepare lightweight use case model descriptions

( e s s e n t i a l use cases) that do not contain any implicit user interface decisions. Later on, the user interface designer can use these essential use cases as input to create the user interface without being bound by any implicit decisions. Nunes [13] proposes to annotate use cases using non- functional requirements at the level o f abstraction at which they should to be considered. Rosson [14] proposes combining the development o f tasks and object-oriented models, which are viewed as a refinement o f rapid prototyping and an extension o f scenario-based analysis. Krutchen [10] introduces the concept of a use c a s e s t o r y b o a r d as a logical and conceptual description o f how a use case is provided by the user interface, including the interaction required between the actor(s) (user) and the system.

3. C o m p a r i n g U s e r - C e n t e r e d w i t h Use

Case-Driven requirements Processes

3.1. Capturing Functional Requirements

in UP Process

The goals of the requirements workfiow, as defined in the UP, are to describe what the system should do in terms o f functionalities, and allow the developers and the customer to agree on this description. This UP workflow offers a systematic and intuitive way for gathering the functional requirements, with a particular focus on the value added to each individual or external system. The main activities described in the use case-driven requirements workflow, part o f the unified developmem process, are as follows [7]:

Develop the vision document, which identifies the high-level user or customer view o f the system to be built. In the vision document, initial requirements are expressed as key features the system must have in order to solve the more critical issues. Understand the needs o f stakeholders, and future users.

Structure the use case model Detail the use case model

Model and prototype the user interface Prioritize the use cases for implementation This process captures also the non-functional requirements to a certain extent. This includes user characteristics that cannot be associated with any particular use case. The authors o f the Rational UP process suggest that the non- functional requirements presented in the IEEE 610.12.1990 standard can be described in this document [7]. This is one o f the major weaknesses of use case-driven requirements that user-centered requirements approaches can substantially improve.

This process is supported by several techniques for gathering requirements such as interviews, questionnaires, brainstorming, use case workshops, storyboarding, role-playing and reviewing existing requirements. The use case diagram is the most important requirements artifact. It is used as starting point for building an object-oriented model. Other requirements artifacts related to usability and the interface aspects are:

- Additional requirements, which are primarily non-functional requirements Use case storyboarding, which is a logical and conceptual description o f how use cases are provided by the user interface, including the required interaction between the actor(s) and the system. Storyboards represent a high-level understanding o f the user interface, and are much faster to develop than the user interface itself. Use case storyboards can thus be used to create and evaluate several versions o f the user interface before it is prototyped, designed and implemented [ 10]

- User interface prototypes

3.2. C a p t u r i n g C o n t e x t o f U s e in R E S P E C T P r o c e s s

The R E S P E C T process is based on the iterative human-centered design process for interactive system outlined in the ISO-13407 standard [11]. R E S P E C T collects and generates user requirements under a series o f semi-structured text forms. It distinguishes three iterative phases: user context and early design, prototype and user tests, and user requirements documentation. Each

User:~ ;i ; i.}..'.~ .~ ~::~,..' !, : :.;, " .~... 1. User inserts card for identification purposes. 2. User enters PIN or presses finger on

fingerprint pad.

3. User selects "Withdraw Cash"

4. User selects or enters amount up to the maximum.

5. User selects "Exit System"

o f these phases brings to light the following activities:

Understanding the user and organizational needs for a system, and planning the user- centered design process

Understanding the user context, also known as the context o f use

Specifying user and organizational requirements

Developing design concepts or operational prototypes

Testing whether the prototype meets the user and organizational requirements

By the end o f the third phase, the RESPECT process produces twelve text-based forms. These forms detail the general system characteristics, organizational structure, task scenario and interaction steps required to carry out key end- user tasks, technical environment, system functions and features, user interface design, user support, physical, social and organizational environments, standards and style guides to apply, usability testing plan, as well as implementation plan. Table 1 describes the scenario and interaction steps form required to carry out k e y end-user tasks.

System ~':.-: ;.i :,, . . . ::..:.":i .i ..:: . ...: 1. System reads card, regardless o f how inserted,

and displays message prompt.

2. I f recognized, system displays options.

3. System displays the m a x i m u m withdrawal and other possible amounts.

4. System responds that the cash is ready and displays menu o f other services.

5. System returns card and dispenses cash. Table 1. Task Scenarios and Interaction Steps

To facilitate the elicitation and validation o f user requirements, several usability techniques are suggested. A m o n g them, we list brainstorming, interviews, surveys, observation, focus groups, group discussion, task analysis and allocation, storyboarding, paper, video and rapid prototyping, scenario building, walkthroughs and wizard o f Oz prototyping.

3.3. C o m p l e m e n t a r i t i e s a n d F o u n d a t i o n o f A C U D U C

While use case artifacts generally describe

functional requirements including details needed by the software developers, R E S P E C T enhances functional requirements descriptions by adding information that improves the users' understanding o f the future system. Basically, this additional information concerns the context o f use and takes into account usability problems that m a y be encountered by end-users when performing certain tasks.

Table 2 summarizes the complementarities that we identified and the ways that A C U D U C reconciles them.

U s e r - C e n t e r e d R e q u i r e m e n t s Process

RESPECT captures a complete description o f the context o f use and usability goals/metrics, including user characteristics, task analysis, as well as the physical, technical and organizational environments in which the system will be used.

_

_

Use C a s e - D r i v e n R e q u i r e m e n t s Process

Although in theory use cases have the potential to gather the non-functional requirements that are a simplified description o f the context of use, in practice, use cases have been used for gathering the system functionalities and features including technical capabilities and constraints.

ACUDUC defines context o f use and functional requirements as two views o f the same shared requirements picture.

The functional view on this picture is a set o f artifacts describing the functional requirements. The usability view is a set o f artifacts describing the context o f use and the usability goals/metrics in which the functionalities will be used.

The context o f use is described using a non- [ formal notation that is easy to understand by

I

users and stakeholders alike. However, these forms are a cause for inconsistency and ambiguity when used by software . .developers. 3- ACUDUC supports Artim's [1] opinion of"onq

The artifacts that are produced and the semi-formal notation used are familiar and understood by software developers. It can also support automatic validation o f the functional requirements

model, but many views and notations." We strongly share his belief that different notations for the same concept may foster communication between all the persons involved in the requirements process.

4- In ACUDUC, the artifacts related to the context o f use should be described using text-based forms or any other information notation. Functional requirements artifacts are manipulated using the use case model.

5- ACUDUC should mediate the communication between the individuals involved in the requirements process: users, stakeholders, and software and usability engineers. It should maintain the correspondence between the two views o f requirements.

The context o f use is used by usability specialists " The functional requirement artifacts are used by as an important input for usability testing, software developers as a starting point for design. 6- ACUDUC includes activities for reviewing and validating the integrity and consistency of all

requirements artifacts from both the usability and developers' perspectives. It then generates portfolios called usability and implementation plans.

Table 2. The Foundations o f ACUDUC

4. K e y s A c t i v i t i e s o f t h e A C U D U C F r a m e w o r k

The ACUDUC approach distinguishes four steps for integrating context o f use and usability techniques in the use case-driven requirements lifecycle:

1- Summarizing the system from the user's perspective.

2- Gathering and specifying the context o f use 3- Specifying and/or generating functional

requirements including UI widgets and use

c a s e s

4- Reviewing and validating an integrated picture o f requirements

These steps were defined and validated through various industrial projects. All the projects are related to Internet-based interactive systems. They were conducted at the Computer Research Institute o f Montreal (CRIM) with industry partners. The requirement specification step always involved a group comprised of:

- Usability engineers - those who specify the context o f use and conduct usability requirement reviews and testing sessions. - Software developers - those who detail the

specification o f the system's functionalities and develop the use case model and the user interface prototype.

- Users - those who use the system. They may be the direct users (generally called end- users) who use the system to complete their tasks, or indirect users who use it for other

purposes, such as system administrators, installers and demonstrators. Even if the cause-effect relationship b e t w e e n usability p r o b l e m s and indirect users' j o b s can be easily demonstrated, indirect users' requirements are most often neglected in both software and usability engineering approaches. For example, a system whose installation is not e a s y to understand will be incorrectly installed in terms o f user preference and specific need. This will be source o f m a n y usability problems.

Stakeholders - those who are affected by the system or can influence its development, such as marketing staff and purchasers. Their input is mainly used as constraints or additional requirements. For example,

marketing staff may like to add to the system a specific function that another company is planning to implement. In m a n y projects, we observed that such functions are more a source o f distraction and ambiguities for users than added values. Consequently, functions such as these are classified in specific category in the requirements.

Each o f these contributors is characterized by its role and responsibilities. Roles are expressed in terms o f the activities the contributor performs, and each contributor is associated with a set o f activities. The responsibilities o f each contributor are usually expressed in relation to certain artifacts that the contributor creates, modifies or controls [Figure 3].

I

Users [ Summarizing the Stakeholders ] System Usability I Engineers Software D e v e l o p e r s II

Gathering and specifying : =.. __ the context o f use

I!

Specifying and/or generating ~ .- functional requirements Requirement Artifacts : : = ~ System _ ~ - I Summary : : : : - - , - , . : : 1 1 . [ Context o f ] .. : m ~ . - . ~ : z : l l

unc ona' I

Figure 3. Relationships b e t w e e n Requirement Artifacts, Contributors and Activities in A C U D U C 4.1 S u m m a r i z i n g t h e S y s t e m f r o m t h e

U s e r ' s P e r s p e c t i v e

It is important for usability-to-software engineering collaboration and for consistency and coherence o f ease o f use and functional requirement artifacts to gain a high-level understanding o f the system from the end users perspective. Therefore, A C U D U C starts when a representative set o f users and/or stakeholders are invited to summarize the system from the future u s e r ' s perspective. T h e y are mainly asked to answer different questions that we organized

in a system summary form [Figure 4]. Maguire [11] and Constantine [4] suggested similar questions. Users and stakeholders, the main contributors during this step, are invited to give b r i e f answers to these questions. All completed forms are then analyzed and compiled in a unique system summary form by usability engineers. This compiled form is approved b y software developers, stakeholders and users. It is used as a roadmap during the requirement process and represents a general consensus on the system.

Question

What is the purpose o f the system? W h y is this system necessary?

Assumptions

ISO 9000-based quality system over an Intranet

Who will use the system?

What will the users accomplish with the system?

Where will the system be used?

How will users learn to use the system? How will the system be installed? How will the system be maintained?

country (new clients, remote offices.)

Employees a n d some o f the company "s clients Access to quality procedures a n d associated f o r m s Learn the quality system and the 1 S 0

90.00

By a Webmaster f o r the server version, and by employees on their PDA (download f r o m the server)

By a Webmaster and a quality control manager

Table 4. An Example o f the System Summary Form

4.2. G a t h e r i n g a n d V a l i d a t i n g t h e

C o n t e x t o f U s e P o r t f o l i o

Organizational, technical and physical environments.

The context o f use portfolio describes all the aspects that have an important impact on the system usability including [Table 5]:

User characteristics o f each group o f direct and indirect users.

Task description form including goals, frequency and duration. Task flowchart [5] may be used instead o f this form.

The context o f use portfolio includes also a description o f usability goals such as effectiveness, efficiency and satisfaction, quantitative/qualitative metrics such as required user performance and satisfaction, as well as guidelines and usability patterns to which the user interface should conform.

Form Main Information

User characteristics

Characteristics o f tasks that users will perform

Work environment in which the system will be used.

Knowledge, skill, experience, training, physical attributes, habits and motor-sensory capabilities

Goals, frequency and duration o f tasks

- Organizational attributes including structure o f the operational teams, individual staff members' level o f autonomy, business process

- Technical platform and constraints including hardware, operating systems, network, and software on which the new system depends - Physical factors including potential health, safety and security

issues if applicable Table 5. Summary o f Context o f Use Portfolio

4.3. S p e c i f y i n g F u n c t i o n a l R e q u i r e m e n t s

The functional requirements portfolio include the following artifacts use cases, system functionalities, characteristics and constraints as well as UI prototypes.

Our investigations have shown that it is possible to generate some functional requirements artifacts from the context o f use artifacts. This is true for the use case diagram and UI widgets. If this generation can be automated, it will certainly bridge the gap between context o f use artifacts and functional requirements. At the same time, it

will improve the communication between soft-ware and usability developers.

T o illustrate this fundamental result, let us consider a substantial real-world example for which we have attempted to write a use case diagram that would reproduce the task descriptions described by usability engineers. The task analysis was conducted by usability engineers with hopes o f computerizing the handling o f "psychological/social" requests at a community health center in Quebec, Canada. The task load o f social workers at a health center involves a considerable amount o f

c o m m u n i c a t i o n with others (the requestor, the patient and fellow healthcare professionals.). Table 6 describes the Handling a Request task. Use cases and specifications o f tasks both describe the task in different ways. Beside tasks and use cases, which have nearly the same meaning in both a p p r o a c h e s there, we listed the following ways that a task analysis m o d e l can c o m p l e m e n t a use case model:

U s e r characteristics form can be used to p r o v i d e further information about actors Technical, physical and organizational e n v i r o n m e n t s forms can be used to describe the c o n t e x t o f use related to a use case diagram

CLSC Task 1: Handling a Request

C L S C Task 1.1: Receive R e q u e s t / * b y telephone or in p e r s o n * / C L S C Task 1.1.1: Get Details o f Request

C L S C Task 1.1.1.1: Situate the Request

C L S C Task 1.1. I. 3: Evaluate the R e q u e s t ' s Urgency

C L S C Task 1. I. 1.5: Identify Special Elements o f the Request C L S C Task 1.1.4: R e s p o n d to an Immediate Request

C L S C Task 1.2: Evaluate Urgency o f Request /*this task is usually carried out by a single individual a n d can extend over several sessions*/

CLSC Task 1.2. 4: Identify Solutions

S a l u a t e U r g e n c y o f ~

wo er

Table 6. T a s k Analysis and Use Cases Diagram

5. C o n c l u s i o n

In this paper, we presented the rationale behind the A C U D U C a p p r o a c h and our understanding o f how to integrate usability in the use-case driven software d e v e l o p m e n t lifecycle. With respect to experimentation, two specific processes constitute the focus o f our interests: use case-driven and the u s e r - c e n t e r e d requirements engineering processes. Further to

the A C U D U C f r a m e w o r k we defined, we identified the following principles which we c o n s i d e r as fundamental enhancements to the functional r e q u i r e m e n t lifecycle.

First, the requirements o f an interactive system must be defined on two levels, but not i n d e p e n d e n t l y o f one another. T h e first level is c o n c e r n e d with the specification o f the context o f use, and the second focuses on functional

requirements. Different specification notations m a y be used for the t w o levels, but they should exploit an integrated representation o f all the requirements artifacts. In our case, we elected to use text-based forms from R E S P E C T and the graphical representation o f use cases as defined in Unified M e t h o d L a n g u a g e [7].

Secondly, the list o f artifacts describing the context o f use ensures a g o o d usability specification. Better still, this list can assist with generating functional requirements, at least to a limited extent. This result is fundamental because it can minimize requirements artifacts inconsistency and improve communication between software and usability engineers.

Thirdly, the classification o f the contributors that we established clarifies roles and responsibilities o f each contributors. Furthermore artifacts such as the system summary form are a simple and effective way to maintain a quasi-permanent consensus between p e o p l e that do not speak the same language and p r e f e r to use different notations.

O u r work to date has addressed two o f the three m a j o r issues for reconciling use case and usability driven approaches namely, what artifacts should be developed, and what activities should be p e r f o r m e d to d e v e l o p the artifacts. W e have yet to address the third issue o f h o w to facilitate human-to-human collaboration amongst the users, stakeholders, usability engineers, and software engineers during the process.

6. References

[1] Artim, J. et al. "Incorporating work, process and task analysis into industrial object-oriented systems

development," SIGCHI Bulletin, 30(4), 1998.

[2] Bevan N. and Azuma M. "Quality in Use: Incorporating Human Factors into the Software Engineering Lifecycle," proceedings o f the Third IEEE International Software Engineering Standards Symposium and Forum, 1997.

[3] Cockbum, A. "Structuring Use Cases with Goals." Journal of Object-Oriented Programming, Sept-Oct 1997 and Nov-Dec 1997.

[4] Constantine, L.L. and Lockwood, L.A.D. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Reading, Massachusetts: Addison-Wesley, 1999.

[5] Dayton, T., McFarland, A, and Kramer, J. "Bridging User Needs to Object-Oriented GUI Prototypes via Task Object Design," in User Interface Design, Wood, L. (Editor), CRC Press, 1998.

[6] ISO/DIS 13407 Standard: Human Centered Design Processes for Interactive Systems, 1998.

[7] Jacobson I., Booch G., and Rumbaugh, J. Unified Software Development Process. Reading, Massachusetts: Addison-Wesley, t 999.

[8] Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison- Wesley Object Technology Series, Reading, Massachusetts: Addison Wesley, 1994.

[9] Jarke, M., "Scenarios for Modeling," Communications of the A CM 42( 1 ), 1999.

[10] Krutchen, P. "Use Case Storyboards in the Rational Unified Process," Workshop on Integrating Human Factors in Use Case and OO Methods. 12 th European Conference on Object-Oriented Programming. Lisbon, Portugal, June 14-20, 1999. [11] Maguire, M.C. RESPECT User Centered Requirements Handbook, EC Telematics Applications Program, Project TE 2010 RESPECT, Wp5 Deliverable D5.3, 1998.

[ 12] Mayhew, D.J. The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design, Morgan Kaufmanns Publishers,

1999.

[13] Nunes, N. "'A bridge too far: Can UML finally help bridge the gap?" Proceedings of INTERACT'99 Doctoral Consortium, Edinburgh, Scotland, 1999. [14] Rosson, M.B. "Integrating Development of Tasks and Object Models." Communications o f the ACM, 42(1) 1999.

[15] Seffah, A., Hayne, C. "Integrating Human Factors in Use Case and OO Methods," 12 th European Conference on Object-Oriented Programming Workshop Reader, Lecture Notes in Computer Science 1743, 1999.