Business Analysis Fundamentals — CS Notes
Business Analysis Fundamentals
Complete Study Notes with Real-Life Examples
Topics: What is a BA | Roles & Responsibilities | SDLC | Waterfall Model
Topic 1: What is a Business Analyst?
Simple Definition
A Business Analyst (BA) is a person who sits between the business side (clients, managers,
stakeholders) and the technical side (developers, designers) of a project. The BA makes sure
that both sides understand each other perfectly.
Real-Life Analogy: The Translator
Think of a Business Analyst like a translator at the United Nations.
The client (business side) speaks in business language:
"We want our customers to order food online easily and pay securely."
The developer (technical side) speaks in tech language:
"We need REST APIs, a MySQL database, a payment gateway, and a mobile-responsive
UI."
The BA understands BOTH languages and converts the client's wishes into exact technical
requirements for the developers. Without the BA, both sides would be confused!
Another Real-Life Example: Pizza Shop App
Imagine a Pizza shop owner named Ahmed wants to create a mobile app for his shop. He says:
• "Customers should be able to order pizza from their phone"
• "I want to see daily reports of how many pizzas were sold"
• "Customers should get notifications when their order is ready"
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
The BA's job is to:
• Meet with Ahmed and ask detailed questions about what he wants
• Write down exact requirements (e.g., which phones? Android or iPhone? Both?)
• Create diagrams showing how the app should work
• Give all this information to the developers in a clear document
• Make sure the final app matches what Ahmed actually wanted
Why is a BA Important?
Without a BA, companies waste millions of rupees building the WRONG product. Studies show
that 70% of software projects fail because requirements were unclear. The BA prevents this.
Without BA With BA
Developers guess what client wants Developers know exactly what to build
Requirements change constantly Requirements are clear from the start
Project goes over budget Project stays on budget
Client is unhappy with result Client gets exactly what they wanted
Project delivered very late Project delivered on time
Where Does a BA Work?
• Banks and financial companies
• Software and IT companies
• E-commerce companies (like Daraz, Amazon)
• Healthcare and hospital management systems
• Government projects
• Any company that builds or uses software
Topic 2: Roles and Responsibilities of a Business
Analyst
A Business Analyst has many different jobs to do throughout a project. Think of them as having
6 main roles:
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Role 1: Requirements Gatherer
The BA collects information about what the business needs.
HOW? Through interviews, meetings, surveys, and workshops with stakeholders.
REAL EXAMPLE: A hospital wants to build a patient record system. The BA meets with
doctors, nurses, and the hospital manager. She asks:
• What information do you need about each patient?
• Who should have access to records?
• Should it work on mobile phones or only computers?
• What should happen if a patient is transferred to another hospital?
All these answers become the official Requirements Document.
Role 2: Bridge Between Business and IT
The BA translates business language into technical language and vice versa.
REAL EXAMPLE: During the hospital project, doctors say:
"We need to see a patient's complete history immediately in an emergency."
The BA translates this for developers as:
"The system must retrieve all patient records within 2 seconds. The emergency dashboard
should show the last 5 visits, current medications, allergies, and blood type on one screen
without scrolling."
This precision is what developers actually need to code!
Role 3: Process Analyzer
The BA studies how the business currently works (As-Is Process) and designs how it
SHOULD work (To-Be Process).
REAL EXAMPLE: Old hospital process (As-Is):
Patient arrives → Fills paper form → Receptionist types data into system → Doctor
searches for records manually → 20 minutes wasted
New process designed by BA (To-Be):
Patient shows CNIC → System auto-loads all records → Doctor sees everything instantly
→ 2 minutes saved per patient
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
The BA finds what is wrong and designs the better solution.
Role 4: Documentation Expert
The BA writes important documents that guide the entire project.
KEY DOCUMENTS a BA produces:
1. BRD (Business Requirements Document) - What the business wants
2. FRD (Functional Requirements Document) - What the system must do
3. User Stories - Short descriptions of features from the user's view
4. Use Case Diagrams - Visual diagrams showing system interactions
5. Process Flow Diagrams - Step-by-step flow of how things work
EXAMPLE User Story: "As a doctor, I want to see a patient's allergy list before prescribing
medicine, so that I don't give them something dangerous."
Role 5: Testing & Quality Checker
The BA verifies that what was built actually matches what was required.
REAL EXAMPLE: After the hospital system is built, the BA checks:
✓ Can the doctor access patient records in under 2 seconds? (Test it!)
✓ Does the allergy alert appear when prescribing medicine?
✓ Can nurses update patient information from their tablets?
✗ Oh no! The system doesn't show blood type on the emergency screen!
→ BA reports this as a bug, developers fix it before launch.
The BA ensures the final product matches the original requirements.
Role 6: Stakeholder Manager
The BA manages relationships with all people who have interest in the project.
WHO ARE STAKEHOLDERS in the hospital project?
• Hospital Director (wants cost savings and efficiency)
• Doctors (want easy access to patient data)
• Nurses (want to update records quickly from wards)
• IT Department (wants a system that is easy to maintain)
• Patients (want their data to be private and secure)
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
• Government (wants compliance with health data laws)
The BA balances ALL their needs and ensures everyone is satisfied — this is one of the
hardest parts of the job!
Summary of All Responsibilities
Responsibility What BA Does Real-Life Example
Requirements Collects what business needs Interviews Ahmed about his pizza
Gathering app
Gap Analysis Finds difference between current Identifies that old system has no
and desired state mobile support
Writing User Describes features from user's "As a customer, I want to track my
Stories perspective order..."
Process Mapping Creates diagrams of business Draws flowchart of order-to-
processes delivery process
Facilitating Runs workshops and meetings Weekly meetings with hospital
Meetings staff
Testing/UAT Verifies the system works Tests if patient records load in 2
correctly seconds
Change Manages scope changes during Client adds new feature; BA
Management project assesses impact
Stakeholder Keeps everyone aligned Balances doctor needs vs. IT
Management budget limitations
Topic 3: Software Development Life Cycle (SDLC)
What is SDLC?
SDLC (Software Development Life Cycle) is a structured process that defines how software is
planned, created, tested, and delivered. It gives teams a roadmap to follow so that software is
built in an organized, efficient way.
Real-Life Analogy: Building a House
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Before building a house, you don't just start laying bricks randomly!
Step 1: PLANNING — Decide the budget, location, and timeline
Step 2: REQUIREMENTS — Decide number of rooms, design, facilities needed
Step 3: DESIGN — Architect draws the blueprints
Step 4: CONSTRUCTION — Workers build the house
Step 5: TESTING — Inspect electrical, plumbing, structure for any defects
Step 6: DELIVERY — Owner moves in
Step 7: MAINTENANCE — Fix any issues that arise over time
SDLC follows the EXACT same logic for building software!
The 7 Phases of SDLC
Let's understand each phase using a real-life example of building an Online Food Delivery App
(like Foodpanda).
Phase 1: Planning
This phase answers: WHY are we building this? Is it feasible?
Question Answer in Food Delivery App Example
What is the goal? Build a food delivery app to compete with Foodpanda in
Pakistan
Is it technically possible? Yes — similar apps already exist worldwide
What is the budget? PKR 50 million allocated for the project
How long will it take? Estimated 12 months for full launch
What is the risk? Market competition, technical challenges, user adoption
BA's role in Planning: The BA participates in feasibility studies and helps define the project
scope — what will and will NOT be included in the project.
Phase 2: Requirements Analysis
This is where the BA does the most work! The team collects all requirements from stakeholders.
For the Food Delivery App, the BA conducts meetings with:
• Restaurant owners — "We need to manage our menu easily"
• Customers — "We want to track our order in real-time"
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
• Delivery riders — "We need a simple app showing route to deliver"
• Business owner — "I want to see profit reports and analytics"
The BA then writes the BRD (Business Requirements Document) listing all these requirements
in clear, organized language.
Phase 3: System Design
Developers and architects plan HOW the system will be built. They create the technical
blueprint.
Design Component Food Delivery App Example
Database Design Tables for Users, Restaurants, Orders, Payments, Riders
Architecture Mobile App (Flutter) + Backend API ([Link]) + Cloud
(AWS)
UI/UX Design Figma wireframes showing all screens and user flow
Security Design JWT authentication, encrypted payments, SSL
Integration Design Google Maps API for tracking, Stripe for payments
BA's role in Design: Reviews design documents to ensure technical design covers ALL business
requirements. If something is missed, the BA raises it immediately.
Phase 4: Implementation (Coding)
Developers write the actual code. This is the phase where the app is actually built.
For the Food Delivery App:
• Frontend team builds the customer mobile app
• Backend team builds the server and database
• Restaurant portal is built for restaurant owners
• Rider app is built separately for delivery people
• Admin dashboard is built for business management
BA's role in Implementation: Available to answer developers' questions about requirements. If
developers are confused about what to build, the BA clarifies. The BA also reviews progress
regularly.
Phase 5: Testing
The system is tested to find and fix bugs before launch. This is critically important — mistakes
found here are 10x cheaper to fix than after launch!
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Type of Testing Example in Food App
Unit Testing Test that the 'Add to Cart' button works correctly
Integration Testing Test that order placed on app correctly reaches restaurant
portal
Performance Testing Test if app handles 10,000 users ordering simultaneously
Security Testing Test that payment information is properly encrypted
UAT (User Acceptance Real customers test the app and give feedback
Testing)
BA's role in Testing: The BA conducts or oversees UAT (User Acceptance Testing). They check
that the system matches the original requirements they documented.
Phase 6: Deployment
The software is released to real users. This phase includes:
• Setting up servers and infrastructure
• Migrating data from old system (if any)
• Training users on how to use the system
• Soft launch to a small group first, then full launch
BA's role in Deployment: Helps train users, creates user manuals, and ensures the deployment
plan aligns with business requirements.
Phase 7: Maintenance
After launch, the software needs ongoing support and improvements.
• Bug fixes — fixing issues found after launch
• Updates — adding new features as business evolves
• Performance optimization — making the app faster
• Security patches — protecting against new threats
BA's role in Maintenance: Collects user feedback and new business requirements, starting the
SDLC cycle again for new features.
Key Insight: SDLC is a CYCLE!
SDLC does not end after deployment. After maintenance, you gather new requirements and
the entire cycle begins again.
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Example: After the food delivery app launches, users request:
• "Add a feature to schedule orders in advance" → New SDLC cycle begins!
• "Allow group ordering for offices" → New SDLC cycle begins!
• "Add loyalty points system" → New SDLC cycle begins!
Successful software products go through many SDLC cycles over their lifetime.
Topic 4: Waterfall Model
What is the Waterfall Model?
The Waterfall Model is the oldest and simplest SDLC model. In this model, development flows in
ONE direction only — like a waterfall flowing downward. Each phase must be 100% complete
before the next phase begins. You CANNOT go back to a previous phase.
Real-Life Analogy: Making a Wedding Cake
Imagine you are baking a 5-layer wedding cake. You MUST follow these steps in order:
Step 1: Bake the bottom layer → It must cool completely before adding the next
Step 2: Place the second layer → It must be set before adding more
Step 3: Add the third layer → Same rule
Step 4: Add the fourth layer → Same rule
Step 5: Add the top layer → Same rule
Step 6: Decorate the whole cake
You CANNOT add the top layer first. You CANNOT go back and change the bottom layer
after everything is stacked. The order is fixed and must be followed strictly.
This is exactly how the Waterfall Model works in software development!
Phases of the Waterfall Model
The Waterfall Model follows 6 phases, each flowing into the next:
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Phase What Happens
1. Requirements ALL requirements are gathered and documented completely upfront
2. System Design Complete technical blueprint is created based on requirements
3. Implementation Developers write all the code based on the design
4. Testing The complete system is tested after all coding is done
5. Deployment The tested system is released to users
6. Maintenance Bug fixes and minor updates after launch
Deep Example: Hospital Management System Using Waterfall
A private hospital in Lahore hires a software company to build a Hospital Management System.
They use the Waterfall Model. Here is exactly how it goes:
Waterfall Phase 1: Requirements (Month 1-2)
The BA spends 2 full months meeting with ALL hospital staff. Nothing starts until ALL
requirements are finalized.
Requirements gathered:
• Patient registration — capture name, CNIC, address, medical history
• Doctor scheduling — doctors should be able to see their appointments
• Pharmacy management — track medicine stock and prescriptions
• Billing system — auto-generate bills based on services used
• Lab reports — store and retrieve test results
• Reports — daily patient count, revenue reports for management
A 50-page Business Requirements Document (BRD) is written and SIGNED by the hospital
director. After signing, NO new requirements are accepted.
Waterfall Phase 2: System Design (Month 3-4)
The technical team designs the complete system blueprint:
• Database schema with 25 tables designed
• System architecture: Java backend + Oracle database + Windows desktop application
• UI mockups for all 40 screens created
• Security design: role-based access (doctor sees different things than receptionist)
Design documents are reviewed by the BA to ensure all requirements from Phase 1 are
covered.
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Waterfall Phase 3: Implementation (Month 5-9)
A team of 8 developers spends 5 months writing code:
• Patient registration module — 3 weeks
• Doctor scheduling module — 4 weeks
• Pharmacy management module — 4 weeks
• Billing system — 5 weeks
• Lab reports module — 3 weeks
• Reports and analytics — 3 weeks
Important: Testing does NOT happen during coding in Waterfall. The entire system is coded
first.
Waterfall Phase 4: Testing (Month 10-11)
The complete system is tested after ALL coding is done:
• Testers find 247 bugs in the first round of testing
• Developers fix the bugs — this takes 3 extra weeks
• Second round of testing finds 43 more bugs
• After fixing, BA conducts UAT with hospital staff
• Hospital staff are trained on the new system
PROBLEM: During UAT, the hospital director says "I also want an SMS notification sent to
patients when their appointment is confirmed." — The BA says this was NOT in the original
requirements. To add it, the project timeline must be extended and extra cost added. The
hospital director is frustrated. This is a classic Waterfall problem!
Waterfall Phase 5: Deployment (Month 12)
• System is installed on hospital computers
• Old paper records are transferred to the new system
• All 200 hospital staff are trained over 2 weeks
• Old system runs parallel for 2 weeks as backup
• Full switch to new system on January 1st
Waterfall Phase 6: Maintenance (Month 13 onwards)
• Bug reports from daily use are collected
• Monthly patches released to fix issues
• New requirements added 6 months later (SMS notifications!)
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Advantages of Waterfall Model
Advantage Why It Helps
Simple to understand Easy to explain and follow — even non-technical
managers understand it
Well-documented Each phase produces detailed documents, great for
reference
Easy to manage Clear milestones — everyone knows when each phase
ends
Good for fixed requirements If requirements will NOT change, Waterfall works
perfectly
Works well for small projects Simple projects with clear scope benefit from this
structure
Disadvantages of Waterfall Model
Disadvantage Real-Life Problem
No flexibility Hospital director cannot add SMS feature mid-project
without huge delay/cost
Testing happens too late Bugs found in Month 10 are much harder to fix than bugs
found in Month 5
Client sees product only at Hospital sees the system only in Month 12 — what if they
end don't like it?
Assumes perfect requirements Nobody can predict ALL requirements 12 months in
advance perfectly
High risk for large projects A 2-year Waterfall project could deliver something
outdated by end
When to Use Waterfall?
Waterfall is the RIGHT choice when:
• Requirements are very clear and will NOT change (e.g., government tender with fixed
specs)
• The project is small and simple
• The technology is well-understood and proven
• Documentation is required (e.g., defense or aerospace projects)
• The client is not available for frequent feedback meetings
Waterfall is the WRONG choice when:
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
• Requirements are unclear or likely to change
• The project is large and complex
• Client needs to see progress regularly
• The team is using new, unfamiliar technology
Quick Comparison: Waterfall vs Agile (The Modern Alternative)
WATERFALL:
• All requirements gathered upfront
• One long phase then the next
• Client sees product only at end
• Hard to accommodate changes
• Good for: Government projects, construction software, defense systems
AGILE (what most modern companies use instead):
• Requirements evolve over time
• Work in small 2-week sprints
• Client sees working software every 2 weeks
• Easy to accommodate changes
• Good for: Mobile apps, e-commerce, startups, web products
Note: Most Pakistani IT companies have moved to Agile, but Waterfall is still important to
understand because many government and large enterprise projects still use it. Exam
questions frequently test both!
Summary Table: All 4 Topics
Topic Key Definition Real-Life Example Used
Business Analyst The translator between business Ahmed's Pizza App project
and IT teams
BA Requirements, process analysis, Hospital patient record system
Responsibilities documentation, testing,
stakeholder management
SDLC Structured 7-phase process for Food Delivery App (like
building software from idea to Foodpanda)
maintenance
Waterfall Model Sequential SDLC model where Hospital Management System in
each phase must complete before Lahore
next begins
Prepared by Claude | University Study Notes
Business Analysis Fundamentals — CS Notes
Exam Tips - Remember These!
1. BA = Bridge between business and IT (translator analogy works great in exams)
2. SDLC phases in order: Planning → Requirements → Design → Implementation → Testing
→ Deployment → Maintenance
3. Waterfall = SEQUENTIAL (one phase at a time, no going back)
4. Biggest weakness of Waterfall = Cannot handle changing requirements
5. BA does MOST work in Requirements phase of SDLC
6. BRD = Business Requirements Document (what business wants)
7. FRD = Functional Requirements Document (what system must do)
8. UAT = User Acceptance Testing (users test before final launch)
9. BABOK = Business Analysis Body of Knowledge (the BA bible)
10. Waterfall is best for: fixed requirements, small projects, government contracts
Prepared by Claude | University Study Notes