Success with Requirements

But it's important not to misinterpret YAGNI. It doesn't mean don't document your requirements because you'll never need or use it.

This is an extreme interpretation of a sensible principle. Instead, YAGNI means that you'll benefit from paying close attention to what you document and how.

Form: The form of business requirements might be a list of goals and objectives. User requirements might take the form of scenarios, business rules, and a data model. The form of quality attributes might be text statements, a subset of "Planguage" (Planning Language) elements, or quality attribute scenarios.

Format: The format of scenarios might be handwritten statements on index cards or templated scenarios recorded in a spreadsheet or Word document. The format of your data model might be a rough draft sketched on a poster or whiteboard, or a diagram drawn in a tool such as Visio. If you write your quality attributes using Planguage, you might format them in a Word document that will be traced to test cases in a requirements management tool.

Be practical. If your developers are co-located with the customers and are very familiar with the business domain, they won't read or work off of detailed requirements specification documents. But if you plan to outsource or offshore development, it's essential to write formal documentation supplemented by visual models.

On an agile project, you know that requirements will evolve. So it doesn't provide business value to write a detailed specification with all the requirements that will be needed. Indeed, a study (Standish, 2003) showed that 45 percent of specified requirements were never delivered. While there may be many reasons for undelivered requirements and even a rationale for some documentation of requirements you know you won't deliver, you should strive for a minimalist approach whenever possible. In some situations you will find it more efficient to write brief requirements in the form of stories, accompanied by "doneness" tests (such as acceptance tests).

• Is our customer willing to pay for the time it takes to document requirements?
• What is the risk to the project and product if we do not create this particular documentation?
• What specific documentation is needed by external entities (regulatory, governmental, oversight agencies)?
• How can we reduce the time we spend revising documentation?
• How will we know the requirements documentation we have is "good enough"?

• Who will use each requirements document we produce, and how will they use it?
• Is this documentation necessary to architect, build, test, or maintain the product?
• What models (text and visual) can we use to elicit and validate requirements with customers before we invest in building and testing?
• What's the minimum amount of documentation we need to create a prototype or to demonstrate a partial solution?
• Which requirements documents are most often used to enhance or maintain the product?
• Will anyone use this documentation after the product is built?
• Who is going to maintain the documentation?

~ ellen

Standard citation for this article:
Ellen Gottesdiener, "YAGNI Your Requirements Docs," Success with Requirements, Vol. 1, No. 9(2007).

Reference
Standish Group International, Inc. 2003. Standish Group Study. Reported by Jim Johnson, chairman, XP 2002 Conference.