Usage-Centered Design and Software Engineering:

Models for Integration

Larry Constantine Robert Biddle James Noble

Constantine & Lockwood, Ltd. Victoria University of Victoria University of
University of Technology, Wellington (New Zealand) Wellington (New Zealand)
Sydney (Australia) [email protected] [email protected]
[email protected]

Abstract
2. Designing the Human Interface
This paper argues for a model-driven framework for
integrating human interface engineering with software Responsibility for human interface design, while
engineering. The usage-centered design process, a robust eschewed by software engineering, is claimed by a
and proven process grounded in software engineering, is number of professions with varying perspectives.
briefly described and contrasted with traditional user- Terminology is often marked by vehement debate over the
centered approaches. The connections between the core professional responsibilities of graphic designers versus
models of usage-centered design and their software visual designers or the distinctions between user interface
engineering counterparts are outlined, and the design and interaction design or the precise domain
advantages of this approach to bridging the gap are covered by information architecture.
discussed. In the final analysis, however, the engineering of the
interfaces between humans and software requires solving
1. Introduction design problems in three intimately interrelated areas:
architecture, presentation, and interaction. The
All software ultimately serves human needs and architecture of the interface refers to the overall and large-
interests, hence provision for effective interaction between scale organization of the interface, that is, the way in
human users and software would reasonably be expected which the interface as a whole is partitioned into distinct
to be integral to all software engineering. Such has not and recognizable regions or parts, how these parts are
been the case, historically. Until recently, software related and interconnected, and how the user navigates
engineering methods and practice have focused primarily among these parts. Presentation design addresses the
or exclusively on the internal structure and functioning of specification of how information is presented to users by
computer programs, leaving the interaction with users and visual, audible, haptic, or other means. In conventional
the user interface that supports that interaction to other graphical user interfaces, presentation design involves the
disciplines and professionals. For its part, the human- selection and design of visual elements as well as their
factors community has shown relatively little interest in layout within and distribution among the various parts of
the problems of software engineering as such. the user interface, as well as details of appearance, such
Recent years have seen an upsurge in interest in as, color and shape. Interaction design addresses the
narrowing the gap between human-computer interaction specification of the means by which users interact with a
(HCI) and software engineering (SE) perspectives, system and includes the organization of discrete steps in
particularly in regards to object-oriented methods [1]. The processes, the selection or specification of gestures or
gap is, of course, multifaceted, with differences relating to idioms for interaction, the sequencing of actions, and
historical evolution, training, professional orientation, and workflow.
technical focus, as well as in methods, tools, models, and These three aspects of interface design interact strongly
techniques. Although the academic, research, conceptual, and are ultimately inseparable, even if some designers and
and professional aspects of this gap are interesting in their methods strive to address them independently. The choice
own right, in this paper we shall focus on pragmatic of a particular selection component, for example, implies
matters in integrating the means and methods by which constraints on appearance and forms of interaction with
software, with its human interface, is engineered. effects on both layout and the use of “screen real estate,”
which in turn may impact what features can be combined and even in some cases under the rubric of user-centered
within a single part of the interface and which must be design [15, 16].
separated. The tensions between software engineering and user-
While we are keenly aware that others have used other centered methods are widely recognized [17]. An
terms and definitions, in this paper we will use the term emphasis on thorough investigation and extensive field
human interface engineering in preference to user observation, particularly in ethnographic approaches,
interface design and will consider it to embrace the three combined with repeated cycles of prototyping and user
areas of interface architecture, presentation design, and feedback, leads to a substantial, often unpredictable,
interaction design. analysis and design commitment that typically must
Ultimately, any integrated approach must not only precede software design and development. Usability
address these three areas but also the design of the testing, a cornerstone of user-centered approaches,
supporting software as such. In the usage-centered typically comes late in the development cycle when its
software engineering approach described in this paper, a findings are all too often ignored or deferred for later
single set of models forms the basis of integration and releases, especially when testing uncovers architectural
coordination of human interface and software engineering. defects or problems in the basic organization of the user
interface.
3. Usage-centered or user-centered? Usage-centered design differs from its older and better
established counterpart in several important ways. As the
Usage-centered design [2, 3] is a systematic, model- name suggests, the center of attention is not users per se
driven approach to human interface engineering for but usage, that is, the tasks intended by users and how
software and Web-based applications. Beginning with these are accomplished. This difference in emphasis is
early work on task modeling based on use cases [4, 5], it reflected in differing practices that have a significant
has evolved into a sophisticated process that has proved impact on the development life cycle and on integration
itself on projects of widely varying scope and scale in a with software engineering. Table 1 summarizes salient
variety of application areas [3, 6, 7, 8, 9]. Because of its differences in the two approaches.
focus on designing software for use based on robust task Unlike user-centered design, whose methods and
models, the approach has proved particularly effective in traditions are firmly rooted in the human factors and
delivering innovative—even award-winning—designs that human-computer interaction world, usage-centered design
both enhance performance and are easily learned [9, 10, is grounded in a strong engineering orientation reflecting
11]. the background of its co-developers, including one of the
Usage-centered design can be distinguished from the early pioneer software methodologists (Constantine).
more widely recognized and practiced user-centered Usage-centered design emerged directly from software
design [12]. In one form or another, the latter has become engineering and particularly from object-oriented software
the dominant design philosophy of human-computer engineering [18]. Precisely because usage-centered design
interaction. As one indication of this dominance, a Google is built around extensions and refinements to well
search on user-centered design yields over 74,000 hits, in established software engineering models and techniques,
contrast to about 2,000 hits for usage-centered design. such as actors and use cases [19], integration with
Nevertheless, the application and influence of usage- software engineering is more straightforward.
centered approaches has grown steadily, and its core Perhaps the most fundamental difference is in the basic
concepts and techniques have been incorporated into other organization of the design process itself. Underlying much
methods, including the Rational Unified Process [13, 14] of user-centered design as practiced is a view of user

Table 1. Salient Differences between User-Centered and Usage-Centered Design

User-Centered Design Usage-Centered Design
Focus on users: Focus on usage:
user experience, user satisfaction improved tools supporting task accomplishment
Driven by user input Driven by models
Substantial user involvement: Selective user involvement
user studies, participatory design, user feedback, user testing exploratory modeling, model validation, structured usability
inspections
Descriptions of users, user characteristics Models of user relationships with system
Realistic or representational design models Abstract design models
Design by iterative prototyping Design through modeling
Varied, often informal or unspecified processes Systematic, fully specified process
Evolution through trial-and-error Derivation through engineering
interface design as a process of successive approximations models are connected in a logical sequence, in reality
wherein a final solution emerges principally through experienced practitioners develop them concurrently,
repetitive cycles of trial design alternated with user testing moving from model to model as information and insight
and feedback. Although the profession may be loathe to emerge and as the needs of project management and
admit it, such approaches are appropriately described as problem solving dictate. In addition, the process divides
design by trial-and-error. into concurrent but interdependent threads, one primarily
In contrast, usage-centered design is conceived as an focused on designing the human interface, and the other
integrated concurrent engineering process aimed at primarily focused on designing the internal software.
producing an initial design that is essentially right in the A number of variants to this process and its models
first place. This is not to say that refinement and have been devised to suit various contexts and varying
improvement through evaluation and feedback are not degrees of formality, ranging from highly structured forms
employed, but these are not the driving forces in the [2, 9, 20] to agile design for Web-based applications [3,
design process. Instead, usage-centered design is driven 21], and even incorporation with extreme programming
by interconnected models from which a final visual and [22].
interaction design are derived more or less directly by In lieu of more unstructured or open-ended
straightforward transformations. Iterative refinement investigation typical of contextual inquiry or other
applies more to the models from which the final design is ethnographic techniques, a model-driven process is used
derived than to the design. even for problem definition and requirements gathering.
In this exploratory modeling [23] (not shown in the
4. The usage-centered design process diagram), questions and areas for investigation are
identified by constructing provisional user role and task
The process, outlined schematically in Figure 1, is models based on whatever background information or
based on concurrent engineering. Although the core knowledge is at hand. Limited, sharply focused inquiries,

AAesthetic
estheticBBrief/
rief/ Interface
InterfaceStyle
Styleand
andStandards
StandardsGuidelines
Guidelines
G raphic D esign
GraphicDesign Help and Documentation
Help and Documentation
CREATIVE Operational HUMAN INTERFACE
OperationalModel
Model(environmental
(environmentaland
andcontextual
contextualfactors)
factors)
DESIGN PRESENTATION
AND INTERACTION
User
UserRoles
Roles Task
Task Cases
Cases Abstract
Abstract DESIGN
PRODUCT doing2 Prototypes
Role3 Prototypes
DEFINITION Role1 doing1 Context1 Behavior
Role2
PProduc
roductt Role
RoleMap
Map Task
TaskCase
Case
Context2
Navigation
Navigation
Step1 Step2

FFram
ramewework
ork Map Map R
Map Map Context2 1. Asdhfepasdf
res
U ser & doing1
Probzc ent
User & Role3 2. Wertwrt a
3. Ouiaaerototyp tional
CCustom
ustomerer Role2 doing2 Context1
es
PProfiles
rofiles Role1

FFeatures,
eatures, ROLES TASKS CONTENTS
FFunc
unctions,
tions,
&&C Content
ontent Domain
DomainModel
Model(glossary,
(glossary,class
classmodel,
model,data
datadictionary,…)
dictionary,…)

Class
ClassModel
Model
System
System System
System Sequence
Actors Use Task-Case Sequence
Actors UseCases
Cases Diagrams
Diagrams
Actor2
case1 Responsibility-
case2
case3
Driven Design
Actor1
SOFTWARE
DESIGN
user review/feedback, inspection/evaluation, or audit/validation
Figure 1. Schematic Outline of Usage-Centered Design Process
observation, surveys, or investigations are then conducted of actions…that a system…can perform by interacting
to answer questions, resolve ambiguities, and supply with outside actors” [24]. They are usually expressed in
missing information as identified through the exploratory terms of sequences of user actions and system responses.
modeling. For guiding human interface design, the focus on the
system and on concrete action and interaction proved to
4.1. Usage-centered models be problematic, leading to the development of task cases,
a more abstract form modeling user intentions rather than
Presentation and interaction designs, as is typical, are actions and system responsibilities rather than responses.
embodied as representational prototypes, that is, paper or An example is shown in Figure 2. Task cases, also known
other prototypes representing or approximating the actual as essential use cases, are expressed from the perspective
appearance of the user interface. Usually these take the of users in roles.
form of annotated drawings or renderings of screens,
pages, or other interaction contexts supplemented by Running Standard Test
descriptions of the behavior of the interface in narrative or USER INTENTIONS SYSTEM RESPONSIBILITIES
other convenient form, such as, flow charts or decision 1. show available
tables. standard tests
In the usage-centered process, the presentation and 2. pick test
interaction designs derive directly from the contents of the 3. optionally
three tightly integrated core models: a user role model, a [modify test] } 4. show test
user task model, and an interface content model. Although
some form of user and task modeling is common to most configuration
user-centered approaches, usage-centered models are 5. confirm & start 6. run test
distinctive in the use of abstraction and simplification to 7. report results
focus precisely on matters most essential for informing the
design process.
4.1.1. User roles. Rather than modeling actual users or
Figure 2. A task case or essential use case.
user communities broadly, as is often the case with user-
centered techniques, the user role model focuses Because task cases are essential in the sense introduced
exclusively on salient aspects of the relationships between by McMenamin and Palmer [25]—that is, abstract,
users and the system as represented by the various roles simplified, generalized, and technology- and
users assume. In its simplest informal form, the role model implementation-independent—they come closer to the
describes context, characteristics, and criteria, that is, the essence of user needs than typical use cases, offering
context within which each role is assumed including the advantages for requirements modeling [26] and for
overall contextual purpose and responsibilities of the role, reducing the complexity of sophisticated systems [9]. The
the characteristics of interaction within the role, and advantages of abstraction and goal orientation in use cases
criteria for support of the role, such as specific functions are widely accepted [3, 27, 28, 29, 30].
or the relative importance of various design objectives. In practice, task case models are more fine-grained
Relevant characteristics of roles have been cataloged and than typical use case models for software engineering.
compiled into templates for structured modeling of user Increased granularity has advantages for user interface
roles [2]. In practice, a simple summary of context, design in exposing small, reusable tasks and in clarifying
characteristics, and criteria on an ordinary index card may the interrelationships among user tasks. This facilitates
suffice in many projects. For example, devising a more robust and flexible interface architecture
Routine-Test-Running Role that closely conforms to the underlying structure of user
CONTEXT: Unsophisticated but trained operator
task needs.
runs predefined standard tests with limited
4.1.3. Content models. User-centered designers
modification (under supervision).
typically move quickly into sketching paper prototypes,
CHARACTERISTICS: frequent, regular performance
but in usage-centered design, content modeling is used to
of relatively simple but crucial repetitive tasks.
first work out the architecture or overall organization of
CRITERIA: simple, efficient, error-free operation.
the interface and its subparts independent of their
4.1.2. Task cases. Developed originally by Ivar realization as actual interface components and apart from
Jacobson for his object-oriented methodology [18], use
the details of appearance and behavior. The interface
cases have become ubiquitous in modern software
content model consists of a set of abstract prototypes
engineering practice. As originally conceived and
representing the contents of the various parts of the user
conventionally employed, use cases comprise “sequences
interface and a navigation map representing the other users, are excluded, as they are part of the context
interconnections among all these parts. of user actors (direct users) and are not directly involved
Abstract prototypes [31] range from simple content with the user interface. User actors interact with the
inventories or lists of the contents of each part of the user interface within the roles they play in relation to the
interface to highly structured and formalized abstract system. A given actor may play in a number of different
prototypes based on canonical abstract components [32]. roles and the same role may be played by more than one
Abstract prototyping facilitates exploration and actor.
problem solving regarding the contents and organization Task cases support user roles. A given role typically
of the various component parts of the interface without requires a number of task cases, and a given task case may
having to plunge ahead into details of appearance and support multiple roles. On the software engineering side,
layout. In their preferred form, abstract prototypes are the picture is more straightforward: system actors are
constructed from a canonical collection of abstract supported by system use cases. Both task cases and system
components that allow for precise description of interfaces use cases become input for the object design, which must
in terms of form and function independent of details of support them all to meet requirements. However, many
appearance and behavior and that promote the recognition details of the required software may not be determined
of common patterns and problems in presentation and until the presentation and interaction design are complete.
interaction design. An example of a canonical abstract The presentation and interaction designs are based on
prototype is shown in Figure 3. abstract prototypes of the various interaction contexts and
the navigation map modeling the interrelationships among
distinct contexts. Particular user interface components
configuration display standard with specific behavior and appearance are chosen or
testing
designed to realize the abstract components.
Abstract components are incorporated into abstract
standard test list prototypes based on the particular tools and materials
needed to realize each step in those task cases to be
supported together within a given part of the user
reset modify interface. The partitioning of the total user interface into
subparts, as represented by the navigation map, is
! test status print STOP determined based on the interrelationships among task
(highlighted as needed) TEST cases. A task case map in its most specific form models
start inclusions, extensions, and specializations relating task
cases, but for many projects a clustering based on the
likelihood of task cases being used together suffices.
Figure 3. Example of an abstract prototype using The domain model, which captures the core concepts
canonical abstract components. of the application, is developed and refined concurrently
and collaboratively throughout the process and serves to
5. Interrelationships among models link the various design models. For example, object
classes referred to in the narrative body of task cases
In the process model of Figure 1, models form the correspond to those in the contents of abstract prototypes
bridge between human interface engineering and software on which the realized presentation and interaction design
engineering, providing traceability and interdependence are based. The domain model in turn maps to the internal
and serving as the means for coordinating concurrent object design.
processes. From this overview it should be clear that use cases, as
Software engineering typically begins with some form task cases or system use cases, form the common thread
of high-level representation of the system scope in terms that interconnects the various models and activities in the
of the system boundary and interfaces with the process. Indeed, task cases can directly guide the
environment. In the contemporary unified process and organization and contents of documentation and online
related methods, a use case diagram serves this purpose by help [2, 33], thus providing uniform and comprehensive
identifying all the actors interacting with the system. traceability throughout the delivered system.
An actor, as the term is used in UML and the UP, is
any entity that interacts with a system. For a usage- 6. Distributed responsibilities and software
centered approach, non-human actors, referred to as
system actors, are distinguished from user actors. Indirect For use within conventional object-oriented software
users, whose interaction with the system is mediated by engineering approaches, such as the Unified Process, task
cases (essential use cases) need to be transformed into responsibilities, and collaborations. For greater precision,
conventional or concrete use cases. Abstract narratives sequence diagrams can also be developed to clarify and
defined in terms of user intentions must be elaborated into detail responsibilities and collaborations.
a more complex and detailed “flow of events” that refers
to actual user actions in relation to the user interface as 7. Prospect
designed. In many situations, differences in granularity
require combining closely related task cases into a The usage-centered software engineering process
composite concrete use cases that incorporates many if not outlined here is not a proposal but an already well
all of the exceptional or alternative flows. Because this established “industrial strength” process that has proved
process of translation begins with task cases in the successful in numerous projects ranging up to 50+ person
abbreviated form understood by the human interface years completed by organizations around the world.
designers, the detailed concrete use cases needed for Current areas of continued investigation include
software engineering must be developed by the human refinement in notation, compilation and elaboration of
interface designers. Although this somewhat tedious patterns based on canonical abstract components [32] and
translation introduces an added step with its attendant task cases [26], and continued work on common theory
resource needs and opportunities for error, it has been and metrics, such as cohesion and coupling, underlying
used successfully on even very large projects [8]. both object design and human interface design [2, 37, 38,
The abstraction to intentions and responsibilities in the 39].
defining narrative of task cases suggests a possible more Perhaps most pressing is the need for tools that support
direct link to object-oriented software engineering by way usage-centered software engineering by incorporating its
of responsibility-driven design [34] and so-called CRC models and exploiting their interconnections for flexible
cards [35], both of which employ the concept of concurrent modeling and systematic requirements tracing.
responsibility to guide software design decisions. Indeed, The dominance of contemporary software engineering
as has been noted [26], the role of responsibility in task standards, in particular UML [24], is itself an impediment,
cases is entirely consistent with the role of responsibility as UML lacks constructs for user roles, task cases, and
in software design. Both describe behavior without interface contents, forcing practitioners and process
describing implementation, a commonality that enables mentors to emulate the needed models in a procrustean
linking the methods for determining requirements, for bed constructed of UML “stereotypes” that are ill-suited
designing human interfaces, and for designing software. to the purpose [13].
The distributed responsibility technique [26, 36]
developed at Victoria University of Wellington takes task 8. References
cases and system use cases in the same essential form as
used for requirements definition and human interface [1] van Harmelan, M. Object Modeling and User Interface
design and uses them to drive the derivation of an object- Design. Addison-Wesley, Boston, 2001.
oriented design. This technique has several demonstrated
advantages. The abstraction and brevity of essential use [2] Constantine, L. L., and Lockwood, L. A. D. Software for
cases allows a more agile start to early object modeling Use: A Practical Guide to the Models and Methods of Usage-
and makes possible conducting object modeling and user Centered Design. Addison-Wesley, Reading, MA, 1999.
interface design in parallel. The key role of responsibility
[3] Constantine, L. L., and Lockwood, L. A. D. “Usage-Centered
in both task models and object models supports
Engineering for Web Applications.” IEEE Software, 19 (2),
traceability between the two models, as well as providing March/April. 2002.
better operational guidance to developers and facilitating
review processes in design evaluation. [4] Constantine, L. L. “Essentially Speaking.” Software
The iterative process begins with a system object, a Development, 2 (11), November 1994.
single class whose responsibilities are those identified as
system responsibilities in the task cases and system use [5] Constantine, L. L. “Essential Modeling: Use Cases for User
cases, which means the design is guaranteed to provide Interfaces,” interactions 2 (2), March/April 1995..
the behavior specified in the requirements. In successive
[6] Anderson, J., Fleek, F., Garrity, K., and Drake, F.
iterations, additional classes are identified as suggested by
“Integrating Usability Techniques into Software Development.
repeated terms within the class responsibilities or by IEEE Software, 18 (1), January/February, 2001.
virtue of their inclusion in the evolving domain model.
As classes are identified, responsibilities are delegated [7] Patton, J. “Extreme design: Usage-Centered Design in XP
and the resulting provisional model is checked for and Agile Development.” In L. Constantine (Ed.), forUSE 2002:
reasonableness and refactored as appropriate. CRC cards Proceedings of the First International Conference on Usage-
are often used as convenient tools for representing classes,
Centered, Task-Centered, and Performance-Centered Design. (Ed.), forUSE 2002: Proceedings of the First International
Ampersand Press, Rowley, MA, 2002. Conference on Usage-Centered, Task-Centered, and
Performance-Centered Design. Ampersand Press, Rowley, MA,
[8] Strope, J. “Putting Usage-Centered Design to Work: Clinical 2002.
Applications.” In L. Constantine (Ed.), forUSE 2002:
Proceedings of the First International Conference on Usage- [21] Constantine, L. L. Process agility and software usability:
Centered, Task-Centered, and Performance-Centered Design. Toward lightweight usage-centered design. Information Age, 8
Ampersand Press, Rowley, MA, 2002. (8), August 2002. Also in L. Constantine (Ed.), Beyond Chaos:
The Expert Edge in Managing Software Development. Addison-
[9] Windl, H. “Designing a Winner: Creating STEP 7 Lite with Wesley, Boston, 2001.
Usage-Centered Design.” In L. Constantine (Ed.), forUSE 2002:
Proceedings of the First International Conference on Usage- [22] Patton, J. “Extreme Design: Usage-Centered Design in XP
Centered, Task-Centered, and Performance-Centered Design. and Agile Development. In L. Constantine (Ed.), forUSE 2002:
Ampersand Press, Rowley, MA, 2002. Proceedings of the First International Conference on Usage-
Centered, Task-Centered, and Performance-Centered Design.
[10] Windl, H., and Constantine, L. “Performance-Centered Ampersand Press, Rowley, MA, 2002.
Design: STEP 7 Lite.” Winning submission, Performance-
Centered Design 2001, http://foruse.com/pcd/ [23] Windl, H. “Usage-Centered Exploration: Speeding the
Initial Design Process.” In L. Constantine (Ed.), forUSE 2002:
[11] Constantine, L. L., and Lockwood, L. A. D. “Instructive Proceedings of the First International Conference on Usage-
Interaction.” User Experience, 1 (3), Winter 2002. Centered, Task-Centered, and Performance-Centered Design.
Ampersand Press, Rowley, MA, 2002.
[12] Norman, D. A., and Draper, S. W. User-Centered System
Design. Erlbaum, Hillsdale, NJ, 1986. [24] Rumbaugh, J., Jacobson, I., and Booch, E. G. The Unified
Modeling Language Reference Manual. Addison-Wesley,
[13] Heumann, J. “Use Cases, Usability Requirements, and User Reading, MA, 1999.
Interfaces.” Tutorial Notes, OOPSLA 2002, 4-8 November.
ACM, New York, 2002. [25] McMenamin, S. M., & Palmer, J. Essential Systems
Analysis.: Prentice Hall, Englewood Cliffs, NJ, 1984.
[14] Kruchten, P., Ahlqvist, S., and Byland., S. “User Interface
Design in the Rational Unified Process.” In M. van Harmelen, [26] Biddle, R., Noble, J., and Tempero, E. “From Essential Use
ed., Object Modeling and User Interface Design. Addison- Cases to Objects.” In L. Constantine (Ed.), forUSE 2002:
Wesley, Boston, 2001. Proceedings of the First International Conference on Usage-
Centered, Task-Centered, and Performance-Centered Design.
[15] Scanlon, J., and Percival, L. “User-Centered Design for Ampersand Press, Rowley, MA, 2002.
Different Project Types, Part 1: Overview of Core Design
Activities.” IBM DeveloperWorks, March 2002. [27] Cockburn, A. "Structuring Use Cases with Goals," Journal
ftp://www6.software.ibm.com/software/developer/library/us- of Object-Oriented Programming, September/October 1997 and
ucd.pdf November/December 1997.

[16] Percival, L. and Scanlon, J. “User-Centered Design for [28] Graham, I.(1996) “Task Scripts, Use Cases and Scenarios
Different Project Types, Part 2: Core Design Activities by in Object-Oriented Analysis,” Object-Oriented Systems 3 (3),
Project Types.” IBM DeveloperWorks, March 2002. 1996.
ftp://www6.software.ibm.com/software/developer/library/us-
ucd2.pdf [29] Kaindl, H. “An Integration of Scenarios with Their
Purposes in Task Modeling.” Proc. Symposium on Designing
[17] McCoy, T. “Letter from the Dark Side: Confessions of an Interactive Systems. ACM Press, Ann Arbor, 1995.
Applications Developer. interactions 9 (6), November/December,
2002: 11 - 15. [30] Lee, J., and Xue, N. “Analyzing User Requirements by Use
Cases: A Goal-Driven Approach.” IEEE Software, 16 (4)
[18] Jacobson, I., Christerson, M., Jonsson, P., and Övergaard, July/August 1999.
G. Object-Oriented Software Engineering: A Use Case Driven
Approach. Addison-Wesley, Reading, MA, 1992. [31] Constantine, L. L. “Rapid Abstract Prototyping.” Software
Development, 6, (11), November 1998. Reprinted in S. Ambler
[19] Constantine, L. L., and Lockwood, L. A. D. “Structure and and L. Constantine, eds., The Unified Process Elaboration
Style in Use Cases for User Interface Design.” In M. van Phase: Best Practices in Implementing the UP. CMP, Lawrence,
Harmelan (Ed.), Object Modeling and User Interface Design. KS, 2000.
Addison-Wesley, Boston, 2001.
[32] Constantine, L. L., Windl, H., Noble, J., and Lockwood, L.
[20] Armstrong, C., and Underbakke, B. “Usage-Centered A. D. “From Abstraction to Realization: Abstract Prototypes
Design and the Rational Unified Process.” In L. Constantine
Based on Canonical Components.” Working Paper, The Science Conference (ACSC2002). Australian Computer Society,
Convergence Colloquy, July 2000. Melbourne, 2002.
http://www.foruse.com/articles/canonical.pdf
[37] Constantine, L. L. "Visual Coherence and Usability: A
[33] Lynn, R. “Beyond Code Freeze: Use Cases that Do Not Cohesion Metric for Assessing the Quality of Dialogue and
Leave Documentation and QA in the Cold.” In L. Constantine Screen Designs." In Grundy, J., & Apperley, M. (eds.)
(Ed.), forUSE 2002: Proceedings of the First International Proceedings, Sixth Australian Conference on Computer-Human
Conference on Usage-Centered, Task-Centered, and Interaction. IEEE Computer Society Press, Los Alamitos, CA,
Performance-Centered Design. Ampersand Press, Rowley, MA, 1996.
2002.
[38] Constantine, L., and Noble, J. "Interactive Design Metric
[34] Wirfs-Brock, R. J., and McKean, A. Object Design: Roles, Visualization: Visual Metric Support for User Interface Design."
RESPOnsibilities, and Collaborations. Addison-Wesley, Boston, In Grundy, J., & Apperley, M. (eds.) Proceedings, Sixth
2002. Australian Conference on Computer-Human Interaction. IEEE
Computer Society Press, Los Alamitos, CA, 1996.
[35] Wilkinson, N. Using CRC Cards - An Informal Approach
to OO Development. Cambridge University Press, London, 1995. [39] Constantine, L. L. "Usage-Centered Software Engineering:
New Models, Methods, and Metrics." In Purvis, M. (ed.)
[36] Biddle, R., Noble, J. and Tempero, E. “Essential Use Cases Software Engineering: Education & Practice. IEEE Computer
and Responsibility in Object-Oriented Development. In M. Society Press, Los Alamitos, CA, 1996.
Oudshoorn (ed.), Proceedings of the Australasian Computer