Software managers sometimes assume 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 a cadre of trained and experienced BAs. Let’s see some of 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. I call these people “product champions.” Also, identify who your decision makers will be for resolving requirement trade-offs and priority conflicts and the decision-making processes they will use. Do this before the project team confronts its first major decision.
Customers and their managers sometimes are reluctant to spend time on requirements discussions. You might remind them of problems on previous projects that arose from 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 motivate your customers 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; don’t force your 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 your customer counterparts for clarification during requirements discussions. You might explain that you’re not completely familiar with the customer’s business and that’s why you don’t fully grasp what they’re describing. This approach sometimes makes customers more willing to help because they can see you’re making a real effort to understand their problems and needs.
We all think within the frame of our own experience and knowledge. Take the time to learn about your customer collaborators and understand how they prefer to communicate. Watch for unstated assumptions that underlie either the users’ input or your own thinking. Challenge those assumptions to determine if they’re still valid and to understand their implications.
The goal of requirements development is for stakeholders to reach a common understanding 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 you 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. You need 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.
I recommend focusing 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 requirement approach like this is more accurate and efficient than a feature-driven 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. One way to approach this is to ask users what would constitute unacceptable performance, usability, security, or reliability. When users say the system must be “user-friendly,” you need to understand what that means to them. Then you can translate the vague “user-friendly” into some specific requirements developers can satisfy.
Color Inside the Lines
Many projects suffer from scope creep, growing ever larger, sometimes out of control. But many of those projects never clearly defined their intended scope, the boundary between what’s in and what’s out. It’s hard to even know if you’re experiencing scope creep if stakeholders never agreed upon — and documented — the scope in the first place.
Begin your requirements exploration with the project’s business requirements. Why is the organization undertaking this project? What benefits do they hope it will provide to them and their customers? Can the managers state a concise vision of what the overall product will be and do?
Without understanding the business objectives, you can’t answer the critical question whenever someone proposes a feature: “Is this in scope?” A structured vision and scope document is a good place to store this guiding project information.
Most teams follow an iterative process for software development, so define the scope of the first release or iteration as a subset of the final product. Describe a growth path from this initial release toward the ultimate product vision through a series of iterations. Document any known limitations, such as functionality that you don’t intend to build but which some stakeholder might expect. Such expectation management can help prevent unpleasant surprises at the project’s end.
Ask Revealing Questions
The worst question you can ask during a requirements elicitation discussion is “What do you want?” The second-worst question is “What are your requirements?” Nobody knows how to answer questions like that. The BA needs to actively facilitate discussions with users to pull out the pertinent knowledge.
Users naturally focus on the system’s normal, expected behaviors for common tasks. Also ask questions to explore possible alternative ways a user might want to perform some task and related tasks. Questions that begin “Would anyone ever need to…” can reveal requirements nobody thought to mention yet.
A user who says “The default should be …” is probably describing the normal flow or most common scenario for a use case. A phrase like “The user should also have the option to …” suggests an alternative flow or scenario. These alternatives might have lower priority, so you can target them for later implementation. Beginning prioritization very early helps the team focus on delivering the minimum necessary solution as soon as possible.
Also ask questions about possible error conditions that could arise and how the system should respond. If a user says the system should be “robust,” he means it needs to handle erroneous input and unexpected situations sensibly. If you don’t explore exceptions as part of requirements discovery, you can only hope the developers will think of them and make reasonable guesses as to how the system should handle them.
The BA is not simply a scribe. Put on your creativity cap and suggest ideas and alternatives to users during elicitation. Analysts can often think out of the box that limits the creativity of people who are too close to the problem. Watch out for gold-plating, though. This is the temptation to add extra functionality that just seems cool or somehow necessary. If you don’t know how the functionality will be used or why it’s there, you probably don’t need it.
An effective analyst can think at multiple levels of abstraction. Sometimes you might generalize a specific user’s request to a set of related requirements that will satisfy a broader range of needs. You also need to judge when to drill down into specifics from a vaguely stated need. The more guidance you can provide the developers about what to build, the less guessing they’ll have to do, and the less time they’ll need to spend chasing down answers.
Prioritize Early and Often
All stakeholders think their requirements should have the top priority, but you can’t build everything at once. Analysts must work with customers to define feature priorities, so the team can implement the most critical functionality first. One BA responsibility is to facilitate negotiation among stakeholders to make sensible priority decisions. The elicitation group should decide early on how to classify requirement priorities to make sure things get built in the right sequence.
Early in requirements development, identify the various user classes — and other, non-user stakeholders — that might contribute requirements. Determine which user classes are “favored.” Meeting their needs is most closely aligned with achieving the project’s business objectives. The favored user classes take precedence if you encounter conflicts in the requirements or the priorities coming from different groups.
One effective strategy is to begin by working with your product champions to identify their major use cases or user stories. Perform a first-cut prioritization on those user requirements to determine which ones to explore in detail first. The top priority requirements are those that are both the most important (capabilities the users really need) and the most urgent (capabilities the users need right away).
One truism of software development is that requirements will change during development. View your backlog of requirements as dynamic, ebbing and flowing as reality happens. Reprioritize requirements as changes come in to make sure the team delivers the maximum customer value as quickly as possible.
Hone Your Skills
A competent BA must combine communication, facilitation, and interpersonal skills with some technical and business domain knowledge. These capabilities are particularly important:
- Listening skills, to understand what people say and to sense what they might not be saying
- Interviewing techniques, to talk with individuals and groups about their needs
- Facilitation techniques, to lead elicitation workshops
- Writing skills, to communicate information effectively to customers, managers, and technical people
- Modeling skills, to represent knowledge in visual forms that augment natural language text
- Organizational skills, to structure and manage the vast array of information collected during requirements discussions
- Interpersonal skills, to negotiate priorities and resolve conflicts among stakeholders
- Domain knowledge, to have credibility with user representatives and converse effectively with them
I suggest you do a self-evaluation of your skills and pick out one or two areas you wish to strengthen. The list on pages 65–67 of Software Requirements, 3rd Edition, is a great place to start. Then, commit to learning more in each of those areas and actively try to practice those new skills on your next project or iteration.
A more structured way to enhance your skills is to pursue a professional certification in business analysis. There are many to choose from, including the following.
- The International Institute of Business Analysis (IIBA) has several levels of certification, including Entry Certificate in Business Analysis (ECBA), Certification of Capability in Business Analysis (CCBA), and Certified Business Analysis Professional (CBAP).
- The Project Management Institute (PMI) has the Professional in Business Analysis (PMI-PBA) certification.
- The International Requirements Engineering Board (IREB) offers the Certified Professional for Requirements Engineering (CPRE) credential.
- A series of business analysis certifications are available from the British Computer Society (BCS) at the beginner, practitioner, professional, consultant, and expert levels.
Holding one or more certifications demonstrates a serious level of commitment to accumulating the knowledge and experience of a true business analysis professional.
Pulling It All Together
Requirements aren’t just lying around waiting for someone to collect them. At best, requirements exist as fragments in the minds of users, visionaries, and developers. The BA’s job is to gently extract them, massage them into a usable form, and communicate them to the project stakeholders for action.
Few project roles are more challenging than that of business analyst. Few are more critical.
If you’re interested in requirements and business analysis, Process Impact provides numerous useful publications and other resources.