What are the most common elicitation challenges? This is one of the most discussed topics from my business analysis training sessions. A business analyst extracts information in various forms, from various sources, and transforms those findings into requirements and design artifacts. Let’s take a look at some of the common challenges during the elicitation process and how to address them.

Integration requirements are critical for any Project’s success when Business Processes flow across multiple systems. As a Business Analyst it’s our responsibility to understand the end-to-end Business and Systems Process flow and document the hand off as part of the requirements gatherings process. A systematic approach to gather the requirements for integration between systems will ensure that there is a smooth interaction between the systems and hence the Business Process flow. The below Framework on Integration Requirements Analysis provides a systematic approach to document requirements for an Integration Project

In all my years as a Consultant Business Analyst, having reached a level of proficiency, I have realised that being a business analyst is seldom about the hard skills. In fact, it is more about the soft skills and BAs who operate at that level are more impressive and effective in their job. Hard skills like documentation, requirements elicitation, process maps etc. are easily taught and acquired but the soft skills are developed with experience and the right attitude towards this role. Over time I feel the perception of the value of BAs has diluted and I blame those who have been superficial about performing this role. Those who think their role is just about the tangible artefacts like the business requirements document, process maps, business case, etc. Those who think they are here to deliver a project and nothing else. Those who think the BA’s job is to take orders and execute. But the fact is that the role of a BA is a lot more subtle than one thinks. There is a much broader aspect to this role, which is often forgotten, and we get caught in deliverables and artefacts.

Let’s look at some aspects of this role, which are common knowledge and broaden our perspective of that. When the mindset of the Business Analyst changes to the bigger picture and to the more delicate facets to this role, you perform much better as a business analyst and are a more reliable and thus a desirable professional for companies.

My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in the Scrum framework).

Ever wondered how to write foolproof acceptance criteria? Or even wondered what a business analyst can do to ensure that requirements are testable? Acceptance criteria define the minimum requirements the solution must meet. A business analyst plays a key role in defining the tests around it. The acceptance tests can be at various levels of requirements detail. Starting from high-level requirements to detailed requirements. Let’s take a look at common challenges involved in this part of the world, along with a few ideas to overcome those.