Chapter 8. Organizing scenarios into a specification suite

 

This chapter covers

  • Organizing scenarios into specifications
  • Organizing specifications by outcome and stakeholder
  • Working with functional and nonfunctional requirements
  • Choosing among features, abilities, and business needs

I remember one particular specification my team and I worked on. The scenarios were meant to describe a highly personalized management panel for the organization’s key performance indicators (KPIs). We started with a few KPIs and no option to combine them to create custom reports. Putting the scenarios in a single feature file seemed an obvious choice back then—but in the end, that turned out to have been a bad decision.

The file kept growing as new KPIs appeared. At the time, we didn’t recognize the difference between exhaustive and illustrative examples, so we tested too many combinations. The specification ended up being unreadable. It had 508 lines of text—about 10 times as many as the longest ones you’ve seen in this book so far. When we finally rewrote the specification, we found that we had specified the same option in two separate scenarios because we hadn’t noticed that a similar example already existed. If we’d had a different, more focused organization system, we would have been able to consider the granularity of our scenarios from the start.

8.1. Is organizing scenarios by features a good idea?

 
 

8.2. Organizing scenarios by user stories

 

8.3. What about nonfunctional requirements?

 
 
 

8.4. Answers to exercises

 
 
 

8.5. Summary

 
 
sitemap

Unable to load book!

The book could not be loaded.

(try again in a couple of minutes)

manning.com homepage