A current grad school class (CSCI715 at North Dakota State University with Dr. Gursimran Walia) required us to read two papers about requirements engineering, which has always been a topic that I acknowledge as an utterly necessary activity, but not one that I found particular enjoyable. However, as I read these papers, I found myself being drawn in and becoming rather excited about some of the research directions in this area. (I know I'm a nerd. Shut up.)
Requirements engineering (RE) is arguably the most critical activity in a software engineering effort, possibly second only to construction. The aim of this process is to develop a clear understanding of how a new software system is expected to behave and perform. The importance of this cannot be overstated, for without this understanding, other activities cannot be completed with certainty. Design, development, testing, configuration management, deployment, and practically every other software engineering activity depends heavily on the presence of a complete, accurate, verifiable, and clear specification of requirements. Without an understanding of the expectations, we have no way of knowing when the work is finished. We would have no means of assessing the correctness of the resulting behavior.
Legendary
software engineer Frederick P. Brooks, in his paper No Silver Bullet: Essence and Accidents of Software Engineering,
writes:
The hardest single part of building a software system is
deciding precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements, including all
the interfaces to people, to machines, and to other software systems. No other
part of the work so cripples the resulting system if done wrong. No other part
is more difficult to rectify later.
Therefore, the most important function that the software builder
performs for the client is the iterative extraction and refinement of the
product requirements. (Brooks 1987)
Given the
magnitude of these implications, it is expected that software engineers would
make efforts to improve the efficiency and effectiveness of the requirements
engineering process. Two papers that
propose such improvements are Requirements
Engineering: A Roadmap by Bashar Nuseibeh and Steve Easterbrook; and Research Directions in Requirements
Engineering by Betty H.C. Cheng and Joanne M. Atlee.
Nuseibeh
and Easterbrook begin in a typical fashion by justifying the importance of
requirements engineering and then analyzing a formal definition of it. Then they break away from the pack in a
variety of ways: First, they argue quite
effectively that RE involves more than just business and technology, but that
it also depends on psychology, anthropology, sociology, linguistics, and
philosophy. Second, they propose
requirements management and communication as integral umbrella activities. Though this appears to be stating the
obvious, it is an area that many authors neglect to adequately address. Also, rather than just providing simple
examples of the primary RE activities, they include a moderately detailed list
of approaches for accomplishing each one.
Finally, and perhaps most significantly, they reorganize the classic
paradigm into more specific categories:
eliciting, modeling and analyzing, communicating, agreeing, and
evolving.
The first
of these activities is elicitation, the process of extracting software
requirements from the people and environment surrounding the need for a new
software system. Nuseibeh and
Easterbrook recommend beginning the elicitation process by identifying system
boundaries, the results of which will continue to influence further elicitation
efforts. To accomplish this, they advise
requirements engineers to identify the stakeholders, elicit their business and
technical goals, and explore a series of scenarios including the way things are
done before the new system is available and the ways that the new system is
expected to change the performance of these tasks. The techniques proposed to elicit this
information include traditional data gathering, joint application design,
prototyping, modeling, cognitive knowledge acquisition, and various contextual
techniques.
Proceeding
forward from elicitation is analysis, the process of solidifying, refining, and
organizing the requirements obtained through elicitation. The most common and effective technique for
performing analysis is to create models, upon which Nuseibeh and Easterbrook
place such emphasis as to rename the process with it -- “Modelling and
Analyzing Requirements”. The authors
describe the use of models for analysis in five distinct categories:
- Enterprise models that document an organization’s structure, operations, and goals;
- Data models to represent details and relationships in the information that a system must produce, process, and/or store;
- Behavioral models to explore the functional activities of people and systems;
- Domain models to capture important aspects of the business, technical, and/or physical environment in which a system will operate; and
- Non-functional requirements models to express the quality attributes of a system.
Throughout
all of the phases in RE, communication intermingles with other umbrella
activities. Communication is primarily
documentation which takes numerous forms depending on the nature of the
requirements being communicated and the intended audience. Proper documentation simplifies the process
of requirements management by enabling requirements traceability (RT), which is
the ability to track a requirement from its original elicitation through
implementation and beyond.
One key
thing that Nuseibeh and Easterbrook handle very differently from most authors
is their treatment of verification, which is an attempt to ensure that
requirements are correct and complete.
Instead, they refer to the concept of agreeing requirements, which
concentrates more on validation than verification. Validation is the task of ensuring that the
requirements statements accurately reflect the true needs of the
stakeholders. Agreeing requirements
involves making sure that the stakeholders all agree with the requirements
statements, and may possibly involve some negotiation techniques to reach
consensus.
Finally,
Nuseibeh and Easterbrook confront the inevitable problem of change by including
a discussion on evolving requirements.
The process of evolving requirements is really just a form of another
software engineering activity -- change management, which involves expecting
change and following an established procedure for responding to it. Since requirements can change at any point,
the process of evolving requirements incorporates all other phases of
requirements engineering, possibly requiring an engineer to revisit phases that
have already been performed in order to successfully incorporate the new
changes. Evolving requirements exemplifies
the need for requirements traceability and demands, at the very least, a return
to elicitation and analysis.
Whereas
Nuseibeh and Easterbrook’s paper focused primarily on current practices in
requirements engineering, Cheng and Atlee’s paper looks to the future by
exploring and summarizing research directions.
Essentially, they begin with an explanation of why RE is difficult, summarize
the current state of the art of RE research, and then proceed to identify
future research areas to help manage the difficulties identified.
Cheng and
Atlee do an exceptional job of describing the purpose of each RE phase;
presenting each one with a concise definition and justification for its
existence. By concentrating on each
activity’s intent, the authors draw clear connections to the types of
solution-based research that most directly benefit each task. Elicitation involves identifying requirements,
so most research in elicitation focuses on improving the precision, accuracy,
and variety of those requirements.
Modeling involves creating abstract representations of requirements, so
research in this area involves improvement of scenario-based models and
techniques for manipulating them.
Analysis involves the refinement and organization of requirements, so
research in this area attempts to improve evaluation techniques. Validation ensures that requirements
accurately reflect the needs of stakeholders, so research into verification
techniques deals mostly with communicating the requirements to stakeholders in
a clear way so that an accurate assessment can be made. Requirements management comprises numerous
responsibilities, so the research areas here cover a diverse array of
concerns: automation of RE tasks,
analyses of requirement stability for the purpose of isolating those most
likely to change, and techniques for organizing large numbers of requirements.
Following
the discussion of solution-based research, the bulk of the paper concentrates
on evaluation-based research, in which there are a number of research
strategies which the authors first summarize and then discuss in detail:
- Paradigm shift: Radically new ideas change the way of thinking.
- Leveraging other disciplines: Analogies to other disciplines are drawn to help find solutions.
- Leveraging technology: New technology is applied to solving RE problems.
- Evolutionary: The state of the art is advanced by incremental but meaningful improvements.
- Domain-specific: A problem is solved in a way that applies to a specific application domain.
- Generalization: A domain-specific technique is generalized to apply outside of that domain.
- Engineering: RE techniques are simplified to make them accessible to practitioners and students.
- Evaluation: Existing RE techniques are assessed according to some benchmark or objective.
In
addition to the detailed coverage of research strategies, Cheng and Atlee
identified nine “hotspots” -- areas that are expected to have the largest
impact on software engineering:
- Scale: The size and complexity of software systems creates a need for improved modeling, analysis and requirements management techniques.
- Security: New technologies present new security threats, which may or may not benefit from improved RE.
- Tolerance: Some requirements are difficult to quantify precisely, so tolerances must be established to assess sufficient correctness.
- Increased Reliance on the Environment: Systems are increasingly interoperable with other systems, so we need better ways to represent scope boundaries and interfaces.
- Self-Management: Requirements and environment change frequently, and a self-managing system that can react and adapt would have numerous applications.
- Globalization: Communication is difficult for globally distributed development teams. There is a need for tools and techniques to facilitate collaboration and negotiation.
- Methodologies, Patterns, and Tools: A need exists for improving the transfer of RE techniques from research into practice.
- Requirements Reuse: Products from similar product lines have a large number of requirements in common. Reusable requirements would shorten engineering timeframes and benefit from past experience, but must be adequately flexible to adapt to subtle variations.
- Effectiveness of RE Technologies: The results of RE efforts are only useful if they are applicable to real-world problems. Evidence of applicability is required in order to assess the value and utility of RE techniques and research.
The paper
culminates in a thoughtful and inspiring list of recommendations, many of which
involve collaboration and communication:
Researchers should work with practitioners, other researchers, and
industrial organizations; repositories of artifacts should be jointly
established; researchers should conduct evaluation research and proactively
consider emerging technologies; and academics need to confer this knowledge to
students of disciplines related to software development.
Quite a
few of these research directions piqued my interest and caused me to reconsider
my own selection of research area. Cheng
and Atlee’s description of the engineering research strategy rung with
familiarity because it rephrased my own proposal for a book that I have
outlined. My concept involved leading
the reader through the major SE lifecycle activities, describing the purpose of
each one, and exploring ways to accomplish the objectives without the need to
endure the complex, formal processes prescribed by most SE literature. These simpler alternatives make software
engineering much more attainable to the average developer or student, which
conforms to the way Cheng and Atlee described engineering as a research
strategy.
Of the
nine hotspots, however, requirements reuse really grabbed my attention. Again, the idea echoed in my mind as
something for which I too have expressed a need. As a game developer, I notice that the same
basic requirements seem to be elicited repeatedly. On the most basic level, it is fairly obvious
that games within the same genre have many of the same functional gameplay
requirements. From a system perspective,
each product released for a specific target platform shares many requirements
with other products developed for that same platform. Perhaps we can even consider this at a more
general level, e.g. nearly all games involve similar multimedia needs, like
graphics, animation, and audio.
This idea
may even extend to non-functional requirements.
For instance, games generally place the highest priority on
performance. However, an MMO server also
has a critical need for security, games that are intended to be expanded with
downloadable content (DLC) have a need for extensibility, and the
ever-increasing number of gaming devices demands portability. I simply wonder if the possibility exists of
establishing a set of core requirements that serve as a starting point for RE,
and can then be extended, overridden, and supplemented to satisfy the unique
needs of a new game product.
As I
consider how one might go about researching the topic of requirements reuse in
the domain of video games, I realize that there are a number of potential
challenges. First, we would need to
define scope boundaries to provide focus for the types of requirements we will
specify. Second, this specification
should be formed by experienced, professional game developers, preferable those
who have completed multiple products.
Third, the requirements statements would need to be used in several
projects so we have a valid sample size.
Fourth, we would need evaluation criteria for assessing the
effectiveness of the requirements after the project had completed. Finally, and most importantly, we would need
a few different game development groups who are willing and able to incorporate
our requirements statements, track the requirements accurately, and provide
detailed, honest feedback on the outcomes.
Only after
contemplating the content of these papers have I begun to feel genuine
excitement about requirements engineering.
From this point forward, I am now considering requirements engineering
research as a viable dissertation area.
