Business analysis is a specialized skill. Following are some practices and behaviors that help a business analyst (BA) contribute to project success.
Software managers sometimes assume that every skilled developer can also interview customers and write requirements, without any training, resources, or coaching. This is not a reasonable assumption.
Regardless of who on the team does the work, business analysis has its own skill set and body of knowledge. Analysts who come from a user background may lack deep technical understanding. Those who migrated into business analysis from the development side might not understand the user’s business domain. Business analysts also need the right personality and soft skills for this people-centric job. It’s not for everyone.
A business analyst provides a specialized capability that can make the difference between a project that succeeds and one that struggles. Every software organization should develop an experienced cadre of trained and knowledgeable BAs. It is important to understand their key skills and activities.
Create a Collaborative Environment
Software projects sometimes experience strained relationships among customers, developers, managers, and marketing. The parties might not trust each other’s motivations or appreciate each other’s needs and constraints. A win/win outcome means customers love the product, the organization achieves its business objectives, and team members are proud of the work they did.
A business analyst contributes the most to software success when she helps to forge a constructive and collaborative relationship with customers. Identify key individuals who could serve as the voice of the customer for each of your system’s user classes, often called “product champions.” Also, identify the decision makers for resolving requirement trade-offs and priority conflicts and the decision-making processes they will use – stakeholders. Do this before the project team confronts its first major decision.
Customers and their managers sometimes are reluctant to spend time on requirements discussions. Remind them of problems on previous projects where the root cause was inadequate user involvement. Nearly every organization has horror stories of new systems that failed to satisfy user needs, didn’t meet unstated usability or performance expectations, or duplicated the shortcomings of earlier systems. Refreshing their memories might help motivate stakeholders and team members to participate more fully in the next project.
No organization can afford to keep rebuilding or discarding systems that fail because customers and BAs didn’t collaborate to understand the user needs. If customers won’t commit to reaching a shared understanding of their requirements, the outcome might well be lose/lose.
Bridge the Communication Gap
The BA is a communications middleman, bridging the gulf between vague customer notions and a clear developer understanding of requirements. To be an effective analyst, become proficient in all forms of communication, including listening, speaking, writing, and modeling. Learn the vocabulary of the application domain, rather than forcing customers to understand computer jargon. Include a glossary as part of each project’s requirements documentation to make sure everyone has the same understanding of important terms.
Don’t be afraid to ask the customers for clarification during requirements discussions. Explain a lack of familiarity with the customer’s business to help clarify requirements. This approach sometimes makes customers more willing to help since the BA is demonstrating a valiant effort to understand their problems and needs.
Everyone thinks within the frame of one’s own experience and knowledge. Take the time to learn about the customers and understand their communication preferences. Watch for unstated assumptions that underlie either the users’ input or validate understanding. Challenge those assumptions to determine if they are still valid and to understand their implications.
The goal of requirements development is to reach a common understanding among the stakeholders of the solution that will address the customer’s problem. The BA assembles a set of requirements that clearly expresses this shared understanding. This means a BA must be able to communicate both with users (task view) and with developers (technical view). Often, no single written requirements document can accomplish both objectives. It is important to create requirements representations that contain the right level of detail to communicate effectively with each audience. Visual models nicely supplement textual descriptions to this end.
Focus requirements discussions on the tasks users wish to perform with the system—their use cases—not on the features they want to include. If you understand user tasks and goals, you can derive the necessary functional requirements that will let users perform those tasks. A usage-centric approach like this is more accurate and efficient than a feature-driven requirement strategy. It also helps avoid the problem of implementing functionality that no one ever uses.
Beyond functionality, explore the users’ expectations— often unstated—about the system’s quality attributes. Performance, usability, security, and reliability are some common quality categories. When users say the system must be “user-friendly,” understand what that means to them. One way to approach this is to ask users what would constitute unacceptable performance, usability, security, or reliability. Then, translate the vague “user-friendly” phrase into some specific requirements that developers can satisfy.
Conclusion
All business analysts should develop the fundamental habits of effective BAs. These fundamental habits will help improve the development of accurate, complete, and appropriate business requirements.
