« Table of Contents »
Previous « The Behaviour Specification Writing Process
The Behaviour Specification Handbook
The Behaviour Specification Writing Process
Prerequisites
There are two important prerequisite inputs for writing Behaviour Specifications — the business requirements and an initial low-level technical design. I cannot stress enough how important these prerequisites are to hosting a successful Behaviour Specification writing session!
Requirement Analysis Complete
Imagine that your team has just moved a User Story from the Backlog into an In-Progress phase where analysis is to performed and the Behaviour Specifications written. Before your team meets to determine and write the Behaviour Specifications for that User Story, ensure that the business requirements analysis is as complete as possible by having various conversations and workshops with all the relevant people, in order to gain enough clarity. Once the requirements are generally well-understood and an initial design is drafted, the team can proceed to actually writing the Behaviour Specifications.
The nemesis of a Behaviour Specification writing session is unknown, unclear or incomplete requirements. Unclear requirements are the primary cause of elongated discussions, frustration and confusion in a Behaviour Specification writing session. During the Behaviour Specification writing session, if missing requirements are identified, I recommend that you simply make a note of them for later and carry on — if possible. On the other hand, if there is a critical requirement missing, it could be wiser to postpone the session until the relevant details of the requirement can be determined.
If a team ever walks away exhausted from a Behaviour Specification writing session or thinking that the process is difficult, I can almost guarantee that there was a lack of requirements analysis performed before the meeting. The requirements gathering, analysis and clarification is the difficult work that requires and causes the most discussion, time, effort and agreement. Requirements analysis is thus defined as a prerequisite that should remain a very separate process from writing Behaviour Specifications.
I have witnessed many Behaviour Specification writing sessions turn into requirements analysis workshops. This in itself is not a bad thing — indeed the Behaviour Specification writing meeting has just succeeded in facilitating, identifying and initiating other important discussions. However, if this happens in your sessions, please be careful to clearly communicate to your team that the Behaviour Specification writing session has been postponed and the team instead is now performing more requirements analysis.
If the boss or various stakeholders think that the team have been “doing” Behaviour Specifications for days, with none of the expected outputs produced (because most of the effort has been requirements analysis and clarification), then they are not receiving accurate information for tracking and planning purposes. A possible next, unfortunate and counter-productive step is for the stakeholders to start questioning the overall process and value of BDD — so be careful! It is unfair to blame the process of writing Behaviour Specifications for delays that arise due to an unfulfilled prerequisite — when the culprit is a lack of requirements or business analysis.
Core Business Requirements
There are different types and ways of describing requirements. For the purpose of the Behaviour Specification writing meeting, it is most useful to have not just the business requirements understood, but the “core business requirements” understood beforehand.
A core business requirement has a clear purpose and business value, and it explicitly does not contain a description or specification of the implementation details.
If a “requirement” includes implementation detail, then there is the awkward situation where non-technical business colleagues are effectively dictating the implementation design to the technical experts. The technical folk however may think of a better implementation option, if they were empowered and given the opportunity.
Sometimes the “core” requirements are already known, but many times the author of a requirement has innocently encoded implementation-specific details within the requirement. A common example is with User Interface requirements. The User Interface requirement may, for instance, specify the need for a new textbox on a screen. That however is not a “core business requirement” because both “textbox” and “screen” are implementation details.
It is more beneficial to take these implementation-specific requirements and convert them back to “core business requirements”. The “5 Whys” principle can be used to find the “core” or root requirement. The “core business requirement” can be uncovered by iteratively asking “Why?” or “What is the real underlying business need for doing XYZ?".
Core Business Requirements — An Example of Iterative Whys
Here is a contrived example. Let us assume that the documented requirement is: “Display a new textbox on screen XYZ so we can enter data for ABC”.
Now let us iteratively ask “Why?” to find the “core business requirement”.
Q) Why?
A) Because we want to enter data for ABC and screen XYZ has related stuff on it.
Q) Why do you need the data for ABC?
A) We need that data for ABC to calculate MNOP.
Q) Why do you need to calculate MNOP?
A) To correctly invoice the customer.
With this understanding we can now state that the “core business requirement” is: “To receive information about ABC so that the customer can be invoiced correctly”.
That is the flavour of business language that I highly recommend be used in the documentation of requirements and Behaviour Specifications — not implementation-specific language about a textbox!
Initial Low-Level Technical Design Complete
After sufficient business requirements have been gathered and clarified, and before the Behaviour Specification writing session, the solution architects, technical architects, designers and gurus in the team should have met, discussed and sketched out an initial, draft version of a low-level technical design. This technical design should identify the systems and software components that are likely to be involved in the solution for the User Story. If an even more mature technical design can be determined, then even better.
During the Behaviour Specification writing meeting, the team will focus on defining the behaviours of each of the software components that were identified in this low-level technical design.