I created my own Business Analysis Framework to synthesize my two-year professional experience as a business analyst for enterprise software development projects.

Do note that the framework is contextualized for enterprise software development, but this may come in handy too for any business analysis role in other industries.

Experience has taught me that business analysis, in general, boils down to identifying and solving the right business problem. It's a matter of uprooting the real problem by asking the right questions and using your specialization, in my case—enterprise software, in delivering the solution.

The Business Analysis Framework

This flowchart aims to encapsulate the common themes I do for different projects. I decided to use a flowchart because it is still the most comprehensible diagram for both business and technical folks.

The double-sided arrows depict the iterative nature of BA work. We all know that waterfall is too idealistic for the real world.

Activities in blue are touchpoints to the client. The BA work I am in is service-oriented; my job starts with client needs and ends with their satisfaction. I gather requirements from them and prove to them that we have delivered what they asked.

The framework applies to implementation-type of engagements, where enterprise software delivery is essentially the whole point. Pre-sales and consulting work would require a different baseline, which would most likely exclude the delivery phases.

My job is to ensure that business requirements are delivered in the enterprise software we're building for the paying client. The flowchart depicts the activities that are essential to achieve this objective.

Now that the context is clear, let's proceed with the discussion!

The five (5) common activities of business analysis for enterprise software projects are the following:

  1. Elicit Requirements - Identify current process, business problem and engagement priorities.
  2. Analyze Requirements - Finalize functional specifications based on business requirements, technical capability and project resources.
  3. Communicate Requirements - Refine and discuss functional specifications and with the project delivery team.
  4. Validate Delivery - Use the system as designed to check if the features meet the requirements. The most technical part of BA work!
  5. Prove Delivery - Trace system features with agreed requirements. Present actual system to clients.

1. Elicit Requirements

At this stage, the term 'elicit' is used instead of 'gather' to convey the proactive role of a business analyst during project initiation. A business analyst does not only gather requirements, but also asks the right questions.

In eliciting requirements, the objective of the business analyst is to identify the real business problem first before defining the solution. The mindset should be agnostic to implementation.

This stage goes hand-in-hand with the analysis stage, but elicitation is more focused on understanding the current process, which goes beyond and deeper than the client's intended implementation.

Eliciting requirements for bigger clients

Bigger clients, which are essentially huge corporations, send a business requirements document (BRD) to its potential vendors. This document contains their vision of the solution. My job is to contextualize the BRD items by understanding the current process in breadth and depth.

Image: Except of an actual Business Requirement Document from a huge corporation

Here's how I elicit requirements for bigger client:

  1. Understand their current process. I do this by analyzing the artifacts they actually use in their line of business. For this excerpt, I studied the entailed activities per billing cycle and how settlement amounts are calculated.

  2. Reconcile the current process with the business requirements stated in the BRD. In this step, you will be able to identify their priorities. For this excerpt, I noticed that they want a solution that would improve the precision of the settlement calculations.

  3. Clarify questionable items in the BRD during requirement elicitation meetings. For this excerpt, I had to ask if the envisioned solution has to support both 5 or 15-minute intervals.

  4. Refine the BRD with the client to document agreements at this phase, if needed.

Eliciting requirements for smaller clients

Smaller clients, which pertains to small to medium enterprises (SMEs), usually don't have the time to draft a business requirements document for potential vendors. They usually just state their interest for a quotation.

Here's how I elicit requirements for smaller clients:

  1. Do initial research of the business process by collating actual business artifacts that they use in their line of business.

  2. Meet with the process owners and the project champion. Let them narrate their own business process. Clarify items from initial research. Identify their priorities and the intended scope. One example: "Does the solution have to cover the whole HR process, or only payroll?"

  3. Document the current process and use it for solutioning (identifying functional specs, composing quotation).

Elicit Requirements: In a nutshell

Output:

  • For bigger clients: a final Business Requirements Document approved by the client and the vendor (the company the BA is working for!)
  • For smaller clients: Documentation of the current process and their priorities

Skills:

  • Learning fast. BAs are required to understand the business domain right off the bat.
  • Facilitating requirements elicitation meetings with clients
  • Documenting agreements
Back to top


2. Analyze Requirements

Analyzing requirements requires the business analyst to consider the implementation of elicited business requirements.

To accomplish this, the business analyst drafts the functional specifications, which are versed to be comprehensible for system implementation.

For instance, a business requirement would sound like this:

1.3.1 The system shall allow the users to perform calculations for trading amounts, calculations for market fees for energy, and calculations of market fees for reserves as separate processes.

The corresponding functional specifications for that requirement are the following: 

Settlement Process Type: Main  
Step 1: Calculate Settlement Amounts  
Step 2: Calculate GMR (without Energy and Reserve Market Fees)  
Step 3: Finalize Calculations

Settlement Process Type: Energy Market Fees  
Step 1: Calculate Energy Market Fees  
Step 2: Finalize Energy Market Fees

Settlement Process Type: Reserve Market Fees  
Step 1: Calculate Reserve Market Fees  
Step 2: Finalize Reserve Market Fees

In this case, roughly seven (7) features have to be implemented to meet the business requirement of separating the calculations for energy and market fees.

For more complex requirements, a business analyst can collaborate with the technical lead in defining the specifications.

Functional specifications are pre-requisites in designing the technical solution and estimating efforts. Finalizing the scope of work is a collaboration between the project manager, technical lead/architect and the business analyst.

Do note that the analysis phase goes hand-in-hand with elicitation phase. The business requirements can still be revised at this stage based on technical capability and available resources (time, manpower).

Here's how I analyze requirements:

  1. Translate BR items to functional specifications (or in my practice, use cases)
  2. Per use case, identify actors, business rules, initial acceptance criteria.
  3. Relay the use case index to the project manager and the technical architect. Bring up items with complex business rules to account for QA work.
  4. Refine the use case index based on their feedback.

Analyze Requirements: In a nutshell

Output:

  • Use Case Index - functional specifications that are itemized and ready for system implementation. The more specific at this stage, the better. Items in the index would fill out the product backlog.

Skills:

  • Writing functional specifications
  • Working knowledge in software development. Comfortable with technical concepts such as APIs, ESBs, servers, UI/UX, etc.
  • Estimating effort based on available resources
Back to top


3. Communicate Requirements

Now that the scope, timeline and delivery team are finalized, it's time to implement the software.

If your company observes Agile, communicating requirements to the delivery team is usually done during Sprint planning sessions.

During Sprint planning sessions, the business analyst has to discuss the product backlog to the delivery team and suggest features to prioritize based on the timeline. She also has to be ready to answer questions on the functional specifications.

Here's how I communicate the functional specifications to the delivery team:

  • Create big-picture diagrams: activity diagrams, system flowcharts.

Image here Image: Sample system flowchart from one of my projects

  • Refine use case descriptions and acceptance criteria.

Image here Image: A preview of one use case description

  • Wireframes, mockups and templates are helpful to the developers too.

Image here Image: Sample mockup

Image here Image: Sample wireframe

Other forms of communication include the following:

  1. Functional specifications overview during design workshops
  2. Face-to-face discussion with developers and QAs
  3. Remote discussion with developers and QAs (Email, skype or slack)
  4. Clarifying specifications with the process owners through meetings and email

Communicate Requirements: In a nutshell

Output:

  • Use Case Description or Acceptance Criteria for each business feature
  • Templates - Useful for report generation features
  • Wireframes or mockups
  • System Flowchart to illustrate bird's eye view of the solution
  • UML Diagrams: use case diagrams, activity diagrams, sequence diagrams, state diagrams

Skills:

  • Business writing skills
  • Basic UI/UX knowledge
  • Wireframming
  • Diagramming: UML-standard or not
  • Presentation skills
  • Prioritization
Back to top


4. Validate Delivery

Once the system has been implemented, the business analyst has to conduct functional validation to check if the system is working as intended by the business.

Validating features can be as simple as using the system through its user interface. I just use the system as intended in the use case.

For more technical projects, functional validation can be as technical as running batch jobs and executing SQL statements in the database.

Image here Image: Sample script

If the project requires me to validate the business data, here's my process:

  1. Understand the system design from the back-end to front-end
  2. Create test scenarios based on the system design and use cases. QA engineers handle negative scenarios and more complex permutations.
  3. Prepare and insert the expected business data into the right tables.
  4. Execute the test scenarios. Manipulate the input as necessary

Validate Delivery: In a nutshell

Output:

  • Test Data
  • Test Script - in SQL
  • Functional Validation Logs per feature

Skills:

  • Understanding the system design
  • Creating test scenarios
  • Data analysis tools: SQL, Google sheets
Back to top


5. Prove Delivery

Now that the features are completed in a release, it's time to show to the client what the delivery team has done!

There are two ways to prove delivery: system demonstration/UAT support and requirements traceability

System demonstration and UAT Support

System demonstrations are usually done after a release and before user acceptance testing (UAT).

The business analyst demonstrates the actual system to various audiences from the client side, which are usually the process owners and the project champion.

The quality assurance engineers (QAs) lead the UAT sessions, but the business analyst has to stand by for questions in the requirements and scope.

Most clients are pleased with the fact that the solution to their business need is real and now available. But some clients would raise items that are excluded in the system. At this point, the business analyst has to manage expectations and gently remind the clients of the agreed scope.

Requirements Traceability

Image: Excerpt of RTM

Another method of proving delivery is drafting the Requirements Traceability Matrix (RTM), a document that aligns the system features with the items in the original business requirements document (BRD).

Prove Delivery: In a nutshell

Output:

  • Slides for System Demonstration
  • Test Data for System Demonstration
  • Release Notes
  • UAT Report
  • Requirements Traceability Matrix

Skills:

  • Presentation Skills
  • Business Writing Skills: for Release Notes, RTM
Back to top


Conclusion

(Wow, I did not expect this post to reach 2000 words!)

A framework is valid if it is applicable to many, if not, all scenarios.

The Business Analysis framework is a synthesis of the common patterns I discovered in doing business analysis work for four different system implementation projects. I also borrowed some ideas from BABOK version 3.

That's why I'm confident that the framework will be applicable for my future business analysis engagements, may it still be in enterprise software or something else!

I may have discussed each of the five (5) common activities based from my experience, but I believe the framework works for other domains as well.

Here are the five (5) common business analysis activities with general descriptions:

  1. Elicit Requirements - Identify business requirements based from the real business problem.
  2. Analyze Requirements - Align business requirements with available resources.
  3. Communicate Requirements - Discuss business requirements with the delivery team to come up with the solution.
  4. Validate Delivery - Check if the solution meets the business requirements.
  5. Prove Delivery - Demonstrate the solution to the stakeholder. Prove that the solution is what they are looking for!

These activities are essential in meeting the objective of every business analyst: to identify and solve the right business problem.

Back to top