Civil Engineering Reference
In-Depth Information
Focus Groups and Brainstorming Focus groups and brainstorming are two cheap, easy, and popular
ways that UCD professionals directly interact with stakeholders or users to collect data that can be
used to understand the work system and define appropriate requirements. The basic concept of focus
groups and brainstorming is to gain insight into the real events of work by providing a loosely
moderated forum in which stakeholders or users can collectively discuss aspects of their work. Focus
groups tend to be more rigidly designed and moderated to help keep the participants on the focus
(Caplan, 1990; Kontio et al., 2004), while brainstorming techniques tend to allow for more leeway in
the scope of the discussion — as long as it remains on the focus. Additionally, these techniques are
also good for achieving internal buy-in and support by providing stakeholders with the forum to
provide input and collectively agree on what aspects of the work system are important.
Another derivative of focus groups and brainstorming, which is commonly used, are requirements
workshops. These techniques use the “whole is more than the sum of its parts” principle of collecting
stakeholders and the design team together in a shared space with a shared purpose of defining design
requirements (Gottesdiener, 2002). The output of these meetings includes use cases, business rules,
system criteria, and various models of the work system. These requirements meetings and workshops
are often very efficient and useful methods of data collection and requirements gathering.
Contextual Inquiry: User Interviews in Context It is likely that the majority of readers will be familiar
with the concept of contextual inquiry, or will have been introduced already with the previous
discussion of contextual design. Contextual inquiry is a well-formulated interview technique
popularized by Beyer and Holtzblatt (1998) as the primary data collection tools of their Contextual
Design approach to system design. As the authors explain, “The core premise of Contextual Inquiry is
very simple: go where the customer works, observe the customer as he or she works, and talk to the
customer about the work” (1998, p. 41).
While this method is effectively a user interview (another common requirements elicitation tech-
nique), it is actually more akin to ethnography (Blomberg et al., 2003; Saferstein, 1998) applying the
principles of being anchored in natural settings, focusing on the holistic context, providing descriptive
(rather than prescriptive) understanding of events, and using the point-of-view of the individual
being observed. While there is interaction between the interviewer and the interviewee, this is largely
to clarify the interpretations of the interviewee's words and actions and to help keep the interviewee
vocal and focused on the project scope.
In addition, contextual inquiry is both structured and unstructured as the creators have outlined
several principles and procedures to follow, yet the bulk of the process is the naturalistic observation
of user work. As has been outlined by its creators, contextual inquiry has defined philosophies including
the “Master
Apprentice” model of the relationship between the customer and the designer as well as the
four steps of the interview process — the conventional interview, the transition, the contextual interview
proper, and the wrap-up, wherein each has its own prescribed methods and suggestions (Beyer and
Holtzblatt, 1995, 1998; Holtzblatt and Jones, 1993). The end result of the contextual inquiry process
is a very rich set of notes and observations, which are then used to build models to represent this
interpretation of the work system. These analyses and modeling techniques along with other popular
tools for representing the work system will be discussed in the next section.
/
7.3.2.4.2 Summary
As can be understood from the discussion, requirements elicitation techniques are used to gather inform-
ation on the work system including the users, their goals, their tasks, their work context, their abilities,
their needs, etc. However, as discussed, the information gathered through requirements elicitation tech-
niques is often rough, verbose, and overbearing for immediate use. As such, this data needs to be
arranged, interpreted, analyzed, and modeled to achieve the end goal of creating system requirements
(Nuseibeh and Easterbrook, 2000). Thus, researchers and practitioners developed analysis and modeling
methods to help wrangle this work system data into a form that was more amenable to communication,
study, interpretation, and translation. We refer to these techniques as requirements analysis and model-
ing tools.
Search WWH ::
Custom Search