Introduction to System Analysis

Analysis vs Design vs Implementation

18 min Lesson 7 of 10

Analysis vs Design vs Implementation

Three words — analysis, design, and implementation — appear on every project plan, yet they are routinely confused, collapsed into one another, or skipped altogether. Understanding exactly where one ends and the next begins is one of the most practical skills a systems analyst can have. Get it wrong and teams build the wrong thing perfectly; get it right and every deliverable connects logically to the one before it.

The simplest way to remember the distinction is through two questions:

Analysis answers: WHAT does the system need to do?
Design answers: HOW will the system do it?
Implementation answers: HOW do we build and deliver it?

These are not phases on a Gantt chart — they are types of thinking. Even in an Agile sprint, all three happen; the difference is the scope and the audience for each.

The three phases of a system project: Analysis (WHAT), Design (HOW it will work), and Implementation (HOW it is built).

Analysis: Defining the WHAT

Analysis is entirely about understanding the problem before thinking about any solution technology. The analyst interviews stakeholders, documents workflows, uncovers constraints, and produces a precise statement of what the new or changed system must accomplish. The key output is a Requirements Document — often paired with Use Cases or User Stories.

Consider a clinic booking system. During analysis the analyst asks: Who books appointments? Can a patient cancel online? How far in advance can a slot be reserved? What happens when a doctor is absent? None of these questions involve databases, programming languages, or cloud providers. They are purely about behaviour. A good requirement statement from this phase looks like:

REQ-14: The system shall allow a patient to cancel a confirmed appointment
up to 2 hours before the scheduled time. A cancellation notification
shall be sent to both the patient and the assigned doctor within 60 seconds.

Notice that REQ-14 says nothing about how cancellations are stored, which email service is used, or what the API endpoint looks like. That is deliberate — it is the analyst's job to keep requirements technology-neutral so that designers have freedom to make the best HOW decisions.

Key idea: A requirement that mentions a specific technology (e.g., "the system shall use PostgreSQL to store appointments") is a design decision smuggled into analysis. Flag it, challenge it, and rewrite it in behavioural terms unless there is a genuine business constraint that mandates the technology.

Design: Defining the HOW

Design picks up the requirements document and asks: given these constraints and goals, how shall we construct a system that satisfies them? This phase produces architecture diagrams, database schemas, API contracts, UI wireframes, and component specifications. Design is where technology choices are made — and justified.

For the same clinic booking system, the design team might decide on a three-tier web application, choose a relational database, define a POST /appointments/{id}/cancel REST endpoint, and sketch the cancellation email template. Each decision should trace back to at least one requirement.

A useful mental test: if a decision cannot be traced to a requirement, it is either a reasonable default (document it), an unnecessary gold-plating (question it), or a hidden requirement that was missed in analysis (surface it and add it formally).

Implementation: Building and Delivering

Implementation is where developers write code, DBAs create schemas, testers write test scripts, and DevOps engineers configure pipelines. The input is the design specification; the output is a running, tested system. Implementation discovers omissions in design and design discovers omissions in analysis — which is why feedback loops are essential.

In a logistics firm deploying a new parcel-tracking module, the implementation team might discover mid-sprint that the design assumed a single time zone, but the requirements clearly stated the system would operate across three countries. This is a design defect triggered by analysis incompleteness. The correct response is to pause, revisit the analysis artefact, correct the requirement, update the design, and then continue implementation — not silently patch the code.

Where Analysis Ends and Design Begins

The boundary is often described as the line between logical models and physical models:

Logical (Analysis): A data flow diagram showing that "customer order data flows to the fulfilment process" — no tables, no keys, no programming language.
Physical (Design): An entity–relationship diagram specifying the orders table, its columns, foreign keys, and indexes.

When an analyst draws a box labelled "Order Processing" and an arrow labelled "Order Data", that is analysis. When a designer draws a box labelled OrderService with a method signature processOrder(orderId: UUID): OrderResult, that is design.

Left: Logical analysis artefacts (Data Flow Diagram) — no technology. Right: Physical design artefacts (component and schema) — technology decisions made.

Why the Boundary Matters in Practice

When teams blur the boundary, several predictable problems emerge:

Premature technology lock-in: An analyst who specifies "the system shall use React and a microservices architecture" has eliminated design options before the team has fully understood the problem. If requirements change, the technology constraint may now be an obstacle.
Requirements inflation: Developers who jump to implementation before analysis is solid spend weeks building features only to discover the stakeholder wanted something different. Rework at implementation stage costs five to ten times more than rework at analysis stage.
Missing traceability: When design decisions cannot be traced to requirements, auditors, testers, and new team members cannot verify that the system does what it was supposed to do.

Best practice: In every project status meeting, ask "Are we in analysis, design, or implementation mode right now?" When team members give different answers for the same agenda item, you have found a coordination gap worth surfacing.

Overlap Is Normal — Confusion Is Not

In practice, especially on Agile projects, the phases overlap. A team might be in analysis for the next feature while implementing the current one. That is healthy. What is harmful is confusing the type of question being answered. A design review meeting should not be debating whether the cancellation feature is needed (analysis); it should be debating whether to use a soft-delete flag or a separate cancellation table (design).

For an online store adding a "buy now, pay later" payment option, the analyst must first establish: which users are eligible, what the maximum order value is, which countries are supported, how failed payments are handled. Only when those questions have signed-off answers does it make sense for the design team to evaluate payment gateway APIs, schema changes to the orders table, and UI flows.

Common pitfall: Calling a meeting "requirements gathering" but spending the majority of the time debating technology choices wastes analyst bandwidth and often produces poorly thought-out requirements. Reserve technology debates for the design phase, where the full picture of what is needed is already established.

Key Takeaways

Analysis = WHAT; Design = HOW it will work; Implementation = HOW it is built.
Requirements must be technology-neutral; design artefacts are technology-specific.
The logical-to-physical transition marks the analysis-to-design boundary.
Every design decision should trace back to at least one requirement.
Rework caught in analysis is cheap; rework caught in implementation is expensive.
The phases overlap in Agile contexts, but the type of question being answered must always be clear.