“Behind the Scenes” in Business Analysis

“Behind the Scenes” in Business Analysis

Everything has a beginning, or a starting point – so do the products and solutions being developed. To find a solution, you need to know the problem, or the difficulty, or the improvement you need to solve/make. To walk the proper path with no extra miles, we use the tool called business analysis and requirements engineering. It is how every team member involved in the process of solution development knows the way, follows the way.

The main role in the business analysis itself belongs to the business analyst - from point “plain” to point “rich” in the life-cycle of the project requirements – the CREATOR.

Some ALT text

We will manage to cover the aspects of the business analysis itself, what it’s made of, the benefits and the tolls alongside.


The business analyst always starts with the “what?” in order to come to the “how?”. Or more precisely, the main foundation of every business analysis are the requirements themselves – what we need to solve the problem and how to perform.

Among the many descriptions and definitions of what requirement really means, we would choose the mixture of the following to get it closer to you.

“A specification or capability that’s necessary in solving a problem or accomplish objectives and goals. A necessity to be met by a system to satisfy objective/goal.”

We have the following types of the requirement being analyzed:

  • High Level (expressed by the client) vs. Specific (expressed by the implementer to meet the expression by the client)
  • Business (the problem that needs to be solved…”increase the number of orders from customer by “x” value within “x” time)
  • User (general features to be supported…”add customer data; view activity history; add new order”)
  • Functional (break-down the user requirement…”customer fill in form; link customer name to social media account; sorting/filtering by criteria”)
  • Non-functional (add value to the functional…”support more than “x” number of users…”
  • Implementation (system requirements or requirements from users that will use the system…”the system must run on “x” platform…”)

Basically, we use the first two types as a foundation for the thorough business analysis that needs to be developed and used in development. As the following are presented, up-bottom, we go into details as the analysis requires, the size of the project and the needs of the team involved in the development itself.

Place the FOCUS on the SCOPE

Prior starting developing a project, with the business analysis we define the scope of the project itself – what will be developed in a given period of time; what the final product will include…what is the complete set of features that the solution is agreed upon to include?

Very often, companies do experience for what is called “a scope creep”. And this is the danger zone we all need to avoid to happen:

“The never-ending story of adding features during solution development without bearing in mind the budget or the schedule – expanding the initial scope.”

And how we can avoid it?

  • Agree on the scope with the client
  • Create new scopes if additional features are required
  • Prioritize
  • Note the benefits of the current scope timeline and features

The magic power behind Business Analysis

It is magical indeed. Why? Well, very simple. Clients have specific needs. Clients sometimes don’t know what they need. Clients sometimes don’t know how to express their needs. Business Analyst should help get this revealed.

Here, it is worth mentioning one section from the Fred Brooks’s book "No Silver Bullet: Essence and Accidents of Software Engineering", that very clearly describes the power we mention. (Fred Brooks is a computer architect, software engineer and computer scientist – National Medal of Technology in 1985):

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

The Process and Tools used

How business analysis is actually done:

  1. The analyst tries to understand the business
  2. Dive deep into their core
  3. Learn the internal processes of the business
  4. Research competition
  5. Research similar solutions available on the market
  6. Write down the chaos on paper
  7. De-chaos it and send it for feedback to the client
  8. Iterations! Iterations! Iterations. It’s all about it until we come down to the specific needs.
  9. Wire framing is essential for every party involved – to display the processes that need to be developed visually.
  10. Conceptualize
  11. Pre-finalize (70% no finalization)
  12. Prioritize

And the very important detail that needs to be taken into consideration are the tools being used throughout the process. To note:

  • The tools used need to be standardized for: analysis, documentation, wire framing.
  • This way, the chaos will be reduced.
  • Team members will get used to the visuals and the terms.

The Document

As a product coming out from the business analysis is the business analysis document specification. Most of you have been caught in a situation for searching templates and guidelines online to start from and to be led by. Well, guess what? The “right one” for all of us does not exist. We all function differently, read differently, and act differently. Yes, we use the existing templates online to just see how others have succeeded in their own standardization and can be used for basics but you need to prepare your own standard document template based on your needs.

What we all need to follow regarding the document is the following:

  • Flexibility matters – It meets our organization’s variety in projects. For the project’s needs, we need to be able to change the document.
  • The business analysis needs to be complete.
  • Yes, the data needs to be accurate as all the team members are led by this document.
  • Understandable: Communicate with your team, learn their way of thinking/understanding, make it easy for them…make it easy for all.
  • Use Cases. This is the “blessing” for the developers, it gives even clearer picture of the processes and the actors involved.
  • Wireframes…Visual Models
  • Since the document is being updated continuously, versioning is essential as to know the frequency of changing.
  • Life Materia. It is not a static document, so is the software being developed.

The Benefits

What is the most satisfactory fact of being a business analyst or involved in the business analysis itself, is that you learn businesses and industries they belong to. You learn clients, people, how they think and act.

And the following:

  • You become an artist – drawing can be fun.
  • Up-sales. Learning the business gives you the enormous scope of opportunities for suggesting new features to the client and thus performing up-sales for your company.
  • You understand people…and most importantly you understand your team.
  • Development gets easier…you save people’s time.
  • You meet client’s needs.
  • Make it easy for the future.

Some ALT text

Share this article

Stay updated with HASELT by signing up for our newsletter

Don't worry, we hate spam too!

Keep reading

HASELT, General sponsor @ StartUp Academy closing event

HASELT, General sponsor @ StartUp Academy closing event

In the time period between the beginning of September until mid-December, the team behind the StartUp Academy, along with the help of the already proven…

Read more
Towards good enough code: Re-factoring a business rule check with the Specification Pattern

Towards good enough code: Re-factoring a business rule check with the Specification Pattern

The other day, one of my colleagues asked me for a code review on a specific part of code that was written and I said let's dig a little deeper into the…

Read more