Beginning Software Engineering

CHAPTER 4 Requirement Gathering

If you don’t know where you are going, you’ll end up someplace else.

—YOGI BERRA

WHAT YOU WILL LEARN IN THIS CHAPTER:            

• Why requirements are important
• The characteristics of good requirements
• The MOSCOW method for prioritizing requirements
• Audience-oriented, FURPS, and FURPS+ methods for categorizing requirements
• Methods for gathering customer goals and turning them into requirements
• Brainstorming techniques
• Methods for recording requirements such as formal specifications, user stories, and prototypes

It’s tempting to say that requirement gathering is the most important part of a software project. After all, if you get the requirements wrong, the resulting application won’t solve the users’ problems. You’ll be like a tourist in Boston with a broken GPS. You may get somewhere interesting, but you probably won’t get where you want to go.

Even though requirements are important for setting a project’s direction, a project can fail at any other stage, too. If you build a flawed design, write bad code, fail to test properly, or even provide incorrect training materials, the project can still fail. If any one of the links in the development chain fails, the project will fail.

Let’s just say that requirement gathering is the first link in the chain, so it’s the first place where you can screw things up badly. Requirements do set the stage for everything that follows, so while you can argue over whether this is the most important step, it’s ...