Concept:
|
Concepts: |
Usability Engineering (also called User-Centered Design) is all about building better systems by getting a better understanding of the end-users, and involving users in requirements, user interface design, and testing efforts. Basic concepts are described in Concepts: User-Centered Design, and should be read prior to this concept. This concept page explains how the Rational Unified Process (RUP) currently addresses usability engineering techniques.
The RUP has a number of roles responsible for usability concerns. The System
Analyst and Requirements Specifier
must be skilled in gathering and analyzing information about users, their tasks,
and their environment, and capturing these in the requirements artifacts. This material is reviewed by the Requirements
Reviewer.
The Tester and
Test
Analyst roles are primarily responsible for usability testing. The User-Interface
Designer is responsible for the design and the "visual shaping"
of the user interface. The Implementer
selects and/or develops user interface components to construct the functioning
user interface.
The Project Manager also has
a key role. He/she enables users to be involved in the development process,
and ensures that the development organization is staffed with the skills required
to build usable systems. Other roles, such as Deployment
Manager,
Course Developer,
and
Technical Writer also have
responsibilities for ensuring that the deployed system is usable.
The following sections describe RUP disciplines in terms of the activities and artifacts which are most important to usability.
From a usability perspective, the Requirements discipline focuses on:
The specific activities and artifacts are as follows.
Activity | Artifact | Usability Related Content |
---|---|---|
Elicit Stakeholder Requests | Stakeholder Requests |
This activity involves interviewing users, questionnaires, and holding workshops to better understand the user and the user environment. This includes the following:
The |
Develop Vision | Vision |
The User Environment section of the Vision template describes the working environment of the end users, or what ISO refers to as the Environment Context [ISO 13407]. The User Profile section of the Vision template describes the user's expertise, technical background, responsibilities, success criteria, deliverables etc. This is what ISO refers to as the User Context [ISO 13407]. |
Find Actors and Use Cases, Structure the Use Case Model, Detail a Use Case | Use-Case Model |
The Use Case Model describes the tasks (use cases) that users (human Actors) perform. It capture similarities and relationships between Actors, using generalization relationships. Actors are related to use cases through This is similar to Constantine's "Role Model" [CON99]. The use cases are structured and related to one another and to actors through communicate-association, include, generalization, and extension relationships. Workshops are an excellent way to involve the user. See:
|
|
The characteristics of human actors are captured as attributes of Actors. These include:
|
|
|
These can include essential
use cases as described by Constantine [CON99]
(see Concepts:
User-Centered Design for a discussion of essential use cases).
Specific usability requirements for a given use case may be captured
as "Special Requirements" in the ![]() |
|
Detail the Software Requirements | The Supplementary Specifications capture requirements not specified in the use cases. This includes availability and performance requirements which may be closely tied to usability. General usability requirements applicable to multiple use cases are captured here, along with applicable legislation and usability standards (see Concepts: User-Centered Design for details on usability legislation and standards). | |
Review Requirements | Change Request | A user-centered development effort involves users as much as possible in all requirements reviews. |
Capture a Common Vocabulary | Glossary | Captures common vocabulary terms specific to the users' domain to facilitate communication and understanding between users and the rest of the development team. |
There are some other techniques which may be useful additions to the above Requirements activities.
A number of other activities in this discipline are focused on the shaping and design of the user-interface. These are:
Activity
|
Artifact |
Usability Related Content |
---|---|---|
Design the User-Interface
|
This activity is creates what is often referred to as the Conceptual Design [FER01]. This is the initial abstraction of the user interface itself, capturing the main windows and navigation paths presented to the user. This activity focuses on use cases that drive the user interface design. Navigation Maps, see [CON99] give an overview of the navigational pathways between interaction spaces (screens, windows, and dialog boxes). |
|
Prototype the User-Interface | User-Interface Prototype |
You can make three basic kinds of prototypes: Drawings (on paper) The main purpose of creating a user-interface prototype is to be able to expose and test both the functionality and the usability of the system before the real design and development starts. This way, you can ensure that you are building the right system, before you spend too much time and resources on development. |
The following techniques may also be useful as part of designing the user interface:
In addition to the activities described above, the following Analysis and Design activities are complementary to the designing of the user interface:
Activity
|
Artifact |
Usability Related Content |
---|---|---|
Use-Case Analysis | Analysis Class, Use-Case Realization |
Also see the following: |
Class
Design |
This activity uses the results of the designing and prototyping of the user interface and designs the classes. Unlike the prototypes, this is not throwaway conceptual user interface work, but is intended to represent the design of the delivered system. Also see the following guidelines: |
The implementation of the user interface follows the general Implementation Workflow. Note that implementation of the user interface is often done as part of the design activity.
Usability testing, including
usability-related performance
testing, should be started as soon as there are mockups or executable prototypes
of the user interface. Testing should include verification of usability and
performance requirements captured in the Supplementary
Specifications or as "Special Requirements" in the
use
case specification.
Users should be heavily involved in Workflow
Detail: Beta Test Product, as well as final Usability
Testing during
Workflow
Detail: Manage Acceptance Test.
Workflow Detail: Develop
Support Material includes development of training material and system support
material to ensure that end users can successfully use the delivered software
product.
Project Management is the art
of balancing competing objectives, managing risk, and overcoming constraints
to successfully deliver a product which meets the needs of both customers (the
payers of bills) and the users. From a usability engineering perspective, the
most critical activity is Activity:
Define Project Organization and Staffing. This activity defines the organizational
structure, external interfaces, and roles and responsibilities. This includes
defining the extent to which users will be involved in the development process,
and determines whether the developers should be experienced with usability engineering
methods.
The Environment discipline includes
the definition of development process to be followed by a project or an organization.
The
Activity: Develop Development
Case (
Artifact: Development Case)
defines which usability engineering techniques will be applied, and how the
various RUP artifacts and activities will be tailored to incorporate these techniques.
Another important activity is Activity:
Develop Project-Specific Guidelines which creates the
Artifact:
Project Guidelines that includes user-interface guidelines. These guidelines
help ensure consistency of the user-interface, which can be a significant aid
to usability. They also capture usability principles to be followed, such as
guidelines for shortcuts, "undo" capabilities, recognizable exits,
modeless interaction, and so on.
The software lifecycle of the RUP is decomposed over time into four sequential phases, each concluded by a major milestone; each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.
Within each phase may be several iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. Usability benefits greatly from this iterative approach. It allows users to provide early feedback on usability, and avoids heading too far down a path which simply won't meet user needs.
The user should be involved in each iteration, to further refine requirements, to evaluate design concepts, and test/evaluate the usability of both proof-of-concept prototypes and the evolving system.
The following sections describe the usability-related phase completion criteria and the main activities for each phase.
Two key objectives of Inception Phase are:
From a usability engineering perspective, this means emphasizing Requirements and Business Modeling activities related to:
Inception phase is also often
the time to explore some conceptual design and "proof of concept" prototyping.
This is particularly true when the primary project risks are related to the
user interface and usability concerns. Usability
testing, including usability-related performance
testing, should be started as soon as there are mockups or executable prototypes
of the user interface.
As RUP is an iterative process, the artifacts created in Inception are revisited and reviewed with users in order to manage scope and ensure that the evolving system meets user needs.
In Elaboration, the focus is on the software architecture - including the architecture of the user interface. The conceptual user interface is defined, and the critical and/or risky elements of the user interface design are implemented. Activities related to the software architecture apply in general to the user interface - there are off-the-shelf products that must be evaluated, reuse considerations, selection of mechanisms and patterns, etc.
This phase emphasizes the user interface design activities, as well as supporting activities from the Analysis and Design discipline. Implementation and Test are also involved, since completion of Elaboration requires that a running system be constructed which can be evaluated.
Usability testing, and
usability-related performance
testing, should focus on any risky requirements captured in the Supplementary
Specifications or as "Special Requirements" in the
use
case specification.
In Construction, the focus is
on implementing more use cases. This involves adding to the user interface,
while remaining true to the conceptual model of the user interface and user-interface
guidelines captured in the Project-Specific
Guidelines. Usability Testing
continues to be very important as new features are added.
The selection of what functionality to place in each iteration is based on value to users.
The focus in Transition phase
starts to shift towards the Deployment
discipline. In a user-centered development effort, you shouldn't wait until
Transition phase to involve the user. However, the user continues to be involved,
primarily to give feedback. When the user has been involved throughout the development,
formal beta and acceptance testing is often significantly minimized or non-existent.
Instead, detailed user feedback and approval occurs throughout the development
effort.
Development of training material and system support material is finalized in Transition, but it should be started in earlier phases, if possible, in order to allow user feedback.
In Transition, there is a working system that can be used by end-users. It is a good idea to plan at least a couple of iterations during transition, so that problems with the initial release can be corrected, and so that key user feedback can be incorporated.
Rational Unified Process
|