Home > Articles > Software Development & Management > Object Technology

Becoming a Software Developer Part 4: Understanding Use Cases and Requirements

  • Print
  • + Share This
Where do requirements come from? How can use cases help to record requirements? What does a good use case look like? What do I do with a use case once I have it?
Pete McBreen is the author of Software Craftsmanship: The New Imperative (Addison-Wesley, 2001, ISBN 0-201-73386-2). Software Craftsmanship is the winner of the Productivity Award for Software Development magazine's 12th Annual Jolt Awards (see http://www.sdmagazine.com/jolts/).
From the author of

Introduction

One very intriguing aspect of software development is that whenever someone gets an idea for a new application, we nearly always think that it will be easy to implement. Only after getting a closer look at what the idea really involves do we begin to get a clue about the true complexity of the new application. No matter how much experience a developer has, the first guess as to how long the application will take to create is going to be completely wrong.

To give a sense of this, let's consider a simple application, say a membership system for a running club. Nothing too complicated, you understand—just a means of recording the members' names and addresses, tracking when their membership fees are due, and sending email to notify members about upcoming events and races. It would also be nice if there was a way of recording race results so that the club could publish lists of age-ranked results in the newsletter.

How hard could it be to produce a little application like that? It sounds quite trivial, doesn't it? Take a guess now, and after you've finished reading this article see whether you would revise your original estimate.

  • + Share This
  • 🔖 Save To Your Account