We bought a house and wanted to pave the backyard. The contractor came in to understand my requirements. We agreed on the cost and as I really wanted to make sure that he has understood my requirements, I asked him to send me a recap of the conversation and also send me a detailed proposal with the schedule. The work went on as scheduled and completed on time. What I did not specify was the implicit requirements. A few days later it rained and the backyard started becoming a swimming pool. That is when I realized that the contractor did not make any drainage arrangements. When I called him, he said, “Sir, the requirement for a drainage wasn’t specified in your requirements.”
Business Analysis requires a 3 step approach
This is an enterprise-level requirement understanding where the analyst must understand the goals, visions, objectives and strategies of a business enterprise. What is the USP of this business and the big question of WHY are we doing what we are doing must be answered in this phase. Most of the time the decision analysis is already done and the job of the analyst is to verify the analysis sometimes even if it means asking difficult questions and helping rule out the feasibility.
This is where an analyst will analyze business rules, define entity mappings, build use case scenarios and process data models. Closing of the loop is very important at this stage. Any use case scenario left open may create a gaping hole in the entire analysis process. It would be a good idea here to use a tool like axure.
Implicit requirements are a part of this approach and having correct SOP’s (Standard Operating Procedures) is very important to handle this area of analysis. Areas like security analysis, architectural analysis are not always specified, and like in my story, the drainage facilitation is missed.
To sum up, the duties of a business analyst are nontrivial. The variety of tools and techniques used are substantial and the organizational support required to be effective in that role is significant.