« Table of Contents »
Previous « What’s Happening In Our Minds?
The Behaviour Specification Handbook
The Behaviour Specification Writing Process
Meeting Milestone 4 — Behaviour Identification
Now that the requirements are understood by the team and there is general agreement that sufficient requirements are known and the technical design is sound enough, the process of writing the Behaviour Specifications can begin.
The first phase of actually writing the Behaviour Specifications involves identifying and writing all the Behaviour Specification Descriptions for the software components from the low-level technical design.
This is the most critical and most difficult part of the writing process. In order to be most effective, everyone who was invited to the meeting actually needs to attend. Each individual perspective is beneficial and necessary for creating the best possible solution that fulfils all of your needs.
This milestone is designed specifically to facilitate and maintain a brainstorming flow where the attendees stay focused at a high-level and look down upon the entire behaviour landscape of a single component. This approach is more efficient and less confusing than repeatedly diving deep, narrowing the focus to a single behaviour, and then resurfacing and trying to recover the wider perspective.
The Goal
Please keep in mind that the goal is to specify all the behaviours that each software component should individually perform. This is a true program specification for a component. The only code that should be written by developers is code that fulfils the Behaviour Specifications. The only test cases that need to exist and be performed (excluding exploratory testing, or independent testing) are those represented by the Behaviour Specifications. Remember this easy guideline: “No Behaviour Specification? No Code! No Test!”
The Behaviour Identification Procedure
The simple procedure to identify and describe the behaviours to be delivered is:
-
Carefully examine the low-level technical design and pay attention to all the different software components;
-
Ensure that the team understands how each software component fits into the overall solution;
-
For each software component, one-by-one, narrowly focused on just one component at a time, answer the following question:
"Within the context, boundary and responsibility of just this software component, what are the behaviours this component should perform in order to fulfil all the requirements?”
Of course, now is a great time to refer back to that bullet-point list of core requirements; and -
Summarise and describe each identified behaviour individually as a Behaviour Specification Description. For more information, see the chapter Effective Behaviour Specification Descriptions.