Share this
Using Specification by Example to become a better business analyst
by Kirsten Eriksen on 15 December 2015
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.
Share this
- Agile Development (153)
- Software Development (126)
- Agile (76)
- Scrum (66)
- Application Lifecycle Management (50)
- Capability Development (47)
- Business Analysis (46)
- DevOps (43)
- IT Professional (42)
- Equinox IT News (41)
- Agile Transformation (38)
- IT Consulting (38)
- Knowledge Sharing (36)
- Lean Software Development (35)
- Requirements (35)
- Strategic Planning (35)
- Solution Architecture (34)
- Digital Disruption (32)
- IT Project (31)
- International Leaders (31)
- Cloud (26)
- Digital Transformation (26)
- Project Management (26)
- Azure DevOps (23)
- Coaching (23)
- IT Governance (23)
- System Performance (23)
- Innovation (21)
- Change Management (20)
- MIT Sloan CISR (15)
- Client Briefing Events (13)
- Architecture (12)
- Working from Home (12)
- IT Services (10)
- Data Visualisation (9)
- Kanban (9)
- People (9)
- Business Architecture (8)
- Communities of Practice (8)
- Continuous Integration (7)
- Business Case (4)
- Enterprise Analysis (4)
- Angular UIs (3)
- Business Rules (3)
- GitHub (3)
- Java Development (3)
- Lean Startup (3)
- Satir Change Model (3)
- AI (2)
- API (2)
- Automation (2)
- Scaling (2)
- Security (2)
- Toggles (2)
- ✨ (2)
- .Net Core (1)
- Diversity (1)
- Microsoft Azure (1)
- Testing (1)
- December 2024 (1)
- August 2024 (1)
- February 2024 (3)
- January 2024 (1)
- September 2023 (2)
- July 2023 (3)
- August 2022 (4)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- March 2021 (1)
- February 2021 (2)
- November 2020 (2)
- September 2020 (1)
- July 2020 (1)
- June 2020 (3)
- May 2020 (3)
- April 2020 (2)
- March 2020 (8)
- February 2020 (1)
- November 2019 (1)
- August 2019 (1)
- July 2019 (2)
- June 2019 (2)
- April 2019 (3)
- March 2019 (2)
- February 2019 (1)
- December 2018 (3)
- November 2018 (3)
- October 2018 (3)
- September 2018 (1)
- August 2018 (4)
- July 2018 (5)
- June 2018 (1)
- May 2018 (1)
- April 2018 (5)
- March 2018 (3)
- February 2018 (2)
- January 2018 (2)
- December 2017 (2)
- November 2017 (3)
- October 2017 (4)
- September 2017 (5)
- August 2017 (3)
- July 2017 (3)
- June 2017 (1)
- May 2017 (1)
- March 2017 (1)
- February 2017 (3)
- January 2017 (1)
- November 2016 (1)
- October 2016 (6)
- September 2016 (1)
- August 2016 (5)
- July 2016 (3)
- June 2016 (4)
- May 2016 (7)
- April 2016 (13)
- March 2016 (8)
- February 2016 (8)
- January 2016 (7)
- December 2015 (9)
- November 2015 (12)
- October 2015 (4)
- September 2015 (2)
- August 2015 (3)
- July 2015 (8)
- June 2015 (7)
- April 2015 (2)
- March 2015 (3)
- February 2015 (2)
- December 2014 (4)
- September 2014 (2)
- July 2014 (1)
- June 2014 (2)
- May 2014 (9)
- April 2014 (1)
- March 2014 (2)
- February 2014 (2)
- December 2013 (1)
- November 2013 (2)
- October 2013 (3)
- September 2013 (2)
- August 2013 (6)
- July 2013 (2)
- June 2013 (1)
- May 2013 (4)
- April 2013 (5)
- March 2013 (2)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (1)
- October 2012 (2)
- September 2012 (3)
- August 2012 (3)
- July 2012 (3)
- June 2012 (1)
- May 2012 (1)
- April 2012 (1)
- February 2012 (1)
- December 2011 (4)
- November 2011 (2)
- October 2011 (2)
- September 2011 (4)
- August 2011 (2)
- July 2011 (3)
- June 2011 (4)
- May 2011 (2)
- April 2011 (2)
- March 2011 (3)
- February 2011 (1)
- January 2011 (4)
- December 2010 (2)
- November 2010 (3)
- October 2010 (1)
- September 2010 (1)
- May 2010 (1)
- February 2010 (1)
- July 2009 (1)
- April 2009 (1)
- October 2008 (1)