This content is part of the Essential Guide: Gathering and managing software project requirements
Manage Learn to apply best practices and optimize your operations.

Engage developers in the requirements definition process

Learn when and how a business analyst should engage developers during the process of defining requirements.

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.


Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I think Henry Ford said something like, "If I asked the market what they wanted they would have said a faster horse." Some of every leading product's value comes straight from the development team. The best product teams I've seen, coached and managed include a business and engineering pair at the inception. This insured a cross function content and context surveying of the market and has delivered the best proposals to the product committee.
I think this confuses defining the problem with defining the solution. You need to examine the different aspects of the problem to gain a clear understanding of what, exactly, it is. In that case, everyone on the project team can offer a unique perspective that may provide something everyone else missed.
Thanks for your comments. I think we’re all (hopefully not too violently ) agreeing. If it had seemed not, fault my post for not clearly stating my points. Effective developers indeed first do understand _what_ is needed (what I call REAL business requirements) for the business to get value and only then address defining and implementing a product/system/software way _how_ to satisfy the _whats_. However, because most developers jump right to the product _how_ without adequately understanding the business deliverable _whats_, assuming whatever they decide to build must be what the business needs and likely dominating the discussion, I think generally it’s a good idea to keep developers out of the requirements discovery. Analysts should know better but unfortunately too often fall into the same product-focused trap, which is actually a form of design rather than defining requirements.