Rimu Research


Immediate Storytest Feedback


Paper and Talks



Coaching on Approaches to Requirements

For project teams that are having problems with requirements and are interested in looking at the latest agile software development approaches. Instead of writing static documents, we advocate writing requirements as storytests. These express, through concrete examples, the business rules concerned.

Starting with concrete examples instead of general statements can be an effective way to really understand a business domain, without getting lost in detail. Storytests are expressed in a tabular form that can also be used as tests, to test that a requirement has been met, and continues to be met in the system as it changes.

1. One Day Introduction to Approaches to Requirements

  • Overview of storytests as a way of writing requirements (why and how), presented to the whole team.
  • Storytest Driven Development and evolutionary software development.
  • 2. Multi-day Onsite Coaching on Approaches to Requirements

    Here's one example. Contents:

    • Present overview of storytests as a way of writing requirements (why and how) to the whole team. Storytest Driven Development and evolutionary software development.
    • Coach the Product Managers, Testers, and Business and Systems Analysts for 4-6 days. Start with a simple example for a part of the requirements. Initially I'll sketch storytest tables on the whiteboard and alter them as we progress. We may start with a simple workflow, possibly based on use cases. Then we'll write a second storytest for a variant workflow. Then we'll focus on the underlying business rule and express that as a calculation rule. After we'd tackled a few stories, the participants will gradually do more of the development of the storytests. I won't formally introduce the details of tables, but will show by example what could be done.
  • I'll show by example how to use FitNesse, a tool for creating and running storytests.
  • Coach the programmers for 2-10 days. Start with one or two programmers on one of the storytests. How to write fixtures, which mediate between the storytests and the application system. How to drive the code development from the storytests. When to start test driving with unit tests. Driving the business domain into the code. Resolving differences between current code and storytests. Handling design smells.
  • Ongoing coaching, one day a week for several weeks, to locate issues and to help with those that arise.
  • This can take longer than initially expected because the storytests often expose problems in the way that the software is being developed. Coaching in OO design, Test Driven design, and domain design may be needed as much as coaching in storytest driven development.

    I've carried this out this general approach with several organizations, with groups of from 25 to 60 people.

    Copyright, Rick Mugridge, Rimu Research, 2006 .. 2009.