Course · IT & Analysis

Systems Analysis: APIs, Integrations and Data

The sequel to “Business and Systems Analysis from Scratch”: from requirements to the system. System requirements and measurable NFRs, HTTP and REST, status codes, JSON Schema and OpenAPI, synchronous and asynchronous integrations (queues, Kafka, retries, idempotency, outbox), UML sequence and state diagrams, normalization to 3NF and checking requirements with SQL — on one end-to-end case of a delivery service.

Course authors

PepelenCourse author

0 / 18 lessons done

New lesson →

From requirements to a system specification

From a user story to system requirements

7 exercises · Break a user story down into system requirements, each naming a component, an action, data and a condition, without forgetting what happens on failure.

Non-functional requirements you can measure

7 exercises · Write a system NFR as a measurable metric — a response-time percentile under a given load, availability as a percentage and as minutes of downtime — and map it to an ISO/IEC 25010 quality characteristic.

System boundaries: the context diagram and integrations

7 exercises · Draw a system's context diagram — what is inside, who and what is outside, what data goes along each arrow and how — and build an integration register from it.

How systems talk: HTTP and REST

HTTP requests and REST resources through a designer's eyes

7 exercises · Break an HTTP request and response down into their parts and design the REST resource addresses for the case: plural nouns, hierarchy, path and query parameters.

HTTP methods: safety, idempotency, PUT vs PATCH

7 exercises · Choose the HTTP method for an operation by its properties — safe, idempotent — and explain the difference between POST, PUT and PATCH using an order.

Status codes: choose a code the client will understand

7 exercises · Choose a status code for each outcome of an endpoint — success, request error, no permission, state conflict, overload, failure — and describe the error body so that the client can react to it.

Data on the wire: JSON, JSON Schema, OpenAPI

JSON and JSON Schema: the shape of data and its rules

7 exercises · Read a JSON order object, choose types for money, dates and statuses, and describe the object's rules in JSON Schema so that the server validates the request automatically.

OpenAPI: reading and writing an endpoint contract

8 exercises · Read an endpoint description in OpenAPI 3.1 — path, parameters, request body, responses with status codes and schemas — and write such a description for a new Romashka endpoint.

Lists and API evolution: pagination, filters, versions

7 exercises · Design a list endpoint with filters, sorting and pagination, and tell a contract change that is compatible with clients from a breaking one that requires a new version.

Integrations: synchronous, asynchronous, reliable

Synchronous or asynchronous: choosing an integration style

7 exercises · Choose an integration style — a synchronous request, an event via a broker, a webhook, polling or a batch export — based on whether you need the answer right away, what happens when the receiver is unavailable, and how many receivers the data has.

Message brokers: queue, topic, Kafka and RabbitMQ

8 exercises · Design an exchange through a broker: choose a queue or a topic, a partition key that keeps events in order, and the contents of the event, bearing in mind that at-least-once delivery produces duplicates.

Failures: timeouts, retries and idempotency

8 exercises · Describe in the specification how an integration behaves on failures: the timeout, which errors to retry and with what delays, the idempotency key, discarding duplicates, the dead letter queue and the outbox.

Behavior and data models: UML and normalization

Sequence diagram: who calls whom, and in what order

7 exercises · Read and draw a sequence diagram for the “place and pay for an order” scenario: participants, synchronous and asynchronous messages, replies and alternative branches (alt).

State diagram: the order lifecycle

7 exercises · Describe the order lifecycle with a state diagram — states, transitions, events and guards — and derive API rules from it: what is allowed in which status and what to return for a forbidden transition.

Data model: normalization to 3NF

7 exercises · Bring a flat orders table to third normal form — find 1NF, 2NF and 3NF violations and split the data into tables with keys — and tell duplication apart from a historical value.

SQL for analysts and the end-to-end case

Joining several tables and JOIN traps

7 exercises · Join three tables of Romashka's model and predict the result: find rows without a match with LEFT JOIN … IS NULL and avoid row multiplication in a one-to-many join.

Checking a requirement against the data

7 exercises · Turn a requirement or a business rule into an SQL check — “the query must return zero rows” or “the share is not below the threshold” — and read the result as confirmation or violation of the requirement.

End-to-end case: from a user story to an integration specification

7 exercises · From a Romashka user story, put together a mini-specification — system requirements, a measurable NFR, an endpoint contract, an event, a call sequence, the affected statuses and an SQL check — and self-check it against the course checklist.