When and how should a business analyst engage developers during the requirements definition process?
If I were to quickly list the activities that make up requirements definition, I would focus on elicitation, clarification, documentation, communication and prioritization as the key areas. Other than skipping any of these steps, the biggest mistake is to think of them as sequential activities -- they are tightly coupled, and there isn't a prescribed order in which to do them.
Many business analysts will elicit, clarify and document (and sometimes prioritize) requirements without engaging developers -- then hand over their document and call that transaction "communication." At this point, the developers would ask questions, make suggestions, assess the feasibility and estimate the cost of implementing a solution that meets the requirements. This process can be significantly improved by making sure that communication with development is infused throughout the other activity areas.
As a business analyst, you identify the problem that needs to be solved and establish the criteria that define what it means to truly solve it.
During requirements elicitation and clarification, you ask stakeholders what they need, and they tell you. They usually focus on problem manifestations and not the underlying problems. As a business analyst, you identify the problem that needs to be solved and establish the criteria that define what it means to truly solve it. If you communicate with your developers at this point, you can quickly identify acceptance criteria that did not occur to you and validate with your stakeholders that these criteria are important. The net result -- the implementation -- will be more likely to satisfy the stakeholders' needs because they are better defined.
As you clarify and document the acceptance criteria, you also have an opportunity to assess feasibility and cost. By discussing this in detail with your developers, you will identify situations where slight relaxations of an acceptance criteria (perhaps reducing response time from 100 milliseconds to 200 milliseconds) result in miniscule reduction of value but dramatic reduction in cost or time to implement. This frees up resources to solve additional problems -- making the product as a whole a better one.
As you communicate and document, you can capture the cost estimates from developers, allowing you to prioritize effectively. It is suboptimal to simply prioritize based on importance; you should prioritize based on the combination of value and cost -- getting the most bang for the buck. Prioritization is not just providing an ordered list of tasks to developers; it also tells you where to spend the most of your effort. As you combine the insights about both cost and value during your elicitation, you get guidance about where to invest more (or less) of your time. You can deliver your documentation such that the most important requirements are the best developed.
This emergent understanding of the costs, priorities and feasibility of clarified requirements evolves while working on a body of requirements. As a bonus, you can leverage your elicitation activities to provide feedback and manage the expectations of your stakeholders. It is the continuous concurrent conversations that enable you to make the process and the requirements better simultaneously.
This was first published in December 2012