Business Analysis Notes

Introduction

The notes you see here is a dump of what I have learnt about Business Analysis so far. I initially wrote this after finishing my 8-week course at Holmesglen.

Similar to my other notes, I update them from time to time. Check on the right sidebar to see when this note is last modified.

General Concept

Business analysis is the art of understanding what the business needs to achieve (for a given problem domain) and translating that knowledge to a set of system requirements that can be used as a reference point for building a software system.

Software system in perspective

Software system is only a facility, a tool that can be crafted to do many wonderful, cool and fancy things – it doesn’t matter how many bells and whistles are attached to that system – at the end of the day the system must help the business achieve its goal for the given problem domain.

If it doesn’t do it, as far as the business is concerned the system adds little or no value; And an invaluable system == a failed system.

If the job of a software developer is to craft a good piece of software system, then the job of the business analyst is to ensure that the piece of work created, the system, does the right thing and deliver what the business needs.

The Mission

In summary, the mission of a Business Analyst is roughly:

• Understand the current state of affairs (point A)
• Understand the end vision (point B)
• Help everyone to agree on point A and point B
• Make sure that everyone are on the same page.
• Draw the line from point A and point B and capture the vision as technical documents that can be discussed, reviewed, agreed and baselined.
• At the end of the analysis procedure, a BA should be able to list out the product requirement that needs to be build by the development team and be certain that the built product will meet the project objective.

Keep in mind that Initial request for work usually comes from management, and management are often quite disconnected from operation. At the end of the day what a business need to solve the relevant problem area might not be what it ask for, initially. But it is often the case that what was asked initially will give a clue as to what it really needs.

Extracting raw information

Analysis will produce information that are not commonly perceived, and therefore it is valuable.

However, the amount of analysis that can be done are limited by the amount of raw intel available – if there are no raw data / information to be analysed, then there is nothing to be analysed!

Therefore, the tedious task of collecting raw intel is a very important first step, and it must be stressed that information gathered must be:

• complete – detailed enough to allow you to form an opinion.
• accurate – represents the truth as it was gathered.
• consistent – fits nicely into the big picture and existing information you already have in your hand.

If any of the above is violated, you have an issue you need to resolve

• incomplete information – doesn’t tells you anything and will force people to cover the gap with assumption. If this can’t be avoided, document the assumption in technical documentation and have that assumption clarified. At least, make sure everyone understand what the assumption was.
• inaccurate information – are simply misleading.
• inconsistent information – means that something is not properly understood. It could be that one client conflicts another, or that you misunderstood what was said in the first or second instance. In any case, inconsistent information reveals inaccuracy.

Don’t sit on outstanding issues, always hunt for the truth.

Hunt for the truth

Information will not come to you, you must hunt for them. Hunting for the information is the start of the BA activity.

Start with the end in mind.
- Jon Clyne, BA

When hunting for info, it is possible that you stumble on information that may lead to enlarging the problem domain. It is also possible that you discover information that are seemingly related, but actually totally irrelevant to what you need to discover. In such confusing situation, always use the end vision as guidance.

If the information reveals another piece of the puzzle to discover the big picture in question, then it is the right direction.

Technical information gathering

This is usually more applicable for systems where the objectives are roughly known, but the means to achieve the objective requires analysis on some sort of raw data to determine the best way to implement the system.

For example, building a schedule management system for hospital roster might require analysis on existing roster data to perceive some patterns. The information for existing roster schedule in the past 2-3 years can be queried from existing database of origin.

Knowing this patterns can often give an insight into an ingenious means to solve a problem.

Another thing I learned is that often, when the nature of the project involves some legacy system and the code of the legacy system is available – it could be another source of information that can be analysed.

The truth is in the code, and code never lie
- KP, project manager

Non-technical information gathering

This is usually applied for systems where the objectives / scope. Non-technical information gathering are done through interviewing people in business. Be sure to hunt for key subject matter experts (SMEs). These are people who knows the problem inside-out, and usually have a good idea that can be integrated into the solution.

Jon Clyne’s note-taking tip, which I find to be extremely useful.

• Draw a vertical line across your notebook page. Make it so that the right bit is roughly 4x wider than the left bit
• The thin area (left column) is for jotting down meta information
• The wide area (right column) is for jotting down information.
  
• As you interview people and they blurt out the information, filter out unnecessary bit in your head and jot down only the key information. This takes practice.
• If they speak too fast, just tell them to slow down. If they mumble out jargon, just ask. Never leave an unknown piece of information to float away. You are the doctor, and the people you interview are your patients. make sure that you know all the symptoms, complains of your patients – make sure that the root cause of the problem is known too.
• After the meeting, go over each information block and classify the block as either:
  issue – problem to be solved
  ideas – things that can be done
  action – stuff someone must do
• Put the meta-information next to the information block that you classify.
• Once done, go over your notes to produce meeting minutes and send it around relevant people.

Modelling information

Information models are artefacts used to represent and communicate a complex concept quickly and effectively. The most effective information models are diagrams, second to that are documents.

A picture paints a thousand words.
- an old english proverb.

The goal is to produce information model that represents the as-is, and to-be. The as-is models should capture the current state of affairs, and the to-be model should capture the vision of the end.

Once artefacts are produced they become an object that can be used as vehicle of discussion. Diagrams or documents that are circulated are very in-your-face. Either it is correct and everyone agrees or it is wrong and people object. Either case you’ll find out the truth.
- KP, Project Manager

Everyone is using UML, so should you.

There are many ways to represent concept as boxes, lines and arrows. Anyone can invent their own way of representing a concept using boxes, lines and arrows.

But if this is the case, then diagrams with all this boxes, lines and arrows will have different meaning for everyone – this is a problem because people can interpret the models differently.

To make sure that diagrams are easier to understand and interpret, standards are invented. If everyone draws in the same way, then it is easier to prevent misinterpretation. For this purposed the Unified Modelling Language is created and everyone is using them.

Therefore when modelling information, use UML. It is now also an industry standard all over the world.

As-is: the current state of affairs

Capturing an accurate as-is state of the area of the business in scope is very important, the whole project is based on the assumption that the problem is known. When the whole project is running with a wrong assumption, risks will manifest into real issues and bites you sooner or later.

Concepts that need to be fleshed out as part of the as-is models are:

• Business Process
  Capture business processes by using BPML. Don’t document the whole business, just capture the ones that will be impacted by the system. These are the ones that matters.
• Domain model
  Capture the current relationship of the logical entities involved using Entity-Relationship diagram. For example, in a software project to create an enrolment system, the logical entities are students, classes, teachers, and so on. It is also important to capture the relationship of these entities, especially when it is not obvious.

To-be: vision of the end game

The aim here is to produce artefacts that represents the vision of how the system will finally fit into the existing business model, solve the problem and deliver value.

Again, once artefacts are produced they can be circulated around key members of the project for cross-checking and approval and any conflicting information will be objected against.

In doing so, it is important to remember that you are NOT the project owner, nor should you have any personal involvement – never take a objection personally – remember that you are here to bridge the gap, not to prove that you are right.

As a consultant, you may argue with your client. But remember that at the end of the day the answer is ‘yes’.
- AK, owner of a consulting company

If your to-be models are objected against, it means that there are discrepancies in what you understood to be the end vision as to what the client perceives. Sometimes even clients / key stakeholders bicker amongst themselves on what the end should be. No problem, resolves all disagreement early, but resolves it quick. And by all means, resolve it (if you can).

Concepts that need to be fleshed out as part of the to-be models are:

• Business Process
  Capture with BPML, relevant only if the business processes changes
• Domain model
  Capture with ER diagram, domain model should change very little and should reflect the business policy at all times. It is very unlikely that the as-is model states that the univeristy now has students that can enroll in multiple classes, and the to-be model states that there are no more students, or that students can only enroll in one class. Domain model doesn’t change very often. If they do, they are accompanied by changes in the business policies.
• Business Rules
  List them out as tables – business rules / policies are part of the business policy that needs to be inserted into the system. For example, a university might have a policy that students who don’t pay their fees on time will have 60 days to settle the bills, else they will be kicked out with no exception or further consideration. If you the system being built is an enrollment system that integrates with billing, then this rule must be implemented to reflect that business policy.

Technical Specification & Documentation

Oftencase, technical specification are produced prior to building the system / at the end of the project inception. The idea is to have every key analysis artefacts baselined and agreed upon to kick start the work.

The models to be documented and baselined into various documents are usually

• Use Cases / User Goals
  Jon Clyne always mentions that Use Cases must be based on user goals. Use cases covers key scenario that the user do to do their day-to-day job.
• System Requirements / Product Features
  Product features will list out, line by line, requirement by requirement, what the system is required to do. Usually this is listed in a table of some sort.
• Non-Functional Requirement
  This should be driven by project obvectives and business policies. How long should the system be up for (availablity) is driven by the question, ‘what is the service promised by the business to its customer?’ If it’s an online order management system and the business promises to their customer base that the system will be available 24×7 (100% availability == impossible), then this needs to be catered by the solution.

Documentation format matters little to the importance of a software project. They are usually there to conform to some standards within an organization.

Therefore, focus in producing the artefacts that everyone can agree on. Don’t worry about writing long documentation – that can be done later. Good diagrams that capture the essence of the problem (as-is) and solution (to-be) can be inserted into these documents at appropriate places, and long descriptive text can be written around these information models to produce documents that will please the most strict process-nazis in an organization.

But remember, it doesn’t matter the length of the documentation, what matter is the information that it captures.

This page is wiki editable click here to edit this page.