Creating a Project-Specific Requirements
Engineering Process
Donald Firesmith, Software Engineering Institute, U.S.A.
|
 |
COLUMN
PDF Version |
Abstract
In this column, I use a common situation facing many requirements
engineers to illustrate that “one size does not fit all” when
it comes to selecting a project-specific requirements engineering process.
I then recommend a metaprocess for constructing such a process based
on the use of a preexisting process framework and its associated repository
of reusable process components. I conclude the column with a brief
discussion of some of the benefits and risks associated with this approach.
1 THE CHALLENGE
Imagine that you work for a small to midsize company that
develops software-intensive systems. Today, your company is essentially
ad hoc when it comes to process. Each project and team within the project
is responsible for determining how they are going to perform their
tasks. However because of recent problems with quality and the failure
of important projects to come in on schedule and within cost, management
has recognized the need for more rigor when it comes to the system/software
engineering process. Perhaps there is even some pressure from customers
or members of management to achieve a specific score on a recognized
process assessment such as the SEI’s Capability Maturity Model
Integration (CMMI®; http://www.sei.cmu.edu/cmmi/) or ISO Spice
ISO/IEC TR 15504 (http://isospice.com/standard/tr15504.htm).
And now
a new project is about to start. You have read a couple of requirements
engineering books and maybe taken a one-day tutorial at
some conference so you are perceived as the local requirements expert.
Thus, you have been tasked to lead the requirements effort. And you
have also been tasked to develop and document the project’s process
for performing requirements engineering (RE), with the understanding
that what you come up with is intended to become your company’s
standard RE process if it works reasonably well on your project. So
what do you do?
A fair number of you reading this column have probably either found
yourself in this situation or else know of someone who has. Or maybe
you are working for a similar company and suspect that someone will
face this challenge shortly. What do you do?
You could write a brief
memo stating that your RE process is the process described in your
favorite requirements book. But this isn’t
a very good solution because the book describes a general RE process,
and you need one that is appropriate for your specific project. Also,
even within your company, projects vary greatly in terms of their size,
complexity, business criticality, technical difficulty, and this list
of relevant factors could go on and on. You need an RE process that
is both flexible enough for multiple projects but yet is also appropriate
for your specific project. Also, you cannot expect all of the stakeholders
and participants in the RE process to take several days off from their
busy schedules to read an entire book. And finally, the book describes
lots of tasks, techniques, and work products, several of which will
probably not be appropriate for your specific project.
You could try
to write a longer and more detailed document describing exactly which
parts of the book are relevant, how you are tailoring
other parts of the book, and how you are extending the book with ideas
you’ve taken from other books and the conference tutorial you
took. But basically, the result would be too complex and confusing
to be practical. And besides, management wants you to produce a well-documented
company-specific RE process or set of processes. They want to see real
standards, procedures, guidelines, and templates.
Another possibility
would be for you to hire a consultant experienced in both process and
RE. Such a consultant could either develop a RE
process for you or work with you to develop the process. The need for
the RE process to be project-specific and appropriate and feasible
within your corporate culture would require the consultant to work
closely with you. Unfortunately, hiring the consultant to help you
develop the process from scratch is not practical because there is
insufficient funding to hire someone who is adequately qualified for
the amount of time that would be required. You need someone with practical
industry experience, and the only person you can afford for the necessary
time is a professor at the local university who doesn’t have
that practical experience. For schedule and budget reasons, you really
need to do most of the work yourself, limiting the use of the consultant
to possibly a small amount of initial guidance followed by the later
review of the mostly finished RE process.
What you really need is for
someone experienced to have already done most of the work for you.
You need access to a set of consistent RE
process components (task descriptions, technique descriptions, templates,
guidelines, etc.) that you can reuse. You also need them to be relatively
inexpensive (or better yet free) because you cannot afford to buy
sufficient licenses for a tool that would provide a user friendly access
to the
reusable RE process components. You could spend lots of time on the
Web searching for individual reusable RE process components, but
you would have to deal with the fact that they were not designed to
work
together as part of a single process framework and may therefore
be inconsistent. Actually, you need the equivalent of a class library
of reusable RE process components that you can pick and choose from.
You need a RE process framework [ALC2000] with an associated repository
of reusable RE process components.
2 A METAPROCESS FOR PRODUCING THE PROCESS
Once you have decided
to create a project-specific RE process using a repository of reusable
RE process components, you need to determine
a reasonable metaprocess (i.e., process for processes) for using
it to produce your project-specific RE process. I recommend the following
basic metaprocess that you should feel free to modify to fit the
specific needs of your organization. Although this metaprocess is
written in a roughly temporal order, it is typically performed in
an iterative, incremental, parallel, and time-boxed manner until
an acceptable project-specific RE process is obtained.
- Determine
Your RE Process Needs. Determine the types of projects that your
RE process framework will have to support. The wider the
range of projects, the larger and more complete the repository
of reusable RE process components must be as well as the more tailorable
and user-friendly
the individual RE process components must be. You should consider
the following factors when determining your RE process needs:
- Size and
Complexity. In terms of the size and complexity,
what is the range of the associated systems to be
produced? This will
determine
the size of the projects in terms of staffing, funding,
and schedule.
Large complex projects need larger and more formal
RE processes than small simple ones.
- Contractual Issues. Will the projects
involve subcontracting or partnering? The requirements
for such applications
may well be part of a contract
and thus be legally binding.
Such projects also tend to have more separation between customers,
users,
developers
and
even partners,
subcontractors,
and vendors. Thus, the requirements
for such projects need to be
more formal and of higher quality.
- Legal and Regulatory Issues. You may
be required to use RE processes
that are compatible with various international and
governmental standards.
These may be ISO standards
(e.g., ISO/IEC 12207; http://www.abelia.com/docs/12207cpt.pdf),
IEEE standards (e.g., IEEE STD 830-1998; http://users.snip.net/~gbooker/INFO627/IEEE-830-1998.pdf)
military standards, security
standards (e.g., FIPS
PUB 140-2; http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf),
and
safety standards (e.g., MIL-STD-882D; http://www.reliasoft.org/mil_std/mil_std_882d.pdf).
The process repository will then
need to include the required process
components,
and
these components
must be compatible
in content and meaning with
the requirements
of the standards.
- Support
for Assessment.
You may be required to use
RE processes
that will enable you
to achieve a specific
level on some
major process
assessment
scale such as the SEI CMM
(http://www.sei.cmu.edu/cmmi/)
or ISO Spice
(http://isospice.com/standard/tr15504.htm).
The RE process repository
will then need to include
the required process
components.
- Distributed
Development. When
the project is distributed
geographically,
the specification
and communication
of the requirements will
need to
be more formal and better
documented. Whether you use
email or you will
have good requirements
tools
to enable multiple
distributed
teams
to simultaneously and collaboratively
work on the requirements,
you still have to deal
with
time differences.
- Business Criticality. Some
projects are very business
critical with the success or failure of the project having
a major
impact
on
the
success or failure of the
business. Other projects may involve the development of simple
throwaway
prototypes.
The more critical
the system
is to the business, the more
critical it is that
RE is
successful and the more formal
its process will tend to be.
- Requirements Volatility.
The more volatile the requirements,
the more important it becomes for the requirements
process to support
the
quick and easy modification
and addition of requirements. The requirements process must
be
agile, although
that
does not necessarily
mean
that the requirements process
needs to be superficial.
- Stakeholder Involvement.
The more involved that the
stakeholders (e.g., user representatives, management, subject
matter experts,
architects, testers, assessors, and regulators)
are in the
RE
process, the more important that they both
understand the RE process, that they
can perform
their allocated tasks in
the process, and that they can understand the resulting work
products.
- Process Breadth. Do you need a process
framework that is restricted to RE, or do you
need a general process framework that covers all activities
(e.g., from management, development, operation,
and retirement), whereby RE is only part of the framework?
In order
to ensure
cross-activity consistency, RE is best performed
within the context of the entire
system or software engineering process. Selecting
a general purpose process framework and repository can
avoid
unnecessary
duplication of work and “turf battles” that
may occur between RE and other related activities.
- Corporate Culture. Any RE process must
be acceptable to (and usable by) the staff that
must use it. Personnel performing RE must
have the minimum level of training and experience
to perform the tasks, use the techniques, and
produce the work products
of the process.
Similarly,
they must feel comfortable
with the level of formality and completeness of the process.
This
in turn
will
influence
the way
and the level
of detail to which the process
is documented. The staff must
see the process
as either helpful or necessary,
or else they will not use it.
- Tool Compatibility. Do you already have
a set of existing Computer-Aided Software
Engineering (CASE) tools with
which the process
must be compatible (e.g., produce
the same work products)? Although
the
process
needs
should drive the selection
of the process and the selection of the process should drive
the
selection
of
the associated
CASE and
other
tools, often tool vendors
successfully (and unfortunately) sell their products as solutions
to your
process
needs
before
organizations have
yet determined their process
needs.
- Metrics. Has your management determined
that you need to collect
specific types of RE metrics (e.g., requirements completeness,
requirements
volatility, and requirements
quality)? Sometimes,
the type of metrics required can influence
the process because the process
must create
the data on which the metrics
are based.
- Budget. You may have been
given a budget (in terms
of staff, funding, and calendar time) in which to develop
and incorporate
the
RE process.
Given a limited budget, you
may have no choice but
to select a process that is less complete
than you would like (and need).
The preceding
subbullets influence the size, completeness, and formality
of the needed RE process, which in turn influences the size and
completeness
of the process framework and its associated repository
of reusable process components that you will select and obtain in
the
next
step. This determination can be made manually, and it can
also be supported
by an automated "process consultant" tool such
as the OPF Process Consultant (http://www.donald-firesmith.com/ProcessConsultant/ProcessConsultant.html).
- Identify and Obtain the Process Framework.
Once you understand your RE process needs, you can identify and obtain
(buy or acquire
access to) the repository of reusable RE process components you
will use to produce your project-specific RE process. There are several
repositories of reusable process components available that incorporate
RE components (e.g., RUP http://www-306.ibm.com/software/awdtools/rup/,
OPF http://www.donald-firesmith.com/ and
Ralph Young http://www.ralphyoung.net/artifacts.html).
Some RE process frameworks and repositories are being rapidly maintained
and updated whereas others are relatively static. Some are supported
and augmented by many consultants and books, whereas others are
restricted to “what you see is what you get.” Some are general purpose
repositories of reusable process components (e.g., RUP and OPF), whereas
others are restricted to RE (e.g., Ralph Young’s process
components).
- Size and Completeness. Some repositories of reusable process
components are very large and complete, supporting the entire
system/software engineering process including development
and operation. Other
repositories
are quite small and of restricted scope. Large and complete
repositories have the advantage of almost always having the
process component
you need so you do not have to extend the repository yourself,
which can
be very difficult and expensive, especially in the middle
of a project. They also allow you to develop consistent processes
for
all major development
and operational activities. However, it may be much easier
to identify the relevant process components in a small focused
repository unless
the larger repository is well organized and supplied with
a
powerful search capability.
- Cost. Some repositories of reusable process
components are free (e.g., OPF and Ralph Young), whereas
some must
be purchased from a vendor
(e.g., RUP). The purchase price can vary
considerably and may be out of reach of many smaller companies
and projects.
Also,
the cost
of
any necessary training and consulting should
also be factored in.
- Tailorability. Some are open source (e.g.,
OPF) and thus highly tailorable whereas others have
little or no tailorability
(e.g.,
Ralph Young).
- Learn the Process Framework. If you are playing the combined
roles of requirements engineer and process engineer, you need to
learn
the basics of the process framework you have chosen. You need to
learn
its metamodel (http://www.donald-firesmith.com/Components/Components.html)
of process component types (e.g., RE work products, tasks, roles,
teams, techniques, and conventions) and be able to quickly understand
and
identify those RE process components most likely to be relevant
to your specific project. This will include both the relevant RE
process
components as well as possibly those process components from
other disciplines such as management (scope control), configuration
management
(of requirements and requirements documents), quality assurance
(e.g., technical evaluation and review of the requirements and
requirements specifications), risk management (of requirements related
risks),
etc.
- Select the Relevant RE Process Components.
The first actual step in constructing the project-specific requirements
engineering process
is selecting the relevant RE process components from the repository
of reusable process components that you will use to build it.
Except for the RE tools (including the requirements repository and
any
reusable
requirements), the stored process components are essentially
informational; they are descriptions of the requirements work products
(a.k.a.,
artifacts), languages, work units, producers, conventions, etc.
that will make
up the process.
- Select the Requirements Work Products. First select
the formal requirements work products that will be delivered
to the customer organization and
then select the informal intermediate work products that
will be used to develop the formal work products. These include
requirements, requirements
models, and various types of requirements specifications.
These
may also include application vision statements as well
as various types
of analyses such as customer, user, and technology analyses.
- Select
the Requirements Languages. Select the relevant
natural, modeling (e.g., UML http://www.uml.org),
and formal (e.g., Z
http://www.afm.sbu.ac.uk/z/ or
object-Z http://www.cs.uq.edu.au/~smith/objectz.html)
requirements languages used to build the requirements work products.
- Select the Requirements Work Units. Once you have selected
the requirements work products, you can select the specific
tasks and techniques to
be used to generate them. Relevant tasks might include
customer analysis, user analysis, technology analysis, visioning,
requirements
identification,
requirements analysis, requirements specification, and
requirements management. Relevant techniques might include (but
are not
limited to) brainstorming, elicitation, interviews, questionnaires,
storyboarding,
task analysis, use case analysis, hazard analysis, prototyping,
iterative development, incremental development, joint application
development,
and cross functional teams.
- Select the Requirements Producers. Select
the producers (i.e., people, roles they play, teams,
organizations, and tools) that will perform
the selected work units to produce the selected requirements
work products. These might include the requirements team, the
requirements evaluation
team, the various roles played by members of these teams
(especially
requirements engineer), and the various requirements
tools (e.g., requirements modeling and requirements management)
that they
will
use. Allocate
the requirements work units and work products to the
requirements producers that will perform and produce them.
- Select the Requirements Stages.
If not already selected, then select the development/life
cycle as well as its relevant phases, builds,
and milestones during which RE will be performed. Allocate
the performance of the requirements work units and development
of the
requirements
work products to their associated stages of development,
especially the milestones by which the requirements work products
must achieve
a specific level of completion and approval.
- Tailor the Selected
RE Process Components. Merely selecting the reusable
process components will not make the resulting RE process
adequately project-specific. For example, it is not enough
to decide to produce a system requirements specification (SRS); you
must
also decide how complete the specification must be in terms of
its contents.
Similarly, deciding to have a requirements team is insufficient;
you also have to decide what the makeup of the team should be
in terms
of roles. Likewise, tasks can be performed using many different
techniques and produce varying amounts and types of work products.
Reusable process
components often are very complete because it is easier to
tailor out unnecessary subcomponents than it is to add missing subcomponents,
especially at the beginning of the project when the requirements
team
should be concentrating on engineering requirements instead
of
trying to decide how to engineer requirements. Thus, tailoring
most often
involves deleting subcomponents of the process components that
are inappropriate or not cost-effective. Tailoring may also involve
making
changes to existing subcomponents, such as assigning a task
to a different role than the default one chosen by the developers
of
the repository.
This will involve tailoring the task out of the description
of the default role and adding the task to the description of the
new
role.
Thus during this step, you both tailor out existing subcomponents
and make modifications to remaining subcomponents.
Note that depending
on the amount and difficulty of tailoring that is required,
this
may well be the most time-consuming and costly individual
step in this metaprocess to develop a project-specific RE process.
- Extend the Reusable Repository and Process Framework. No
matter how complete a process framework and associated repository
of reusable
process components might be, there is always the possibility
that it
needs to be extended with additional process component types
and associated process components that were not envisioned or completed
by the supplier
of the repository of reusable process components. Extension
may
mean the addition of new process components (e.g., that provide
new tasks
for a more complete RE activity, new requirements work products,
new roles, etc.). It may also require the addition of new subcomponents
to existing components (e.g., the addition of new techniques
to an
existing task or the addition of new sections to existing documents).
- Document the RE Process Components. Except for reusable requirements
and RE tools, the reusable RE process components are essentially
documents that describe the tasks, techniques, roles, work
products, conventions,
etc. that make up RE. The documents should be written it
in a form that is appropriate for their varied readership of stakeholders
in the RE process. However, the form that they exist in the
requirements
repository may or may not be appropriate. For example, the
reusable process component documents may be Microsoft Word documents,
Adobe
Acrobat PDF documents, HTML files, XML files, or even paper
documents. These documents may therefore need to be translated into
the appropriate
form for use on the project. This redocumentation may involve
change of media (e.g., paper to electronic), change of file type
(e.g.,
MS
Word to XML), and the addition of organizational branding
(e.g., adding brand logo and using brand colors). This is especially
a problem
if
the modifications and extensions are derived from sources
outside of the repository or if the repository contains components
in different
formats or media.
- Integrate the RE Process Components. It is not
sufficient to build (i.e., reuse, tailor, extend, and document)
the individual RE process
components. You must also integrate them into a consistent
RE process that conforms to the associated process framework’s metamodel.
For example, if the reusable RE process components (i.e., process descriptions)
contain hyperlinks to other process components, then the preceding
tailoring, extension, and documentation steps may have broken some
of the existing links and created “orphan” components.
Another issue is whether or not the selection, tailoring, extension
and documentation steps are performed manually or are supported by
a repository-specific process engineering tool. If performed manually,
there is a high probability of integration problems (e.g., broken
hyperlinks); if performed by a process engineering tool, then there
should be few
if any integration problems.
- Verify the RE Process Documentation.
The integrated RE process should be verified to be complete,
consistent, and usable, especially if the
tailoring, extension, documentation, and integration were
performed manually.
- Complete. The integrated RE process should
contain all selected RE process components. The required
documentation for a reusable
process component should also include all required
topics. For example, the
standard contents for the documentation of a requirements
work product may include name, purpose, intended audience,
intended uses,
content,
and guidelines. Similarly, the standard documentation
for a requirements task may include name, purpose, steps,
techniques, inputs and outputs,
and guidelines.
- Consistent. The integrated RE process components
should be consistent with each other. There should be referential
integrity,
in the sense
that if the documentation of one RE component mentions
another (e.g., if a role performs a task and a task produces
a work product,
then
the role produces the same work product). The documentation
of a process component in the integrated RE process should
not refer
to another
process component that is not in the integrated RE process.
Note
that the difficulty in maintaining and verifying referential
integrity is one reason why the reusable RE process components
in some repositories
do not mention other RE process components (or at
least minimize the
number of references or hyperlinks). Unfortunately,
this lack of references makes it more difficult to browse the
RE process
and determine
the
exact meaning of the process components.
- Usable. The integrated process
should be usable by its intended audience of stakeholders.
This could include such quality attributes as readability,
navigability, and search capability.
- Validate the RE Process. Once
the integrated RE process has been verified for basic completeness,
consistency, and usability and any
identified defects have been fixed, you should have it validated
by its stakeholders for appropriateness (e.g., adequacy, appropriateness,
formality, and agility) to the project in terms of project
size and
complexity; contractual, legal and regulatory issues; support
for assessment and distributed development; requirements volatility;
stakeholder involvement;
corporate culture, tool comparability, metrics, and budget.
- Approve
and Publish the RE Process. Once the integrated RE process had
been verified and validated, it can be approved by management,
published as the official project RE process, and made available
to its stakeholders for actual usage on the project. Publication
may take
the form of actual production and distribution of one or more paper
documents (e.g., plans, standards, procedures, and guidelines)
or hosting on a project-internal website.
- Train the RE Process Stakeholders.
Successful use of a new RE process by stakeholders who are either
unfamiliar with it or with the RE discipline
will typically require process-specific training. Training will
typically consist of some initial classroom training followed by
on-the-job training
within and by the requirements team.
- Use the RE Process. The proof
of any process is in its use. As the project-specific RE process
is actually used on the project, members
of the requirements team and other stakeholders will be able to
determine what parts of the process work and what parts require improvement.
- Iterate the Process. Depending on the existence and quality
of the process engineering tool support and the amount of bureaucracy
existing in the approval and publication step, you may be able
to rapidly
and easily iterate the RE process in an on-going fashion, update
the RE process at specific milestones, or update the RE process at
the
end of the project. What ever the case, the RE process should be
considered to be living documentation that is developed and maintained
in an iterative
manner as lessons are learned.
3 BENEFITS, COSTS, AND RISKS
Benefits
By creating a project-specific RE process by reusing a standard
repository of consistent process components, you can expect to obtain
the following
benefits:
- Increased Product Quality. Many defects are introduced
during requirements engineering, and these defects tend to have a
disproportionate negative
impact on the project. By using a better RE process, the project
can minimize these defects and decrease the associated risk to the
project.
- Increased Process Quality. Preexisting process components have been
developed by professional methodologists and experts in requirements
engineering. They are more likely to be of much better quality that
process components developed under the project’s schedule pressures
by staff requirements engineers who have less experience, both in
requirements engineering and in process development.
- Improved Productivity and Schedule. By not having to develop
the RE process from scratch, the requirements team can develop the
process
much faster, allowing them to concentrate on using it rather than
building it. These time savings allows the requirements team to develop
more
expertise in the application domain.
- Consistency and Compatibility. Whereas the project’s requirements
engineering team can create a project-specific process, they are
also reusing process components that can also be used to develop
requirements
engineering processes for other projects within the organization.
Such consistency can help with training costs and the ability to
move staff
from one project to another. If they are from a repository of general
purpose process components, the reused RE process components were
also developed to be consistent with other processes on the project,
such
as management (scope control), configuration management (of requirements
and requirements documents), quality assurance (technical evaluation
and review of the requirements), risk management (of requirements
related risks), etc.
- Process Assessment. The use of a well-documented, industry-best-practices
requirements engineering process can help the organization achieve
a better score on a standard process assessment such as CMM and
ISO Spice.
Costs
Whereas many of the preceding benefits of reusing a
standard collection of consistent process components can decrease the
overall project costs,
there are also costs associated with using such an approach:
- Acquisition Costs. Most repositories of reusable process
components (e.g., RUP) must be purchased from a vendor, and only
a few (e.g.,
OPF) are available for free. Although the acquisition costs are
considerably less than what it would cost to develop the repository
from scratch,
the purchase price is none-the-less significant, especially if:
- You
must purchase multiple seats or an organizational and site license.
- You must purchase the entire process repository including the
entire range of process components, many of which may not be
relevant.
- Construction Costs. It takes time to identify and select
the appropriate process components and build the project-specific
process out of them.
The process framework may or may not come with tools to help you
select components and construct the new process, possibly as a (consistent
set of) paper document(s) or a hyperlinked informational website.
- Tailoring and Extension Costs. It takes time to tailor
the reused process components to fit the needs of the specific project,
and extend the
repository with missing process components. These costs also depend
on how easy it is to find and select the relevant process components
and how tailorable the individual process components are (e.g.,
in terms of deleting unnecessary subcomponents and modifying remaining
subcomponents). It also depends on how easy it is to create new
and
yet compatible components.
- Verification Costs. It takes time to verify the project-specific
process for completeness, consistency (e.g., the proper removal of
unnecessary
subcomponents without the introduction of dangling references and
orphaned objects), and usability.
- Consulting Costs. The typical requirements engineer does
not have adequate experience in requirements engineering, being either
an engineer who
has been tasked with requirements engineering or a full-time requirements
engineer who has been too busy with his or her head in the trenches
to keep up with the latest developments in requirements engineering.
The typical requirements engineer may also not have adequate experience
in process engineering. Thus, the requirements engineer may need
consulting support, either internal or external, from professionals
in both requirements
engineering and process engineering.
- Training Costs. Even with a well-documented RE process,
there will be training costs (classes, books, and staff time) required
to teach
all of the stakeholders in the new process once it is developed.
Because the process is project-specific, some of the training should
be specific
to the new process.
However, one must weigh these costs against the
significant costs due to requirements defects that may result from
reusing a general purpose
requirements engineering process or from attempting to develop a project-specific
process from scratch. Given the criticality of requirements engineering,
I strongly recommend considering the approach identified in this column.
Risks
Even when reusing a standard repository of consistent process
components, there remain significant risks:
- Lack of Tailorability. Not every repository of reusable
process components has associated tools that make their components
easy to tailor. Often,
the process components have to be manually tailored, and this requires
the components to be open source or to specifically include tailoring
in the contract.
- Ease of Tailorability. Tailoring tools need to be flexible
and easy to use. If tailoring is to be done manually, then the form
of the process
component needs to support tailoring; thus the components should
be written in simple and well formatted text (e.g., MS Word .doc
files),
HTML, XML, or Java. Process components documented in PDF files
will require access to an Adobe Acrobat writer as well as the free
Acrobat
reader.
- Appropriateness. After all the work of producing a project-specific
RE process, there is still the possibility that the end result
may still not be appropriate if it does not take into account all
of the
relevant factors (e.g., size, complexity, criticality, staffing,
culture, contracts, etc.) and all significant stakeholders. If a
consultant
is used, care must be taken that the consultant does not push his
or her favorite standard process if that does not meet the specific
needs
of the project.
- Usability. The resulting process components should be easy
to use by their intended audience of stakeholders. Descriptions should
be easy
to read, and work-product templates should be easy to instantiate.
It should also be easy to navigate around the many components to
find the desired components. The framework of components should also
be
based on a clean and intuitive metamodel of process component types.
When
performing a risk analysis of this recommended approach, one must
also take into account the far greater risks associated with reusing
a general purpose RE process or with attempting to develop a project-specific
process from scratch. Given the criticality of requirements engineering,
I strongly recommend considering the approach identified in this column.
4
CONCLUSION
As this column has demonstrated, it is not trivial to produce
a project-specific RE process. There are definite costs and risks that
the benefits must
outweigh. However, given the criticality of requirements engineering,
the development of a project-specific RE process is usually the optimal
approach. The primary question is how to do produce one. Should you:
- Reuse a general purpose RE process as documented in some
requirements engineering book or set of standards.
- Develop a project-specific RE process from scratch.
- Instantiate a project-specific RE process by reusing preexisting
process components from one of the available repositories of such
components.
As
a separate observation, the astute reader has probably guessed that
there is little if anything about the recommended metaprocess for developing
a project-specific RE process that is in fact specific to requirements
engineering. Every other discipline on the project is subject to the
same needs and challenges, and the same metaprocess will work for them
(assuming that the repository is large enough and not restricted to
requirements engineering). In fact, that is one of the benefits from
the approach recommended in this column. If everyone on the project
uses the same approach and the same repository of consistent reusable
process components based on the same metamodel and framework, then
they will be more likely to produce an overall project-specific development
process that minimizes the unnecessary overlaps and inconsistencies
that often plague the boundaries between disciplines.
REFERENCES
[ALC2000] Alcázar, Enrique Garcia and Monzón,
Antonio, “A
Process Framework for Requirements Analysis and Specification”,
in the proceedings of the 4th IEEE International Conference on
Requirements Engineering (ICRE’00) held 19-23 June 2000
in Schaumberg, Illinois, IEEE, pp. 27. http://csdl.computer.org/comp/proceedings/icre/2000/0565/00/05650027abs.htm
Disclaimer
The views and conclusions contained in this column are solely
those of the author and should not be interpreted as representing
official policies, either expressed or implied, of the Software Engineering
Institute, Carnegie Mellon University, the U.S. Air Force, the
U.S. Department of Defense, or the U.S. Government.
About the author
|
 |
Donald Firesmith is a senior member
of the technical staff at the Software Engineering Institute (SEI).
He has worked exclusively with object technology since 1984 and
has written 5 books on the subject. He is currently writing a book
on the engineering of safety, security, and survivability requirements.
Most recently, he has developed a 1,100+ page informational website
on the OPEN Process Framework at http://www.donald-firesmith.com.
He can be reached at dgf@sei.cmu.edu.
|
Cite this column as follows: Donald G. Firesmith: “Creating
a Project-Specific Requirements Engineering Process”, in Journal
of Object Technology, vol. 3, no. 5, May-June 2004, pp. 31-44. http://www.jot.fm/issues/issue_2004_05/column4
|
