The Practice of Business Analysis

by Gary K. Evans

As I work with, or provide training to, Business Analysts (BAs), I find many different backgrounds under this title. Some BAs come into this role from the business side, and others are developers who have only a technical background, and are confused about what the BA role entails. The common issue that arises in these interactions is: What are the practices a BA must master?

An effective BA operates successfully in two areas of practice that I will briefly discuss: those activities the BA should perform to advance the interests of the company's project, and those activities the BA should not perform.

The Goal of Business Analysis

The BA sits between the end-user/customer community, and the IT group in an organization. The goal of business analysis is to transform user and customer needs into requirements that can be technically implemented and delivered by the IT group.

Note that I said customers have "needs", or wishes, and project requirements must be identified from these needs and wishes. Customers seldom give us actual requirements.

What customers usually offer us is a statement of what is not working for them, and that they want a solution that will do X, Y, and Z. For example, "Our customer account and customer buying history information is scattered everywhere. We have to use multiple applications to see everything. We need to consolidate everything under a single customer identifier, so anyone talking to a customer can see all the interactions we have had over time." When you ask this person what the requirements are for this solution, he or she will look at you incredulously and say, "I just gave you the requirements!"

Actually, the statement above is just a concept of what the solution should provide. The requirements underlying this conceptual goal would be identified by answering questions such as:

• What access security must be implemented to protect customer information from improper viewing, and improper modification?
• Must we allow multiple-user access to this customer information?
• Can we delete a customer account, or must we only inactivate a customer account?
• Do we allow, and how do we manage, merging two accounts into one?
• Is the goal to physically, or logically, consolidate this "scattered" information?

We could list many more questions that would define the actual requirements. You will often hear that BAs must "capture" the requirements of a system. I much prefer the term I learned from Mike Cohn of Mountain Goat Software. He says we must "trawl" for requirements. I love this word because it evokes the mental image of a net dragging over the bottom of a river or bay, with all kinds of gunk being stirred up. And sometimes the items we are actually trawling for - the requirements - land in our net. Requirements identification is often dirty, haphazard and tinged with a hue of randomness.

Two other goals are just as important for business analysis. First, the BA-to-Customer interface identifies the "what" of a project: What are the customer needs? What business forces motivate the project? What constraints exist on the project? Second, the BA-to-IT interface enables - but does not define - the "how" of a project.

Here is a graphic that illustrates the BA's role between these two communities:

What the BA Does Not Do

And it is just as important to understand what a BA does not do. Here is a short list of the lines that a BA should not cross.

The BA should not set schedules or make delivery commitments.

This is a project management jurisdiction. Schedules and delivery commitments need requirements as inputs, and providing these is the proper jurisdiction of the BA.

The BA should not make up, prioritize, or remove requirements on his/her own.

Again, this is a jurisdictional matter. You, the BA, are not the customer. You do not speak as the customer. But you are a conduit for the "voice of the customer". The BA should be like a good journalist, who reports the news, and does not make up the news.

The BA should not express unverifiable requirements.

One of my favorite examples of this error comes from a course from IBM/Rational, which offers an example requirement of "The screen shall be a pleasing shade of green". Another example of an unverifiable non-requirement is: "The user experience shall be positive". These examples are the types of statements made when the writer does not have anything useful to offer. Don't be one of these writers of requirements.

The BA shall not convey all requirements are equal.

All requirements are definitely not equal. Not equal in priority, in business value, even in being required. Have you seen - or written - that a requirement is "desirable" or "optional"? An "optional " requirement is an oxymoron. A requirement is either required, or it's not. And just because 10 requirements are stated, does this imply that all are of equal status or priority on the project? No.

The BA shall not ignore the audience reading the requirements.

Different requirements have different primary audiences. User requirements, such as use cases or user stories, have users as their primary audience. Non-functional requirements have architects as their primary audience. Functional requirements have IT/Development as their primary audience.

Much more information on requirements identification and the role of the BA is in my Pragmatic Business Analysis course, and my Business System Analysis for Object-Oriented Projects courses.

Have a productive month,

    Gary K. Evans