Civil Engineering Reference
In-Depth Information
requirements. The translation of this collected information into an actual list of requirements is very
complex and nuanced. It is often an art as much as it is a science (although RE theoreticians may
cringe at the thought). There is no prescribed or preferred methodology for this process, rather
several useful summaries of this process (Nuseibeh and Easterbrook, 2000; Ransley, 2003; Wiegers,
2003; Young, 2004).
Fortunately, however, even Karl Wiegers (a noted RE heavyweight) acknowledges that RE is primarily a
communication activity rather than a technical activity (Wiegers, 2000). A number of guidelines can help
make the requirements formulation considerably less random and more manageable. Many of these
guidelines lay out general principles and processes for generating requirements (Alexander and
Stevens, 2002; Robertson and Robertson, 1999), while others actually propose standardized guidelines
for the process and specification (IEEE, 1998a, b).
As a reminder, requirements are descriptions or statements of system services, functions, properties,
attributes, or constraints laying out 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). In a somewhat sensible, yet magical way, these requirements naturally “drop out” of
the RE process as the requirements elicitation and analysis and modeling tools are used.
For example, the project planning and stakeholders' meetings generally set out the overall business
goals to be met by the system as well as any business requirements and constraints and general usability
requirements. The actual nascence of a requirement lies in an idea that is generated from the study of the
work system (e.g., activities of Stages 1 and 2). Once the goals and needs of the work system are elicited
and modeled, the defining goals (e.g., the new system should be usable) or needs (e.g., the new system
needs to interface with legacy systems) should be broken down into atomic, defined problems, put in a
natural language format, described, and referenced back to the actual data or model that spawned the
requirement. For example, in the contextual design process (Beyer and Holtzblatt, 1998; Holtzblatt,
2003), it is suggested that the requirements be referenced back to the part of the UED or storyboard
that outlines the need for a system function, component, or property and also attaches a list of any
relevant data used (e.g., sections of the affinity diagram or pieces of the consolidated models).
These statements or descriptions serve as specifications of what should be implemented. As the RE
process, or even how the results are communicated, is often a function of the nature and culture of
the audience of the RE results (i.e., the requirements) and the domain in which the system is being
implemented (Kotonya and Sommerville, 1998; Sommerville and Sawyer, 1997), the establishment of
the actual system requirement is a highly variable and flexible process. However, as Ransley (2003)
notes, having an actual process is prerequisite to control and repeatability allowing the ability to
refine the process, improve the knowledge, and increase the skill in turning the identified problems
into appropriate solutions. The RE process also provides a clear auditing trail allowing the traceability
of design decisions back to system requirements and, ultimately, to the identified problems that
needed to be addressed. Arguably, this concept of traceability is of utmost importance as it allows the
design decisions, which have been based on system requirements and specifications to be traced back
to actual work system needs and goals, which were explained and enumerated in the system requirements
and specifications.
7.3.2.6.2 Creating Design Alternatives
Once the systems requirements and specifications have been agreed upon and settled, then the design
process can begin. The truth is, especially in practice, that there is considerable interpretation that
goes into transforming the data collected into a set of well-formulated system requirements or specifica-
tions. However, what happens next — the development of design alternatives — is even less concrete.
Fortunately, researchers and practitioners have developed a number of tools and techniques for translat-
ing an abstract understanding of what the system needs to do into a more tangible representation of how
the system will meet these requirements.
Search WWH ::
Custom Search