(Note: The series on Extreme Remote will continue as a weekly post next Monday. At this time, we are launching a second series of posts with the theme: Delightful Requirements)

Requirements. You're gonna have 'em. Whether they are a hallway conversation with the developer, or a ten-pound doorstop of a requirements document. Somehow, there needs to be an agreement of what software should be developed before the code gets written.

In an agile development process, you should avoid Big Up Front Design; but, you still need requirements. Ideally, the requirements are drafted some time before a sprint starts. Then, during sprint planning, they are reviewed, adjusted, approved, and committed. The form of these requirements may vary.

At Amplified Development, we are enthusiastic proponents of Gherkin requirements (aka Cucumber, SpecFlow, Behave, etc.). Gherkin is a structured language that is designed to be easily understood by business stakeholders, and to be readily wired up to automated test code. It has this basic structure:

Scenario: Feature performs desired behavior
  Given some prerequisite state exists
  When I take some action
  Then I can verify the desired behavior occurred

This is the first in a series of posts that describes best practices for writing Gherkin. Your goal, simply put, is to write requirements that delight those who read them, whether they are business-oriented, developers, or quality assurance experts. (It may be hard to picture anyone being delighted to read software requirements; but, for those with skin in game, well-written requirements just make every iteration, every day, go more smoothly. And, who wouldn't be delighted with that?) Business-oriented stakeholders should sense that you have captured how their business really works and have described a software system that will make their business work better. Developers should readily form a clear picture of the software they must create. Quality assurance experts should feel confident that little ambiguity exists and problem cases have been adequately covered.

We will first discuss a few high-level principles that will provide guidance towards high-quality requirements:

Seek the sweet-spot between meeting the needs of business stakeholders and those of developers.
Examples are your friend
Hide distracting details