Page 106 -

I T SEEMS OBVIOUS that we need to know what software is supposed to do before we build it.

Nevertheless, many projects are delayed (or fail completely) because development begins
before anyone on the project team really understands how the software should behave.
The solution to this problem is to take the time to gather and verify the software require-
ments—documentation that completely describes the behavior that is required of the soft-
ware—before the software is designed, built, and tested.
When starting a new project, programmers are often tempted to just dive in, beginning to
build the software as soon as they have the general gist of what it is supposed to do. It’s
not hard to see why people do this: many programmers develop advanced programming
skills without ever having to figure out and write down the requirements for even a sim-
ple software project. For example, many good programmers hone their craft by building
software that they intend to use themselves. In these projects, the programmer does not
need to take time to understand the behavior of the software—she intuitively knows what
the software is supposed to do from the beginning of the project.
However, most software is built to meet the needs of someone other than the programmer.
If those needs are going to be satisfied, the behavior of the software must be planned before
the software is built. Software requirements engineering is the art and science of developing an
accurate and complete definition of the behavior of software that can serve as the basis for
software development. Like project management, programming, and testing, software
requirements engineering encompasses a set of skills that require training and practice.

Software requirements engineering tasks are usually performed by skilled requirements
analysts (who sometimes have the title “Business Systems Analyst”). If a project manager
does not have a requirements analyst on his team, he may be able to rely on existing team
members to fill this role. There is a good deal of overlap between the skills required for
design, programming, and testing, and those required for software requirements engineer-
ing. A team member willing to spend time learning new skills (and a team willing to work
with him and help him through this task) will often be able to build software require-
ments that are sufficient for building and testing. This chapter covers some of the most
important practices that a requirements analyst uses.

Requirements Elicitation
Requirements elicitation is the process through which a requirements analyst gathers, under-
stands, reviews, and articulates the needs of the software project’s stakeholders and users.
Elicitation involves fact-finding, validating one’s understanding of the information gathered,
and communicating open issues for resolution. The objective of this activity is to create a
complete list of what the users believe are important requirements. Elicitation activities can
include:
• Interviews with the users, stakeholders, and anyone else whose perspective needs to be
taken into account during the design, development, and testing of the software
• Observation of the users at work
• Distribution of discussion summaries to verify the data gathered in interviews

98 CHAPTER SIX