Analysts everyday and in every domain of business come across obstacles in their analysis and efforts that prevent them from best meeting the needs of the business. These obstacles can be in the form of business processes, or system limitations, or both. Furthermore, a considerably big obstacle can be potentially detrimental to the spirit and purpose of a project. Obstacle Analysis is a tool that provides a systematic approach to overcoming those obstacles. Tackling road-blocks carefully and comprehensively can aid in achieving the mission of a project and in turn, satisfy customers.
I recently came across a research paper that revolved around the topic of Obstacle Analysis. The tool was applied to identify contingency requirements governing the mechanism of an unpiloted lightweight, experimental aircraft. Unsurprisingly soon after reading the paper I was under the impression that Obstacle Analysis was used mainly for increasingly autonomous, goal-oriented applications where safety was paramount. By “safety” I mean if one is going to build a flying, unmanned aircraft, you also want to build in autonomous safety features that would otherwise be handled by humans to prevent the vehicle from flying toward a collision. Besides, I don’t think there many on this portal, yet, who engineer requirements for real-time and embedded systems or tangible, moving objects.
Fortunately, I also quickly realized that Obstacle Analysis could be useful in conventional, (object-oriented) software requirements engineering aimed for desktop applications that we all work with daily. Hence, I feel confident in writing this entry expecting that it will be of use to other fellow analysts. I read the paper, read it once more, highlighted the main points, and promptly applied the tool to one of my smaller and uncomplicated projects to start with. You might notice that it's main usage comes in the requirements analysis phase.
So without any further ado, what exactly is Obstacle Analysis? Many of us may have already used it unwittingly in some informal way or another. In my own words, and to not plagiarize the paper, Obstacle Analysis is a systematic approach to identifying, analyzing and neutralizing obstacles that hinder the accomplishment of a necessary goal.
The following is an explanation of the steps involved:
-
IDENTIFY THE SUB-GOAL (the paper calls this Goal, but for semantics purposes, I prefer to use of the term "Sub-goal")
What is the goal that for which you as an analyst are engineering requirements? This, most likely, is a sub-goal that when executed correctly will lead to the achievement of a bigger goal. What is a goal anyway? A goal is one or a set of results expected to materialize on successful execution of one or more tasks.
- IDENTIFY THE AGENTS
Agents are participants who will implement or aid in the implementation of the sub-goals. This could software components, hardware objects, and humans. This is an important element of the analysis, in that identifying the agent itself might resolve the obstacle.
- IDENTIFY THE OBSTACLES
If a goal is a behavior of the system that is desired, an obstacle is an element that keeps that goal from being accomplished. What is it that prevents the goal from being achieved? This is step is particularly cyclical in rational thought – a decent understanding of the application being built will aid in uncovering its weak points that might need attention. Tackling the weak points and making the system more robust, in turn, only deepens one’s understanding further…and the cycle continues.
- IDENTIFY ALTERNATIVES TO THE OBSTACLE
It is here that we offer multiple solutions to eradicate the obstacle. It is imperative that we list as many solutions as possible since, the next step depends on this one. There are multiple ways to identify alternatives:
- De-scope the goal itself. At first, this may sound brash. But on closer thought, we realize that it’s not uncommon to simply wipe the goal off the slate and shrink the scope. Resolving the obstacle may pose a budgetary or scheduling challenge which a team might not be willing to undertake. Hence, getting rid of the goal might actually be a viable option.
- Assign a Different Agent so that someone or some other component of the system helps in accomplishing the goal without giving rise to the obstacle.
- Add a New Goal to the existing one if it prevents the obstacle from arising again.
- Modify the Goal in that the obstacle will not arise in accomplishing the new goal.
- Change the Domain in a way that the goal simply does not occur and keeps the goal in tact.
- SELECT AN ALTERNATIVE
Choose the option that will best tackle the obstacle and thus, aid in achieving the goal.
In conclusion, I believe this is a comprehensive tool to tackle obstacles that we as analysts face nearly everyday. One of the obstacles that I tackled for my project using this tool resulted in nullifying the malicious effects of the obstacle, remaining within the scope, accurately meeting the main goals of the business, and a cleaner, less-complicated code from development.
For your curiosity, the paper can be accessed from here. Thanks in advance for your thoughts, comments and corrections, if you see any, for others to gain from. I also thank Lutz, Patterson-Hine, Nelson, Frost, Tal, and Harris (2006) for their research.