Building A System 'Not' Around Exceptions?

Those were the pre-corona days and pre-google-maps days :-) I lived in Australia then. I had started to use a dedicated GPS navigator device while driving. Eagerly waiting for the lady in the GPS to tell the directions, irritated if she doesn't speak, I got used to it all. I understood that she would start talking only when there is an exception, i.e. when I am going off the direction. Or just before I need to make any change while driving. It means that, on the desired path, the lesser the exceptions the better. In other words, the more I am on the main path, the less get to hear from the GPS lady for exceptions!

The reason to bring this up here in this post is to talk about the business analyst's role as a navigator. How good we are as navigators? In helping the conversations and collaborations? In writing the specs? Business analysts ensure that the system is being on the desired path and not on the exception path! I am sure we can argue that we want to build exception paths, errors, and scenarios that break the system. It is true. If we observe everyday linguistic patterns, there is a natural human tendency to talk about what we do 'not' want. Whereas what we 'want' is something that needs to succinctly be delved into. Is this a clever play of words? No. It is about utilizing 80/20 rule in thinking through what process or system you want to build. 80% on where you want to do and 20% on what exception and roundabout scenarios you can expect of. Let's take a few simple examples as we relate this to a business analyst's role.

Example 1: Alternate paths in a use case becoming main paths

As we know, each use case has a specific goal associated with it, for a given user or actor. To achieve that goal, a business analyst initiates the detailing of that use case. (Requirements Analysis and Design knowledge area from BABOK®). Use case specification has the main path, alternate paths, and exception paths. If we are on the right side of elicitation and writing specs, we would focus on the main path more. It is imperative that we would also discuss alternate and exception paths as well with the stakeholders and write those in the specs.

Example 2: User stories have no 'so that' clause in it

If a user story is missing out on a concrete "so that" clause, it means we need to understand the exact benefit or value of it. Why exactly this feature needed? It sounds trivial to write or not write this clause. Especially when we are running out of time and there is deadline pressure. Now coming back to the original storyline! If and only if there is a user benefit of a given user story, it means the story has value. Else it is either a lesser priority and we can put that story later in the backlog until it is on the 'happy path'.

Example 3: Too many error conditions in a user interface

This one is interesting too. It requires system designing efforts to anticipate what errors and alerts a user interface could throw or show. At the same time, the end-users do not like to be involved in detecting and find a remedy to the problems. They would like to see errors to be prevented in the first place. That again means the requirements should be written such that those state how a system or a user interface eliminates the errors or alerts through intuitive and user-friendly steps and design.

The above-mentioned examples are classically observed during writing functional or detailed requirements. Coming back to the GPS navigator. This topic has been on my mind for a long time. Being an NLP practitioner, I felt the need to bring it up especially in the context of the business analyst's role. The key is to keep the main thing the main thing. Happy driving!

Thoughts?

Picture credit: Image by Dariusz Sankowski from Pixabay

Author: Swati Pitre, CBAP^®, is Sr. Business Analyst 

Sr. Business Analyst, Consultant and Trainer with 20+ years of industry experience across various domains and geographies. Recognized by clients as a valued member of business and technology teams, with a proven track record of delivering artifacts and solutions of high quality. Recognized by participants as a highly effective and hands-on trainer and coach. Self-starter, process-oriented, and creative with unique problem-solving skills.

Her specialities include Process Improvement, BPM, Predictive Analytics, Product Development, Quality, and Governance. She undertakes various training courses such as CBAP®/CCBA®/ECBA® Prep Courses, Comprehensive BA Job oriented Course, Agile BA Course, and several other customized courses.

She is also a public speaker and has completed Level 3 of Effective Coaching Pathway at Toastmasters International. She is a yoga and fitness enthusiast with varied hobbies include reading, writing, art, travelling and music.

LinkedIn: Swati Pitre, CBAP® | LinkedIn