Habits of Effective Business Analysts, Part 1
Software managers sometimes assume that every talented programmer is also proficient at interviewing customers and writing requirements, without any training, resources, or coaching. This isn’t a reasonable assumption. Like testing, estimation, and project management, requirements engineering has its own skill set and body of knowledge. Unfortunately, computer science curricula often emphasize programming-related knowledge over other software life cycle activities. Self-study and on-the-job learning likely neglect softer skills such as those needed in requirements engineering, unless you’re specifically studying in pursuit of a professional business analyst certification.
The role of the business analyst is critical to a software project. Many organizations expect developers or project managers to handle this vital function on their own. And even if a project team does include dedicated analysts, their skills might not be up to the task. Too often, I meet BAs who have had little training in how to perform their job and who have few books or tools available to help them. BAs who come from a user background may lack technical understanding, while those who migrated from the IT world might not understand the user’s business domain and terminology. A BA provides a specialized capability that can make the difference between a project that succeeds and one that struggles. In this two-part series, I describe several characteristics and practices of successful business analysts.
Bridge the Communication Gap
The BA is a communication middleman, bridging the gap between vague customer notions and clear specifications. The BA must first understand the user’s real needs and then define a set of functional requirements and quality goals that allow developers to build and testers to verify the system. To be an effective BA, become proficient in all forms of communication, including listening, speaking, and writing. As you interact with executive project sponsors, marketing, and user representatives, understand their objectives for the proposed system and their concerns about the business and the application. Use the vocabulary of the application domain, rather than forcing your customers to understand computer jargon.
Take the time to learn about your customer collaborators and understand how they prefer to communicate. Watch for assumptions that underlie either the users’ expression of needs or your own thinking. Avoid imposing your personal filter of understanding on what you hear the customers say. Keep one of my axioms of software development—and life, for that matter—in mind: The customer is not always right, but the customer always has a point. You must understand and respect those points, so they can be appropriately addressed in the product.
Try to understand the users’ implicit expectations about the system’s characteristics, such as performance, usability, efficiency, and reliability. Companies sometimes make products that fully meet the functional needs, only to discover that users hate it because it doesn’t work like they expect. When users declare that the system must be “user-friendly,” they have a mental image of what that means to them. As a BA, your job is to understand the intent behind each such expectation, so you can translate something vague and subjective like “user-friendly” into goals the developer can satisfy. One technique is to ask users what would constitute unacceptable performance, usability, or reliability.
Requirements development should lead to an understanding, shared by the various stakeholders, of the system that will address the customer’s problem. The BA is responsible for writing requirements that clearly express this shared understanding. Writing documents that customer representatives can understand and verify, while unambiguously conveying precise functional and nonfunctional requirements to the developers, is a tightrope walk. A single requirements specification might not meet both needs.
In requirements discussions, users often bring up fragments of functionality (“I need to be able to sort the list alphabetically”), quality characteristics (“this system has to be a lot more reliable than the old one”), or solution ideas (“then I select the state where I want to send the package from a drop-down list”). Don’t discard these bits of information, because they convey part of what the user has in mind. However, I prefer to focus the early requirements discussions on the tasks users need to accomplish with the system: their use cases or (as is popular in agile development) user stories. This usage-centric approach helps you understand why the functionality or characteristics customers describe are important. An understanding of user goals leads to the necessary functional requirements, which then leads to detailed user interface design.
Because use cases describe a user view of the system, users should understand them. However, use cases alone rarely convey enough detail to developers. One important BA task is to derive from each use case the specific functional requirements that, when implemented, will let users perform the tasks described in the use case. This means you must be able to communicate effectively in both directions: with users (the task view) and with developers (the technical view). To make sure you’ve been understood, have user representatives, developers, and testers review your documents.
Color Inside the Lines
Begin your exploration of a new system’s requirements by defining the ultimate vision of what the product or application will be and do. Talk with the funding sponsor, marketing manager, or product visionary early on to define the project’s business objectives. This information helps you answer this critical question whenever someone suggests a new product feature: “Is this feature in scope?”
Teams rarely implement the ultimate solution in one pass. Instead, define the scope of the first release or iteration as a subset of the final product. Describe a growth path from the initial release toward realizing the ultimate vision through a series of staged releases or iterations. Also, document any known limitations or functionality that you don’t intend to build but which some stakeholder might expect to find. Expectation management is an important strategy.
Ask Revealing Questions
When working as a BA, you’ll need to actively facilitate discussions with users to pull out information that might otherwise go unstated. Ask questions to identify possible alternative ways a user might want to perform some task and to surface related tasks that the user representatives didn’t mention initially. If a user says “the default should be …”, he’s probably describing the normal flow for a use case. The phrase “but I should also have the option to …” suggests an alternative flow for that use case.
Users naturally focus on the system’s normal, expected behaviors. However, developers write much code to handle exceptions, so you should also search for possible error conditions that could arise and decide how the system should respond. If you don’t describe exceptions during requirements elicitation, either the developers will make their best guess at how to handle them, or the system will simply fail when a user hits the error condition. It’s a safe bet that system crashes aren’t in the user’s plans.
A BA isn’t just a scribe, recording whatever customers say they want. A creative BA can suggest ideas and alternatives during elicitation. When users truly can’t express what they need, watch them work and suggest ways to automate appropriate portions of the job. BAs can often think out of the box that limits the creativity of people who are too close to the problem being solved. Be careful to avoid gold-plating, adding extra functionality that just seems cool or somehow desirable. An effective BA must be able to think at multiple levels of abstraction. You should be able to generalize from a specific need expressed by one user to define a set of related needs that will satisfy many members of that individual’s user class.
The second article in this series will look at some of the other habits that help skilled BAs contribute to building great systems, including prioritizing requirements and creating a collaborative environment.
Don’t forget to leave your comments below.