Civil Engineering Reference
In-Depth Information
Personas and Use Case Models Two more recent requirements analysis and modeling techniques that are
commonly used are personas and use cases (or use case models). Personas, which were first introduced in
a remarkable topic by Alan Cooper (2004), are becoming a wildly popular technique for UCD. Personas
are typically built from data collected in ethnographic interviews (e.g., contextual inquiry) and are
expressed in 1 to 2 page descriptions that include a general profile, behavior patterns, goals, skills,
attitudes, and environment. A persona is a user archetype that is based on a collection of job
responsibilities and goals (Pruitt and Grudin, 2003). Personas help to enhance the utility of scenarios
and other user-centered techniques such as participatory design by strengthening the focus on
realistic users and work contexts — albeit through a fictionalized setting (Grudin and Pruitt, 2002;
Pruitt and Grudin, 2003). In this way, personas are really user models, which can then be used to
guide and enhance other techniques such as use case models.
Use case models are largely popularized through their use in the UML method (Booch et al., 1998;
Rumbaugh et al., 2004) and are used to capture the system requirements through a narrative-like
format of the steps to perform the tasks, the tasks to be performed, and the system's behavior for
each task (Cockburn, 2000; Kulak and Guiney, 2004). The use cases are generated from work scenarios
created through the requirements elicitation processes such as user interviews and brainstorming. Use
cases essentially represent a goal-oriented set of interactions between the users (actors) and the system
to be used and describe the sequence of the user's actions and the system's reactions. In this way, each
use case presents the system functionality needed to support user work for a given task and goal.
7.3.2.5.2 Summary
If any reader happens to already know UCD or system engineering practitioners, there are a lot of other
popular methods, many of which include structural diagramming methods such as task analysis or hier-
archical task analysis (Hackos and Redish, 1998; Shepherd, 2000, 2001) and work domain or cognitive
work analysis (Rasmussen, 1986; Vicente, 1999), just to name a few. Researchers and practitioners
have developed analysis and modeling methods and tools to represent nearly all imaginable aspects of
the work system from models representing the organizational culture and policies of the work system
[the cultural model of contextual design (Beyer and Holtzblatt, 1998)] to models representing
complex tasks in terms of goals and subgoals with associated plans for carrying out those subgoals [hier-
archical task analysis (Shepherd, 2001)].
However, a discussion of all of these work system analyses and modeling techniques could itself
produce a multi-volume handbook. As can be seen, work system analysis and modeling techniques
are used to create fairly concise, yet complex representations of the work system. While each of these
analysis and modeling tools might represent completely different aspects of the work system, they are
all used to provide a representation of the work system that can be used to generate ideas of (primarily)
what the system is supposed to do and (to some extent) how the system should go about supporting these
goals and needs. In other words, work system analyses and modeling tools are used to provide a basis to
form system requirements.
7.3.2.6 Defining Requirements and Specifications to Drive Design
As discussed, the overall purpose of investing all this time, money, and trouble in eliciting knowledge,
opinions, and ideas from the stakeholders and end-users and then analyzing and modeling this data is
to feed the process of developing representative, appropriate, and useful requirements for the work
system. These requirements are vital to UCD as they are the foundation for the engineering design spe-
cification, which will be used as the blueprint in the design and development (Samaras and Horst, 2005).
The system requirements are used to define the engineering design specifications. These specifications are
then used to guide design and development. This basic process is outlined in Figure 7.3.
7.3.2.6.1 More on Requirements
From the previous discussions, RE in actuality is a process — involving sequential activities typically pro-
ceduralized and have been validated through previous use, and building the knowledge about and under-
standing of the work system. The culmination of this process is the requirements document — the list of
Search WWH ::
Custom Search