BestPrice Flight Booking System Analysis

The problem: when an “online” process still relies heavily on people

This project analyzed BestPrice’s current online flight booking process, with the goal of surveying the as-is workflow, identifying operational bottlenecks, and then proposing a redesigned to-be process to improve user experience and increase automation.

The online flight booking process looks digitized on the surface, but in practice it still relies heavily on manual work from customer service staff, especially in confirmation and order processing steps. This leads to a suboptimal user experience, makes order status hard to track, and carries operational risk of error.

Since there was no direct access to the business itself, the team built the analysis based on hands-on experience using the BestPrice website, combined with desk research and observation of the existing workflow — an approach closer to real-world Business Analyst work than just studying theory.

Role: from stakeholder analysis to full system modeling

Within a 5-person team, the work spanned nearly the entire scope of a Business Analyst’s responsibilities, from analysis through to technical modeling:

• Analyzed stakeholders and built a Stakeholder Management plan
• Built a RASCI Matrix to clearly define roles and responsibilities
• Built a Fishbone Diagram (POPIT) to trace the root causes behind problems in the current process
• Analyzed and fully specified Business Requirements, Functional Requirements, Technical Requirements, and Non-functional Requirements
• Designed the Use Case Specification
• Built the Activity Diagram, Sequence Diagram, and Entity Relationship Diagram (ERD)
• Reviewed the As-Is and To-Be BPMN diagrams to ensure consistency with the downstream analysis documents

The process: from “spotting the problem” to “specifying the solution”

The real value of this project wasn’t drawing a lot of diagrams — it was understanding the logical chain connecting them. A business process doesn’t automatically translate into system requirements, and requirements don’t automatically translate into design diagrams. Each layer had to be rigorously derived from the one before it.

The workflow followed standard Business Analysis practice:

1. Survey and analyze the current process (As-Is) based on hands-on experience and desk research
2. Identify problems and bottlenecks in the operational workflow
3. Analyze stakeholders and build a RASCI Matrix to assign responsibility
4. Build a Fishbone Diagram to identify root causes, not just symptoms
5. Propose an optimized new process (To-Be)
6. Build Business and System Requirements based on the analysis
7. Design a detailed Use Case Specification
8. Model the system using Activity Diagrams, Sequence Diagrams, and ERD
9. Finalize documentation and prepare the presentation

Results

• Completed a full Business Analysis documentation set following standard practice
• Successfully mapped the As-Is process and proposed an optimized To-Be process
• Modeled the system using multiple diagram types: Use Case, Activity, Sequence, and ERD
• Clearly identified the core problems in the current process and proposed concrete improvements
• One of the projects that most clearly demonstrates Business Analysis capability throughout the coursework

The biggest takeaway

This was the first project to approach Business Analysis in a structured way — not just learning the concepts, but actually going through a BA’s real workflow: stakeholder analysis, business process modeling, and writing system specification documents. It was also the first time building a complete, properly standardized set of diagrams, which deepened the understanding of how Business Process, Requirements, and System Design connect — rather than focusing solely on writing code.

Limitations

• The project had no real data from an actual business; the analysis relied mainly on simulation and research
• There was no implementation phase to validate the proposed solution
• Some assumptions in the analysis may not fully reflect real-world operating conditions

If I did it again

• Try to gain access to a real business to collect more accurate data
• Conduct actual stakeholder interviews to improve the quality of the analysis
• Add a prototype or mockup to better illustrate the proposed solution
• Incorporate professional requirements management tools such as Jira or Confluence
• Build a tighter link between the analysis documentation and actual implementation feasibility