Executives are key stakeholders and thus key resources for writing business requirements. But being a source for...
business requirements is a lot different than writing them. Note, though, that the BABOK guide v2 online (IMHO somewhat misguided) enterprise analysis knowledge area describes the executive's role as dictating objectives and high-level requirements of the product to be produced in the project being initiated. BABOK often is interpreted as meaning that the business analyst (BA), if involved, merely captures whatever the executive says.
Unfortunately, many executives assume their level alone suffices to define a project and its business requirements. Yet, simply having an executive title often fails to provide the business analysis discovery skills and awareness needed to get the business requirements right. Such shortcomings frequently cause projects to fail and are exacerbated by the executive's inability to recognize the shortcomings, let alone acknowledge them and respond accordingly.
That's all the more reason to involve executives appropriately when writing business requirements, but this usually is easier said than done. To me, the starting point must be the BA's attitude. To truly add value, the BA must do more than take dictation. Rather, the BA must discover business requirements through an integrated combination of active data elicitation and analysis. The focus must be on the business, not on the product the project is to produce.
T o achieve necessary executive rapport and understanding of the business situation, the BA must take the initiative to gain sufficient relevant business knowledge before eliciting and analyzing data. Such prior contextual knowledge will aid the understanding needed to discover the real business requirements, not to presume them.
An added benefit of taking such a business perspective is that it tends to guide more productive executive involvement. That is, it leads to questions concerning business problems and opportunities, along with likely key causes and potential business deliverables that will solve the problems when satisfied.
Instead of tying up executives in writing business requirements, the BA and more directly involved stakeholders should do the bulk of the writing and then present it to executives for review. Executive review can be individual or as part of a group, either just executives or a mix of stakeholders. Either way is usually a more effective and efficient use of the executive's time.
A little-known additional non-requirements way to involve executives in defining requirements is proactive testing master risk analysis. This mixed stakeholder group method applies special techniques to identify often numerous ordinarily overlooked large showstopper-sized risks in the high-level design. Most large risks reflect design errors and omissions, in turn mainly stemming from wrong and missed business requirements. Executives and other key stakeholders generally find such large risk discovery very rewarding. Once they've participated, they and their colleagues want to be sure to be included thereafter.
Common sense tips for writing requirements
Elicitation techniques for discovering software requirements
Dig Deeper on Software Requirements Management
Related Q&A from Robin F. Goldsmith
Using a WBS can help make a big task like requirements easier. Expert Robin Goldsmith explains how developers and testers can make the most of this ... Continue Reading
Why don't users seem to appreciate typical software QA testing status reports? Continue Reading
What is the value of online discussion forums? This expert sees the good and the bad in online forums. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.