System Analysis Techniques for IT Pros, With a Worked Example

System analysis is the work of understanding how a business process runs today, deciding what it should do instead, and writing that down precisely enough that a team can build and test it. The techniques that do most of the work are requirements elicitation, process modelling in BPMN, data modelling, use cases or user stories, gap and feasibility analysis, and prototyping.

None of these is new, and that's the point. They're standardised, so a diagram you draw today can be read by another analyst years from now. Below, each technique gets a short explanation and its standard. Then all of them are applied to one problem: a leave-request workflow for an HRIS in Bangladesh.

Key takeaways

• Elicit before you model. Interviews, observation, document analysis and workshops each catch different requirements. Use at least two on any project.
• BPMN is the process standard. The current OMG version is BPMN 2.0.2, and the notation is also published as ISO/IEC 19510:2013.
• UML covers the system side. Use case, activity and class diagrams come from UML, currently version 2.5.1 at OMG.
• The IIBA BABOK Guide is the reference for the whole discipline. It groups business analysis tasks into six knowledge areas and describes 50 techniques.
• Prioritise with limits. DSDM's MoSCoW guidance suggests keeping Must Have work to no more than about 60% of the effort.
• Rules belong in data, not diagrams. In the worked example, leave entitlements come from the Bangladesh Labour Act and live in a policy table, not hard-coded in the workflow.

What system analysis covers, and where the standards come from

A system analyst sits between the people who run a process and the people who build software for it. The job isn't to collect a wish list. It's to find what the business needs and write it in forms both sides can check.

Three bodies of work define most of the vocabulary:

• BPMN (Business Process Model and Notation) is maintained by the Object Management Group. The current formal version is 2.0.2, published in January 2014. The notation was also adopted as ISO/IEC 19510:2013.
• UML (Unified Modeling Language) is also an OMG specification. The latest version is UML 2.5.1, released in December 2017. Use case, activity, class and sequence diagrams all come from UML.
• The BABOK Guide is the International Institute of Business Analysis's body of knowledge for the role. IIBA says it defines six knowledge areas, and its techniques chapter lists 50 techniques, numbered 10.1 to 10.50.

The six BABOK knowledge areas are Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition, and Solution Evaluation. Treat them as a checklist of what an engagement should cover. Solution Evaluation, the last one, is the step teams most often drop once a system goes live.

The core techniques at a glance

Requirements elicitation: use more than one method

Each elicitation method has a blind spot, so combining two or three is what makes the result trustworthy.

• Interviews are good for goals and pain points. Ask about outcomes ("what would a good month look like?") rather than features ("do you want a dashboard?").
• Observation finds the steps people forget to mention. Sit with the person who does the work, not their manager.
• Document analysis covers forms, spreadsheets and policy manuals. A column someone added to track exceptions is a requirement in disguise.
• Workshops surface conflicts early. If HR and Finance disagree about when a leave day counts as taken, you want to hear it in a room, not in user acceptance testing.

Write every requirement with a unique ID, a one-line statement, its source, a priority and acceptance criteria. For priority, MoSCoW (Must, Should, Could, Won't have this time) is the most common scheme. The DSDM guidance from the Agile Business Consortium adds a useful limit: keep Must Have work to typically no more than 60% of the effort, with around 20% as Could Haves for contingency. If everything is a Must, nothing is being prioritised.

Process modelling with BPMN: draw the As-Is before the To-Be

A BPMN diagram shows who does what, in what order, and where decisions branch. Five element types cover most diagrams: pools and lanes for participants, tasks for work, gateways for decisions and parallel paths, events for starts, ends, timers and messages, and sequence or message flows to connect them.

Model the current process first, even if everyone agrees it's broken. The gap between As-Is and To-Be is your scope. For tools, draw.io (diagrams.net) is fine for quick diagrams, and Camunda Modeler is the better choice if the process might later run on a BPMN engine.

Data flow and entity relationship models: follow the data

A data flow diagram shows what data enters a system, what transforms it, where it's stored and where it goes. It's the quickest way to find integration points and settle data ownership. An entity relationship diagram models what the system stores. Name each relationship and state its cardinality (one-to-one, one-to-many, many-to-many). Common mistakes are treating an attribute as an entity, forgetting the junction table behind a many-to-many relationship, and modelling only today's volumes and rules.

Use cases and user stories: describe behaviour, not screens

A use case describes how an actor uses the system to reach a goal. A complete one has an actor, preconditions, a main flow, alternative and exception flows, and postconditions.

User stories do the same job in smaller pieces: "As a [role], I want [action] so that [benefit]." Each needs testable acceptance criteria. I often write a use case for a complex flow, then split it into stories: the use case keeps exceptions in one place, the stories keep delivery small.

Gap and feasibility analysis: decide whether to build

Gap analysis compares the As-Is and To-Be across four areas: people (skills, capacity), process (steps, controls), technology (systems, integrations) and data (quality, ownership). Each gap becomes a line item with an owner.

Feasibility then asks five questions. Can it be built (technical)? Will people use it (operational)? Do the benefits justify the cost (economic)? Can it be delivered in time (schedule)? Does it comply with the law and contracts (legal)? For the legal question, check the current text of each law with counsel rather than an old summary.

Prototyping: validate with the people who'll use it

Rough wireframes are the cheapest way to catch a misunderstood requirement, because people react to the flow rather than the colours. Test them with daily users, not only the sponsor. The clerk who processes these requests every day will spot a missing field that a director never would.

Worked example: analysing a leave-request workflow for an HRIS

This is an illustrative scenario, not a client case. A mid-sized Bangladeshi company tracks leave on paper forms and a shared spreadsheet, and wants requests handled in its new HRIS.

Step 1: Elicit from four sources

Interview an employee, a line manager, the HR officer who keeps the spreadsheet, and someone from payroll. Watch the HR officer update balances. Collect the form, the spreadsheet and the policy. Typical findings:

• Managers approve on paper, but HR only learns about it days later, so balances in the spreadsheet are often stale.
• The policy manual and the spreadsheet use different rules for carrying leave forward.
• Payroll needs unpaid leave days before the salary run, and currently gets them by phone.

Step 2: Check the rules against the law

For employees covered as "workers" under the Bangladesh Labour Act 2006, the statute sets the baseline. Section 115 gives ten days of casual leave on full wages per calendar year, which can't be carried forward. Section 116 gives fourteen days of sick leave on full wages per calendar year, granted only on a registered medical practitioner's certificate, and also not carried forward. Section 117 gives adult workers in shops, commercial and industrial establishments and factories one day of annual leave for every eighteen days worked, after a year of continuous service, and unused annual leave does carry forward.

That's three different accrual and carry-forward rules before company policy is layered on. Have HR and legal confirm which staff the Act covers and whether later amendments affect these sections.

Step 3: Model As-Is and To-Be in BPMN

The As-Is diagram has three lanes (Employee, Manager, HR) and a gap between Manager and HR where the paper form sits in an out-tray. The To-Be has four lanes, adding Payroll, and looks like this in outline:

1. Start event: employee submits a request in the HRIS.
2. Service task: the system checks the balance for that leave type.
3. Exclusive gateway: if the balance is insufficient, the request is rejected with a reason, or offered as unpaid leave.
4. Exclusive gateway: if the type is sick leave over the company's threshold, a user task asks for the medical certificate.
5. User task: the line manager approves or rejects, with a timer boundary event that escalates to the next manager after a set number of working days.
6. Service task: on approval, the balance is updated and any unpaid days are sent to payroll.
7. End event: the employee is notified.

That timer and the payroll message flow are exactly the requirements the paper process was missing.

Step 4: Draw the data model

The ERD is small. Its main design choice is to keep entitlement rules in their own table, so a policy change is a data update rather than a code change:

CREATE TABLE leave_type (
  id INTEGER PRIMARY KEY,
  code TEXT NOT NULL UNIQUE,          -- 'CASUAL', 'SICK', 'ANNUAL', 'UNPAID'
  name TEXT NOT NULL
);

CREATE TABLE leave_policy (
  id INTEGER PRIMARY KEY,
  leave_type_id INTEGER NOT NULL REFERENCES leave_type(id),
  employee_category TEXT NOT NULL,    -- which staff group the rule applies to
  days_per_year REAL,                 -- fixed entitlement, e.g. casual or sick
  accrual_days_worked INTEGER,        -- e.g. one day per N days worked
  carry_forward INTEGER NOT NULL,     -- 0 or 1
  requires_document INTEGER NOT NULL, -- e.g. medical certificate
  effective_from TEXT NOT NULL
);

CREATE TABLE leave_request (
  id INTEGER PRIMARY KEY,
  employee_id INTEGER NOT NULL REFERENCES employee(id),
  leave_type_id INTEGER NOT NULL REFERENCES leave_type(id),
  start_date TEXT NOT NULL,
  end_date TEXT NOT NULL,
  status TEXT NOT NULL,               -- 'SUBMITTED', 'APPROVED', 'REJECTED', 'CANCELLED'
  approver_id INTEGER REFERENCES employee(id),
  decided_at TEXT
);

Don't skip the effective_from column. It matters more than it looks. When the law or company policy changes, you add a new policy row and keep the old one, so past balances can still be explained.

Step 5: Write the use case and stories

One use case, "Request leave", holds the main flow and the exceptions: insufficient balance, overlapping requests, public holidays inside the range, a manager who is on leave themselves. From it come stories such as:

• As an employee, I want to see my remaining balance for each leave type before I submit, so that I don't request leave I don't have.
• As a line manager, I want requests to escalate automatically if I don't respond, so that my team isn't left waiting while I'm away.

Step 6: Gap register and prototype

Every line in the gap register gets an owner: managers need HRIS logins and a short training session (people), the carry-forward rule in the policy manual must be reconciled with the spreadsheet (process and data), and the HRIS needs a payroll export (technology). Then put a wireframe of the request screen in front of three employees and one manager. If they can submit and approve a request without help, the requirements are probably right.

For the wider rollout around a workflow like this, including data migration and user training, see the HRIS implementation guide for Bangladesh. If you're choosing a platform, deploying Odoo on a VPS with PostgreSQL covers one open-source option that includes a leave module.

Where AI tools help in system analysis, and where they don't

Language models help with drafting: turning an interview transcript into a first requirements list, flagging vague words like "fast" in a specification, suggesting exception flows. What they can't do is know that your HR officer keeps a second spreadsheet, or that payroll moves its cut-off date in some months. Treat AI output as a draft for review, not a deliverable. I cover specific tools in AI tools for IT managers and practical automation patterns in automating business workflows with AI.

FAQ

What is the difference between a system analyst and a business analyst?

They overlap heavily. A business analyst focuses on needs, processes and requirements. A system analyst goes further into how the IT system meets them: data models, integrations, specifications. In small teams it's often one person.

Which version of BPMN should I use?

BPMN 2.0.2, the current formal version from the Object Management Group. BPMN is also published as the international standard ISO/IEC 19510:2013.

Do I need UML if I already use BPMN?

They answer different questions. BPMN describes business processes across people and organisations. UML describes software structure and behaviour, through use case, class and sequence diagrams. Most projects use BPMN for the process and a few UML diagrams for the system.

Is the BABOK Guide worth reading?

Yes, as a reference rather than a cover-to-cover read. The chapter describing its 50 techniques is the part I go back to most.

How many requirements should be Must Haves?

DSDM guidance suggests typically no more than 60% of the delivery effort. Above that, any estimate error or surprise puts the whole release at risk.

I work as a system analyst for a hospitality group and as an IT manager, based in Dhaka. If you'd like help scoping a workflow like this one, you can get in touch here.