BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
When and how should a business analyst engage developers during the requirements definition process?
Engaging developers in the requirements definition process seems perfectly natural. After all, even if they are not explicitly involved in the process, developers do define all sorts of requirements as they build software. They make countless decisions (some conscious and some not) about what code is written and how. But generally, such decisions could be improved upon by making them more formal. Business analysts can provide the formal framework in which developers develop technical requirements.
Two common models of gathering requirements persist despite being counterproductive. The first and older model is built around the myth that software development is only about technical programming issues. Development is seen as a black art that can only be done by computer scientists. Thus, the entire development team is comprised of code-minded programmers who may or may not fully understand actual business requirements. This model is beginning to lift as the roles of business analysts, Agile project managers and testers grow more central to the development team.
A second mistaken model remains far more entrenched, but is no less dangerous. Some say requirements are the features of the software to be created. Indeed, developers do have a central role in defining how a product will work; but that actually is a form of high-level design, not requirements. Developers undoubtedly know much more than business folks about data structures, interfaces and other critical elements that must be taken into account for the implemented solution to work properly. However, these elements need to be built on top of a solid base of business-related requirements.
To supplement what developers know, business analysts provide a better understanding of what the business actually requires. Developers may have relevant and valuable business insights. However, that insight is not required for their role and is not their core competency. Work with business analysts first to attain a solid understanding of the business requirements. Then engage with developers to define the software requirements that meet the business' needs.