Summary: Business analyst best practices - Three things a business analyst should keep in mind during software design meetings.
When it comes to working as a business analyst, I've learned that there are just three technical things you need to keep in your mind when meeting with your customers (the project sponsor (gold owner) and domain experts ("goal donors")) to gather requirements. These three thoughts will keep your meeting on track, lead you to the next question, and will help you know when your work is done.
Those three Business Analyst requirement-gathering thoughts are:
I've met with dozens -- possibly hundreds -- of customers over a 15-year career as a Business Analyst, and no matter what you think your job is -- if you're trying to perform your job efficiently -- creating these documents is your primary concern, your only concern.
You can handle your meetings as Mr. Nice Guy or Ms. All-Business, but in the end, finishing these three documents is the only thing that matters. And, as a side benefit, a very cool thing about this approach is that if you keep those three goals in mind, you'll always know what questions to ask next.
I know, I know, a lot of business analysts just write requirement specifications without creating a data model or user interface prototypes. I know there's supposed to be a difference between requirements and analysis, but sorry, based on my experience, that separation of concerns doesn't work in the real world.
I'll agree that you don't have to completely design the database as you go along (like I do), but you must create some form of data model, otherwise how will you know what you're missing, or when you're finished? (I'll write another article in the near future about how Function Point Analysis helps you know when you're done, and what you might be missing.)
As for the need for user interface prototypes, as they say, a picture is worth a thousand words. I've seen customers complete agree with a use case, then balk when they see screens that correspond with the use case. Some people might call that an "implementation detail", but I call it "communication." Believe me, as a consultant, you must know that the customer agrees with the planned interface before you give them a bid.
Your business may be staffed differently than mine, and it may not be your direct responsibility to create the requirements specification, database design, and prototypes, but for me, as a business analyst, these are still your deliverables, and your responsibility. Someone else may perform the work, but that work still has to be done, and very importantly, you need to know what's missing.
I'm sure other thoughts may be rambling through your mind right now, perhaps thinking about things like time and cost estimates, but for me, those come later on in the process.
Okay, okay, if pushed hard enough I will admit that on more complicated projects you also need to consider the software and hardware architecture of your proposed solution, but I'm leaving this off my "Top 3" list for several reasons.
First, the architecture of most software projects is so simple that it doesn't need to be discussed. You just say "This will be a web application developed in Java, using our usual toolset, and we'll be hitting these databases on the back end, creating our new tables here, here, and here", and that's the whole discussion.
Second, most goal donor's don't care about this implementation detail ... well, at least not until you tell them the cost. :) But even then, at least 75% of the goal donors don't care about the architecture, nor will they understand it. It also doesn't affect them, as long as it matches the stated requirements.
Third, in many large organizations, there seems to be some sort of political firewall installed between business analysts and software architects, and I'm just not up for tackling that battle today. I do think business analysts should have a firm understanding of how a solution will be implemented, and they should know when a customer starts talking "crazy talk" (requests that are way out there, or are technically very, very difficult), but at most large organizations the business analyst is only allowed to go 80% of the way up the mountain, and then the software architecture people say, "We'll take it from here."
To summarize, yes, on more complicated projects you will have to discuss the planned architecture with some people, but not with all of them, so that's why I've left if off my "Top 3" list.