Civil Engineering Reference
In-Depth Information
involves a number of activities, such as discovering the purpose for which the system is intended,
identifying the system stakeholders and their needs, and (finally) translating and documenting
these needs into a form that can be communicated, validated, and implemented (Nuseibeh and
Easterbrook, 2000). RE is, arguably the seminal activity in the UCD process, because it represents the
initial step in involving the users (and their needs) into the design process and, ultimately, serves as
the blueprints for the designs that are to be tested and evaluated in later phases of the system develop-
ment process.
As alluded to, RE is a process, meaning that it is (necessarily) somewhat ill-defined, fluid, and complex.
This process involves any number of activities, ranging from simply defining the purpose of the system or
goals of the customer or organization to diligently observing and modeling the actual work of the end-
users. As all of the experts agree, there is no best way of conducting the RE process, just as there is no
single or best way to define and document the requirements that result from the process.
While there are considerable issues regarding the practice of RE, such as requirements validation,
change management, documentation styles, and traceability, this discussion falls outside of the scope
of this chapter. Readers can be directed to any number of topics and reports that deal with these delicate
issues (e.g., Christel and Kang, 1992; Ransley, 2003; Rosenberg, 1999; Young, 2001). Some of these issues,
such as insuring that representative users are chosen, will be discussed in relation to the activities at the
various stages depicted in Figure 7.3. There are a number of good texts detailing the process of and con-
siderations associated with the RE process, including those by Wiegers (2003), Robertson and Robertson
(1999), and Young (2001, 2004).
The real purpose of the RE process is to minimize problems resulting from costly and destructive mis-
understandings or misinterpretation between the stakeholders or users and the design and development
team (Ransley, 2003; Sommerville and Sawyer, 1997). The RE process is able to limit these types of pro-
blems by utilizing systematic and structured process from the start of the system development process
before making definitive judgments or assumptions about design alternatives or work system needs.
Overall, RE is able to provide a better understanding of the system to be developed, help communication
between users and the design and development team, minimize risk and maximize acceptance through
good structuring, clear language, clear linkages between requirements and documented work system
needs, and direct user involvement.
In more concrete terms, RE is the process of translating knowledge of users, their needs, and their
work, and so on into specific, tangible requirements of the system to be designed and developed. As a
simple summary, the RE process is utilized to produce system requirements in such a way that represen-
tative, accurate, and complete work system data are provided in a feasible, affordable, and ethical manner.
We will now turn to the primary component or outcome of the RE process — the system and design
requirements.
7.3.2.1.3 The Nature and Importance of Requirements
As suggested by popular models of design lifecycles [e.g., the usability engineering lifecycle (Mayhew,
1999, 2003)], requirements are defined during the early stages of system development, prior to any
efforts in the design of system prototypes or implementation efforts. Requirements are generally
described as descriptions or statements of system services, functions, properties, attributes, or constraints
typically detailing how a system should behave within its context of use to help perform work (Kotonya
and Sommerville, 1998; Nuseibeh and Easterbrook, 2000; Ransley, 2003; Sommerville and Sawyer, 1997).
Requirements are typically a mixture of some problem information, statements of system behavior and
properties, and design and manufacturing constraints (Sommerville and Sawyer, 1997).
There is no best way to generate or communicate requirements. The process of creating requirements
from the collected and modeled data of the work system is nebulous to characterize, often requiring con-
siderable interpretation, rationalization, and translation of the raw data into concise, accurate, and com-
municable ideas. There is also no set way to communicate system requirements. The requirements
document, the comprehensive list of requirements, is the communication tool between the users and
stakeholders, the UCD team, and the systems engineers and developers. Depending on the audience,
Search WWH ::
Custom Search