Using Specification by Example to become a better business analyst

A couple of weeks ago Equinox IT Systems Analyst and Agile Coach Ben Hughes and I delivered a presentation at the International Institute of Business Analysis (IIBA^®) BA Development Day event in Wellington (and subsequently at a mini IIBA half-day in Christchurch). The presentation was entitled How to become a ‘Specification by Example’ rocket scientist. The slides from that presentation are included below:

In this article I summarise some of the key points from that presentation, for those who were unable to attend or who want to know more. The focus of the presentation was on using Specification by Example to be a better business analyst.

The problem of requirements that can’t easily be developed or tested

We have all been there on software development projects. You have prepared the requirements and the business has finally signed them off, yet the developers don’t really understand what black and white code needs to be developed and the testers are uncertain whether a developed feature actually meets a given requirement or not.

Often in projects you, as a BA, are solely responsible for ensuring the requirements are “correct” and as such you strive to ensure that all possibilities are covered. This approach results in the unfortunate generalisation of requirements down to a generic form, because then the requirements are “correct”, in that what they say is true. However, at this generic level the requirements do not provide the specific details necessary for the team trying to deliver a working product, be that a piece of software or something else.

Wear your audience’s shoes

Testers are always taught to test one thing at a time. A poorly written test can result in multiple failure states, meaning that if the test fails, it is impossible to understand from that test why it failed.

When wearing the shoes of a tester, business analysts can similarly document or describe one thing at a time. This will help overcome poorly written requirements that muddy the distinction between features, which can make the requirements hard to implement let alone test. This will also break things down to make it easier for both developers and the business you are representing to understand each requirement.

As a BA, early collaboration with testers and other members of a delivery team will help you to understand what is required to develop and test the requirements. This in turn should help you to write requirements that are understood by the whole team, both during the analysis phase and right through development and delivery.

What is Specification by Example?

Specification by Example is a collaborative approach for defining requirements and functional tests using realistic concrete examples instead of abstract statements. It is often used in Agile software development projects (but as we describe later the approach can also be used with other development methods). The approach focuses on ensuring that everyone involved in a problem, solution or opportunity has the information necessary to succeed. This also includes members of the business areas impacted.

The two main ways of using Specification by Example are tables and scenarios. Tables are used to describe inputs and their corresponding outputs whereas scenarios use the ‘Given - When – Then’ format which describes the preconditions (the Givens) the triggers (the Whens) and the outcomes realised (the Thens).

What is the business analyst's role in Specification by Example?

While BAs are accountable to their teams to ensure that the documented requirements are correct, Specification by Example broadens the discussion around correctness to the team as a whole. Everyone involved has an equal opportunity to be heard and all members of the team have a shared responsibility to ensure a quality product.

As a BA your role is to facilitate the discussions the group is having, ensuring not only that the right people are involved, but also that the right discussions are being held, along with documenting the outcomes of the discussions in the form of Specification by Example tables or scenarios.

You can also use the approach as a great and natural conversation starter during requirements elicitation. Try giving people a half finished example or a table that doesn’t cover all possible options. People love to point out other’s ‘shortcomings’. Most will at the very least point out what’s wrong or missing, if not attempt to correct it.

Why use Specification by Example as a BA?

Specification by Example helps address the earlier stated problems. You can use it to help deliver requirements that can be developed and tested. You can use to better understand and clearly communicate the business’s specific needs, thereby increasing the likelihood that the end product delivers excellent value to the business.

In particular, it is a useful approach for making the generic requirements specific and for providing concrete examples that can be discussed and used to drive out true understanding across the team. A happy consequence of the collaborative approach is also that the team ‘owns’ not only the requirements but the whole process, which naturally results in better quality output.

We know from research conducted by IBM Research Sciences Limited that the earlier a problem is found, the cheaper it is to resolve. Specification by Example helps the team to drive the discussion to concrete examples that, by their very nature ensure coverage, (as holes are so easy to identify and fill) thereby pushing the discovery of the problem earlier in the development journey.

By its very nature Specification by Example also makes it easy for you as a BA to record quality requirements, measured by whether or not a requirement meets the quality conditions as set out in section 7.2.4 of the Business Analysis Book of Knowledge (BABOK^®) version 3.

These are:

• Atomic: As we’ve already talked about Specification by Example forces the concentration on a single function, making non-atomic requirements easy to spot.
• Complete: As the team works together to create the wording for the requirement the team will naturally be at the level required for the work at hand, be that high level scoping, or detailed functional requirements.
• Consistent: When the requirements are viewed together contradictions or different levels of requirement in the same requirements set are easy to spot and rectify.
• Feasible: As the team discusses all requirements together this enhances the collective understanding of effort to deliver, and therefore whether or not what is being described is feasible or not.
• Unambiguous: The method directly makes the need or function required explicit, making it easy to see if a proposed solution meets that need.
• Testable: The collaborative nature of Specification by Example along with the other quality characteristics ensures that requirements written using this method are testable.
• Understandable: A common language will evolve through the collaboration of the team, which enhances understanding while the formats used help to ensure assumptions are identified and resolved early.
• Prioritised: this is the only quality condition not inherent within the method however if the other conditions are met, it makes prioritisation an easier exercise as understanding is common and dependencies are easier to spot than with other methods.

What software development methods can you use Specification by Example with?

There are a lot of development frameworks and methods in use across the many development projects that we find in New Zealand. Each framework or method offers something different to the mix. For the purposes of understanding the value of Specification by Example, it doesn’t really matter which approach you take, (although iterative and agile development have other characteristics that support the collaborative nature of Specification by Example) each approach is just a different engine for your spaceship.

Next steps

Like any other technique Specification by Example is not a silver bullet; it is however a very useful tool that can be added to any business analyst’s toolbox.

In this article I have set out some key considerations for what Specification by Example is, the BA’s role, and why you should consider using this approach. The article hasn’t provided detail on how to use the approach as a BA, and perhaps that would be a good topic for a future article. In the meantime I encourage you to find out more about Specification by Example and start thinking about how you could apply it to add value within the context of the work that you do as a business analyst.

If you have observations from applying Specification by Example, please put them in the comments, it would be great to hear your experiences with this approach.

Kirsten Eriksen is a senior consultant specialising in business analysis and is based in Equinox IT’s Wellington office in New Zealand.

IIBA^® and BABOK^® are registered trademarks owned by International Institute of Business Analysis.