In recent months we have overhauled the Intechnica development process to use a lot of the BDD – Behaviour Driven Development – and “Specification by Example” (http://gojko.net/) processes and tools for specification definition. As such we have defined the 6 rules of good specifications:
1. Communication between client, BA, QA and developer:
The more all of these people talk, and the earlier they are involved in specification stage, the better.
2. Don’t define user experience and business functionality in one place.
It leads to repetition and confusion. It also tends to lead to underlying systems designed around the UI rather than the business domain.
3. Illustrate all business logic with examples
…not with wordy descriptions.
4. Illustrate all UI with annotated pictures
…or ideally full HTML prototypes.
5. Specifications must be testable to form objective acceptance tests.
Tests should be automated and built into your continuous integration process.
6. Specifications should be living documents
…and evolve into the living documentation of the system.
Pingback: 6 Rules for Good Specifications in Software Development « intechnica | Agile Software Development | Scoop.it
Pingback: 6 Rules for Good Specifications in Software Development « intechnica | DevOps in the Enterprise | Scoop.it
Pingback: 6 Rules for Good Specifications in Software Development | Metodologías de Desarrollo de Software | Scoop.it
“2. Don’t define user experience and business functionality in one place.”
This is a bit simplistic, you then need to go on to say “don’t confuse experience with function”. You can define your UI experience, but you should not define function by describing the UI to fulfill it
eg.
Functional:
Given I’m a customer
When I add an order
My order is retained by the system
-and-
Experience:
Given I am a system user
When I add data to the system
Then the interface will have input fields with a light blue background and black text
(Experience doesn’t always translate well to gherkin! – but this is just to illustrate the point)