- Why User Stories?
- User Stories Aren't Use Cases
- User Stories Aren't Requirements Statements
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
User Stories Aren't Requirements Statements
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. [5] This document, known as IEEE Standard 830, was last revised in 1998. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830–style software requirements specification is the use of the phrase "The system shall...," which is the IEEE's recommended way to write functional requirements. A typical fragment of an IEEE 830 specification looks similar to the following:
4.6) The system shall allow a company to pay for a job posting with a credit card.
4.6.1) The system shall accept Visa, MasterCard, and American Express cards.
4.6.2) The system shall charge the credit card before the job posting is placed on the site.
4.6.3) The system shall give the user a unique confirmation number.
Documenting a system's requirements to this level is tedious, error-prone, and very time-consuming. Additionally, a requirements document written in this way is, quite frankly, boring to read. Just because something is boring to read is not sufficient reason to abandon it as a technique; however, if you're dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it's not going to be read thoroughly by everyone who needs to read it. Readers will either skim or skip sections out of boredom. Additionally, a document written at this level will frequently make it impossible for a reader to grasp the big picture.
There's a tremendous appeal to the idea that we can think, think, think about a planned system and then write all the requirements as "The system shall...." That sounds so much better than "If possible, the system will..." or even "If we have time, we'll try to..." that better characterizes the reality on most projects.
Unfortunately, it's effectively impossible to write all of a system's requirements this way. A powerful and important feedback loop occurs when users first see the software being built for them. When users see the software, they come up with new ideas and change their minds about old ideas. When changes are requested to the software contemplated in a requirements specification, we've become accustomed to calling it a "change of scope." This type of thinking is incorrect for two reasons. First, it implies that the software was at some point sufficiently well-known for its scope to have been considered fully defined. It doesn't matter how much effort is put into upfront thinking about requirements; we've learned that users will have different (and better) opinions once they see the software. Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills the goals of the intended user. If the scope of the user's goals changes, perhaps we can speak of a "change of scope," but the term is usually applied even when only the details of a specific software solution have changed.
IEEE 830–style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user's goals. And lists of requirements don't give the reader the same overall understanding of a product that stories do. It's very difficult to read a list of requirements without automatically considering solutions in your head as you read. Carroll, for example, suggests that designers "may produce a solution for only the first few requirements they encounter." [6] For example, consider the following requirements: [7]
3.4) The product shall have a gasoline-powered engine.
3.5) The product shall have four wheels.
3.5.1) The product shall have a rubber tire mounted to each wheel.
3.6) The product shall have a steering wheel.
3.7) The product shall have a steel body.
By this point, I suppose images of an automobile are floating around your head. Of course, an automobile satisfies all of the requirements listed above. The one in your head may be a bright red convertible, while I might envision a blue pickup. Presumably the differences between your convertible and my pickup are covered in additional requirements statements.
But suppose that instead of writing an IEEE 830–style requirements specification, the customer told us her goals for the product:
The product makes it easy and fast for me to mow my lawn.
I am comfortable while using the product.
By looking at goals, we get a completely different view of the product: the customer really wants a riding lawnmower, not an automobile. These goals are not user stories, but where IEEE 830 documents are a list of requirements, stories describe a user's goals. By focusing on the user's goals for the new product, rather than a list of attributes of the new product, we can design a better solution to the user's needs.
A final difference between user stories and IEEE 830–style requirements specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written. The typical scenario is that one or more analysts spends two or three months (often longer) writing a lengthy requirements document. This document is then handed to the programmers, who tell the analysts (who relay the message to the customer) that the project will take 24 months, rather than the six months they had hoped for. In this case, time was wasted writing the three-fourths of the document that the team won't have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time. With stories, an estimate is associated with each story immediately. The customer knows the velocity of the team and the cost of each story. When she has written enough stories to fill all the iterations, she knows she's done.
Kent Beck explains this difference with an analogy of registering for wedding gifts. [8] When you register, you don't see the cost of each item. You just make a wish list of everything you want. That may work for weddings, but it doesn't work for software development. When a customer places an item on her project wish list, she needs to know its cost.