Ingeniero

When Telepathy Won’t Do:
Requirements Engineering Key Practices1
Karl E. Wiegers
Process Impact
www.processimpact.com
The software industry is exhibiting an increasing interest in requirements engineering —
that is, understanding what you intend to build before you’re done building it. Despite the hype of
“Internet time,” companies across many business domains realize that time spentunderstanding
the business problem is an excellent investment. Clients have told me they’re getting serious about
requirements because the pain of having built poor products has simply become too great.
You can best achieve requirements success by applying established good practices on your
projects.1,2 Figure 1 suggests a requirements development process framework with steps that
incorporate thekey practices described here. Thoughtfully tailor the practices to suit your project
type, constraints, and organizational culture. Some highly exploratory or innovative projects can
tolerate the excessive rework that results from informal requirements engineering. Most
development efforts will benefit from a more deliberate and structured approach, though.
Telepathy and clairvoyance rarelysuffice.

A REQUIREMENTS ENGINEERING FRAMEWORK
Requirements engineering is primarily a communication, not technical, activity.
Communication problems can begin early on if project participants have different ideas of exactly
what “requirements” are. My favorite definition comes from Ian Sommerville and Pete Sawyer1:
Requirements are…a specification of what should be implemented. They aredescriptions of how the system should behave, or of a system property or attribute.
They may be a constraint on the development process of the system.
This definition points out that many different kinds of information fall in the domain of software
requirements. A project needs to address three levels of requirements, which come from different
sources at different project stages:
•
•
•

1Business requirements describe why the product is being built and identify the benefits
both customers and the business will reap.
User requirements, captured in the form of use cases, describe the tasks or business
processes a user will be able to perform with the product.
Functional requirements describe the specific system behaviors that must be
implemented. The functional requirementsare the traditional “shall” statements found
in a software requirements specification (SRS).

Published in Cutter IT Journal, May 2000. Reprinted with permission from Cutter Information Corp.

When Telepathy Won’t Do

Page 2

1. Define the project’s vision and scope.
2. Identify user classes.
3. Identify appropriate representatives from the user classes.
4. Identify the requirementsdecision-makers and their decision-making process.
5. Select the elicitation techniques that you will use.
6. Apply the elicitation techniques to develop and prioritize the use cases for a portion of the system.
7. Gather information about quality characteristics and nonfunctional requirements from users.
8. Elaborate the use cases into the necessary functional requirements and document them.
9.Review the use case descriptions and the functional requirements.
10. Develop analysis models if needed to clarify the elicitation participants’ understanding of portions
of the requirements.
11. Develop and evaluate user interface prototypes for portions of the requirements that are not clearly
understood.
12. Develop conceptual test cases from the use cases.
13. Use the test cases toverify the quality of the use cases, functional requirements, analysis models,
and prototypes.
14. Repeat steps 6 through 14 for the other portions of the system until the team concludes that
requirements elicitation is as complete as it needs to be.
15. Baseline the documented requirements.

Figure 1. A suggested requirements development process.

A lack of agreement over what to call the...