The business analyst is the individual who has the primary responsibility to elicit, analyze, document, and validate the needs of the project stakeholders. The analyst serves as the principal interpreter through which requirements flow between the customer community and the software development team, as shown in Figure 4-1. Many other communication pathways also are used, so the analyst isn’t solely responsible for information exchange on the project. The BA plays a central role in collecting and disseminating product information, whereas the project manager takes the lead in communicating project information.

Figure 4-1. The business analyst bridges communication between customer and development stakeholders.

Business analyst is a project role, not necessarily a job title. Synonyms for business analyst include requirements analyst, systems analyst, requirements engineer, requirements manager, application analyst, business systems analyst, IT business analyst, and simply analyst. These job titles are used inconsistently from organization to organization. One or more dedicated specialists could perform the role on a given project or it could be assigned to team members who also perform other project functions. These team members include project manager, product manager, product owner, subject matter expert (SME), developer, and sometimes even user.

It’s important to note that when a person who has another project role also serves as the business analyst, he is doing two distinct jobs. Consider a project manager who is also the BA on a project. A project manager needs to create and manage plans, including schedules and resource needs, based on work that BAs define. The project manager must help manage scope and deal with schedule changes as scope evolves. He might perform the project management role one minute, then change hats to execute the analyst practices the next. But these are distinct roles, requiring somewhat different skill sets.

In organizations that develop consumer products, the analyst role is often the product manager’s or marketing staff’s responsibility. Essentially, the product manager acts as a BA, often with additional emphasis on understanding the market landscape and anticipating external users’ needs. If the project has both a product manager and a BA, typically the product manager focuses on the external market and user demands, and the BA converts those into functional requirements.

Agile projects need business analysis skills, too. There will likely be a project role such as a product owner who performs some of the traditional BA tasks. Some teams find it helpful to have someone in an analyst role as well ([ref045]). The BA can help represent the users and understand their needs, while performing the additional BA activities described later in the chapter. Regardless of the job title, the person performing the analyst tasks must have the skills, knowledge, and personality to perform the role well.

A talented analyst can make the difference between a project that succeeds and one that struggles. One company discovered that they could inspect requirements specifications written by experienced analysts twice as fast as those written by novices because they contained fewer defects. In the popular Cocomo II model for project estimation, analyst experience and capability have a great influence on a project’s effort and cost ([ref022]). Using highly experienced analysts can reduce the project’s overall effort by one-third compared to similar projects with inexperienced analysts.

The analyst must first understand the business objectives for the project and then define user, functional, and quality requirements that allow teams to estimate and plan the project and to design, build, and verify the product. The BA is also a leader and a communicator, turning vague customer notions into clear specifications that guide the software team’s work. This section describes some of the typical activities that you might perform while wearing an analyst’s hat.

Define business requirements Your work as a BA begins when you help the business or funding sponsor, product manager, or marketing manager define the project’s business requirements. You might suggest a template for a vision and scope document (see Chapter 5) and work with those who hold the vision to help them express it clearly.

Plan the requirements approach The analyst should develop plans to elicit, analyze, document, validate, and manage requirements throughout the project. Work closely with the project manager to ensure these plans align with the overall project plans and will help achieve the project goals.

Identify project stakeholders and user classes Work with the business sponsors to select appropriate representatives for each user class (see Chapter 6), enlist their participation, and negotiate their responsibilities. Explain what you would like from your customer collaborators and agree on an appropriate level of engagement from each one.

Elicit requirements A proactive analyst helps users articulate the system capabilities they need to meet their business objectives by using a variety of information-gathering techniques. See Chapter 7 and Chapter 8 for further discussion.

Analyze requirements Look for derived requirements that are a logical consequence of what the customers requested and for implicit requirements that the customers seem to expect without saying so. Use requirements models to recognize patterns, identify gaps in the requirements, reveal conflicting requirements, and confirm that all requirements specified are within scope. Work with stakeholders to determine the necessary level of detail for specifying user and functional requirements.

Document requirements The analyst is responsible for documenting requirements in a well-organized and well-written manner that clearly describes the solution that will address the customer’s problem. Using standard templates accelerates requirements development by reminding the BA of topics to discuss with the user representatives.

Communicate requirements You must communicate the requirements effectively and efficiently to all parties. The BA should determine when it is helpful to represent requirements by using methods other than text, including various types of visual analysis models (discussed in Chapter 5, Chapter 12, and Chapter 13), tables, mathematical equations, and prototypes (discussed in Chapter 15). Communication is not simply a matter of putting requirements on paper and tossing them over a wall. It involves ongoing collaboration with the team to ensure that they understand the information you are communicating.

Lead requirements validation The BA must ensure that requirement statements possess the desired characteristics that are discussed in Chapter 11 and that a solution based on the requirements will satisfy stakeholder needs. Analysts are the central participants in reviews of requirements. You should also review designs and tests that were derived from the requirements to ensure that the requirements were interpreted correctly. If you are creating acceptance tests in place of detailed requirements on an agile project, those should also be reviewed.

Facilitate requirements prioritization The analyst brokers collaboration and negotiation among the various stakeholders and the developers to ensure that they make sensible priority decisions in alignment with achieving business objectives.

Manage requirements A business analyst is involved throughout the entire software development life cycle, so she should help create, review, and execute the project’s requirements management plan. After establishing a requirements baseline for a given product release or development iteration, the BA’s focus shifts to tracking the status of those requirements, verifying their satisfaction in the product, and managing changes to the requirements baseline. With input from various colleagues, the analyst collects traceability information that connects individual requirements to other system elements.

It isn’t reasonable to expect people to serve as analysts without sufficient training, guidance, and experience. They won’t do a good job, and they’ll find the experience frustrating. The job includes many “soft skills” that are more people-oriented than technical. Analysts need to know how to use a variety of elicitation techniques and how to represent information in forms other than natural-language text. An effective BA combines strong communication, facilitation, and interpersonal skills with technical and business domain knowledge and the right personality for the job. Patience and a genuine desire to work with people are key success factors. The skills described in this section are particularly important. [ref256] provides a comprehensive table of skills that are appropriate for junior-level, mid-level, and senior-level requirements analysts.

Listening skills To become proficient at two-way communication, learn how to listen effectively. Active listening involves eliminating distractions, maintaining an attentive posture and eye contact, and restating key points to confirm your understanding. You need to grasp what people are saying and also to read between the lines to detect what they might be hesitant to say. Learn how your collaborators prefer to communicate, and avoid imposing your personal filter of understanding on what you hear from the customers. Watch for unstated assumptions that underlie either what you hear from others or your own interpretation.

Interviewing and questioning skills Most requirements input comes through discussions, so the BA must be able to interact with diverse individuals and groups about their needs. It can be intimidating to work with senior managers and with highly opinionated or aggressive individuals. You need to ask the right questions to surface essential requirements information. For example, users naturally focus on the system’s normal, expected behaviors. However, much code gets written to handle exceptions. Therefore, you must also probe to identify error conditions and determine how the system should respond. With experience, you’ll become skilled in the art of asking questions that reveal and clarify uncertainties, disagreements, assumptions, and unstated expectations ([ref082]).

Thinking on your feet Business analysts always need to be aware of the existing information and to process new information against it. They need to spot contradictions, uncertainty, vagueness, and assumptions so they can discuss them in the moment if appropriate. You can try to script the perfect set of interview questions; however, you’ll always need to ask something you could not have foreseen. You need to draft good questions, listen clearly to the responses, and quickly come up with the next smart thing to say or ask. Sometimes you won’t be asking a question but rather giving an appropriate example in context to help your stakeholder formulate the next answer.

Analytical skills An effective business analyst can think at both high and low levels of abstraction and knows when to move from one to another. Sometimes, you must drill down from high-level information into details. In other situations, you’ll need to generalize from a specific need that one user described to a set of requirements that will satisfy multiple stakeholders. BAs need to understand complex information coming from many sources and to solve hard problems related to that information. They need to critically evaluate the information to reconcile conflicts, separate user “wants” from the underlying true needs, and distinguish solution ideas from requirements.

Systems thinking skills Although a business analyst must be detail-oriented, he must also see the big picture. The BA must check requirements against what he knows about the whole enterprise, the business environment, and the application to look for inconsistencies and impacts. The BA needs to understand the interactions and relationships among the people, processes, and technology related to the system ([ref115]). If a customer requests a requirement for his functional area, the BA needs to judge whether the requirement affects other parts of the system in unobvious ways.

Learning skills Analysts must learn new material quickly, whether it is about new requirements approaches or the application domain. They need to be able to translate that knowledge into practice efficiently. Analysts should be efficient and critical readers because they have to wade through a lot of material and grasp the essence quickly. You do not have to be an expert in the domain, so don’t hesitate to ask clarifying questions. Be honest about what you don’t know. It’s okay not to know it all, but it’s not okay to hide your ignorance.

Facilitation skills The ability to facilitate requirements discussions and elicitation workshops is a vital analyst capability. Facilitation is the act of leading a group towards success. Facilitation is essential when collaboratively defining requirements, prioritizing needs, and resolving conflicts. A neutral facilitator who has strong questioning, observational, and facilitation skills can help a group build trust and improve the sometimes tense relationship between business and IT staff. Chapter 7 presents guidelines for facilitating requirements elicitation activities.

Leadership skills A strong analyst can influence a group of stakeholders to move in a certain direction to accomplish a common goal. Leadership requires understanding a variety of techniques to negotiate agreements among project stakeholders, resolve conflicts, and make decisions. The analyst should create a collaborative environment, fostering trust among the various stakeholder groups who might not understand each other’s motivations, needs, and constraints.

Observational skills An observant analyst will detect comments made in passing that might turn out to be significant. By watching a user perform her job or use a current application, a good observer can detect subtleties that the user might not think to mention. Strong observational skills sometimes expose new areas for elicitation discussions, thereby revealing additional requirements.

Communication skills The principal deliverable from requirements development is a set of written requirements that communicates information effectively among customers, marketing, managers, and technical staff. The analyst needs a solid command of the language and the ability to express complex ideas clearly, both in written form and verbally. You must be able to write for multiple audiences, including customers who have to validate the requirements and developers who need clear, precise requirements for implementation. A BA needs to speak clearly, adapting to local terminology and to regional differences in dialect. Also, a BA must be able to summarize and present information at the level of detail the target audience needs.

Organizational skills BAs must contend with a vast array of jumbled information gathered during elicitation and analysis. Coping with rapidly changing information and structuring all the bits into a coherent whole demands exceptional organizational skills and the patience and tenacity to make sense from ambiguity and disarray. As an analyst, you need to be able to set up an information architecture to support the project information as it grows throughout the project ([ref013]).

Modeling skills Models ranging from the venerable flowchart through structured analysis models (data flow diagram, entity-relationship diagram, and similar diagrams) to Unified Modeling Language (UML) notations should be part of every analyst’s repertoire ([ref013]). Some will be useful when communicating with users, others when communicating with developers, and still others purely for analysis to help the BA improve the requirements. The BA will need to know when to select specific models based on how they add value. Also, he’ll need to educate other stakeholders on the value of using these models and how to read them. See Chapter 5, Chapter 12, and Chapter 13 for overviews of several types of analysis models.

Interpersonal skills Analysts must be able to get people with competing interests to work together as a team. An analyst should feel comfortable talking with individuals in diverse job functions and at all levels of the organization. A BA should speak the language of the audience she is talking to, not using technical jargon with business stakeholders. She might need to work with virtual teams whose members are separated by geography, time zones, cultures, or native languages. A BA should be easy to communicate with and be clear and consistent when communicating with team members.

Creativity The BA is not merely a scribe who records whatever customers say. The best analysts invent potential requirements for customers to consider ([ref199]). They conceive innovative product capabilities, imagine new markets and business opportunities, and think of ways to surprise and delight their customers. A really valuable BA finds creative ways to satisfy needs that users didn’t even know they had. Analysts can offer new ideas because they are not as close as users to the problem being solved. Analysts have to be careful to avoid gold-plating the solution, though; don’t simply add new requirements to the specification without customer approval.

In addition to having specific capabilities and personal characteristics, business analysts need a breadth of knowledge, much of which is gained through experience. They need to understand contemporary requirements engineering practices and how to apply them in the context of various software development life cycles. They might need to educate and persuade those who are not familiar with established requirements practices. The effective analyst has a rich tool kit of techniques available and knows when—and when not—to use each one.

BAs need to thread requirements development and management activities through the entire project life span. An analyst with a sound understanding of project management, development life cycles, risk management, and quality engineering can help prevent requirements issues from torpedoing the project. In a commercial development setting, the BA will benefit from knowledge of product management concepts. BAs benefit from a basic level of knowledge about the architecture and operating environment, so that they can engage in technical conversations about priorities and nonfunctional requirements.

Knowledge of the business, the industry, and the organization are powerful assets for an effective BA ([ref115]). The business-savvy analyst can minimize miscommunications with users. Analysts who understand the organization and business domains often detect unstated assumptions and implicit requirements. They can suggest ways that users could improve their business processes or propose valuable functionality that no other stakeholder thought of. Understanding the industry domain can be particularly helpful in a commercial environment so analysts can offer marketplace and competitive product analysis.

Great business analysts are grown from diverse backgrounds of education and work experience, so they will likely have gaps in their knowledge and skill sets. All analysts should decide which of the knowledge and skills described in this chapter pertain to their situation and actively seek to fill their own gaps. The International Institute of Business Analysis (IIBA) describes the competencies that entry-level, junior, intermediate, and senior business analysts should exhibit across the common BA activities ([ref117]). All new BAs will benefit from mentoring and coaching from those who have more experience, perhaps in the form of an apprenticeship. Let’s explore how people with different backgrounds might move into the analyst role and see some of the challenges and risks they’ll face.

The rookie

Becoming a business analyst is a good entry point into the information technology arena for someone right out of school or coming from a completely unrelated job. The new graduate will have little, if any, relevant experience or knowledge. He will likely be hired into the BA role because he demonstrates many of the skills required to be a good analyst. An advantage of hiring a novice as a BA is that he will have few preconceived notions about how requirements processes should work.

Because he lacks related experience and knowledge, a new graduate will have much to learn about how to execute the BA tasks and the intricacies of the practices. The recent graduate also needs to learn enough about the software development process to understand the challenges that developers, testers, and other team members face so he can collaborate effectively with them. Mentoring can reduce the learning curve for a novice BA and instill good habits from the outset.

No matter what his background, a creative business analyst can apply it to enhance his effectiveness. The analyst needs to gain the knowledge and skills he is lacking, build on any past experiences, and practice performing the BA tasks to become more proficient. All of these help create the well-rounded BA (Figure 4-2).

Figure 4-2. Knowledge, skills, and experience feed into creating an effective business analyst.

On projects using agile development methods, the business analyst functions still need to be performed, but the individual who does them might not be called a BA. Some agile approaches have a key team member called the product owner. The person in that role might perform some of the traditional business analysis activities, as well as providing the product vision, communicating constraints, prioritizing the product backlog of remaining work, and making the ultimate decisions about the product ([ref045]). Other projects maintain a business analyst role separate from the product owner. Additionally, other team members, such as developers, perform portions of the analyst role. The point is that, regardless of the project’s development approach, the tasks associated with the BA role still have to get done. The team will benefit from having members who possess the skills associated with business analysts.

Often, in an organization moving toward an agile development approach, the BA finds herself unsure as to how she can most effectively contribute to the project. In the spirit of agile development, the analyst has to be willing to step out of a preconceived role of “business analyst” and fill in where needed to help deliver a successful product. [ref095] offers a detailed list of how traditional business analyst activities can be adapted to an agile environment. Following are a few suggestions for a BA to apply her skills on an agile project:

There is a lot of value in having a role such as a product owner to represent the users throughout development. However, the person filling the product owner role might not have all of the business analysis skills or time to perform all the related activities. A BA can bring those critical capabilities to the team.

Software projects sometimes experience strained relationships among analysts, developers, users, managers, and marketing. The parties don’t always trust each other’s motivations or appreciate each other’s needs and constraints. In reality, though, the producers and consumers of a software product share common objectives. For corporate information systems development, all parties work for the same company, so they all benefit from improvements to the corporate bottom line. For commercial products, happy customers generate revenue for the producer and satisfaction for the developers.

The business analyst has the major responsibility for forging a collaborative relationship among the user representatives and other project stakeholders. An effective analyst appreciates the challenges that both business and technical stakeholders face and demonstrates respect for his or her collaborators at all times. The analyst steers the project participants toward a requirements agreement that leads to a win-win-win outcome in the following ways: