UML: Choose the Right System View Before You Start Drawing

01

Before introducing UML, the article stresses the importance of requirement engineering because UML is mainly a tool for expressing the results of analysis and design.

Requirement engineering is not just asking "what features?"; in real projects users often speak unclearly, omit details, contradict themselves, or change ideas frequently. Therefore the process must make the true user needs clear, analyze them, document them, verify them, and manage changes.

Exam‑style definition: requirement engineering is the process of acquiring, analyzing, specifying, validating, and managing software requirements.

02

Requirement acquisition gathers needs from users, business staff, existing systems, documents, market, and regulations using interviews, questionnaires, observation, meetings, prototypes, document analysis, and business‑process analysis. For an e‑commerce system you would interview operations, customer service, warehouse, finance, and users, review the current order flow, observe refund handling, and analyse pain points.

03

Requirement analysis classifies, clarifies, models, and prioritises the collected needs, uncovering conflicts and omissions. Example user statements like "ordering must be fast" or "inventory must be accurate" are broken down into concrete questions about speed, accuracy, coupon rules, report audiences, mandatory vs optional features, and potential conflicts.

04

Requirement specification writes the clarified requirements into a formal Software Requirements Specification (SRS) document, covering functional, non‑functional, interface, data, constraints, and acceptance criteria. Written specifications provide a common baseline for all stakeholders.

05

Requirement validation checks correctness, completeness, consistency, feasibility, and testability. Vague statements like "the system must be fast" are untestable; rewriting them as "the order API must return within 1 second under normal load" makes them verifiable.

06

Requirement management controls changes, tracks requirements, manages versions, performs impact analysis, and maintains baselines. When a stakeholder adds a new approval step, the team analyses impact on modules, schedule, testing, database, version plan, and decides who approves the change.

07

Requirements are split into functional (what the system does) and non‑functional (how well it does it). Functional examples: login, product search, order creation, payment, refund. Non‑functional examples: performance (order API < 1 s), availability (99.9% uptime), security (authentication and encryption), maintainability (low coupling), extensibility (add new promotion rules).

08

UML (Unified Modeling Language) is a set of diagram types that describe a system from different perspectives. The article advises not to ask "how to draw this diagram?" first, but "which side of the system do I want to express?" UML is divided into structural diagrams (static view) and behavioural diagrams (dynamic view).

09

Use‑case diagram answers who uses the system and what functions are provided. Core elements: actors, use cases, system boundary, relationships. Example: users can login, browse, order, pay; administrators can manage products and handle refunds.

10

Class diagram shows the static structure: classes, attributes, methods, and relationships (association, aggregation, composition, generalisation, dependency, implementation). E‑commerce example classes: User, Order, OrderItem, Product, Payment, with relationships such as a user having many orders, an order containing many items, each item linked to a product, and an order linked to a payment.

11

Sequence diagram (time‑order diagram) depicts how objects interact over time. Core elements: objects, lifelines, messages, activation, and temporal order. Example: a user submits an order, the order service checks inventory, creates the order, calls the payment service, and sends a Kafka message.

12

Activity diagram describes business processes, similar to flowcharts, showing steps, decisions, branches, parallel flows, and control flow. Example e‑commerce order flow: select product → add to cart → submit order → check inventory → if stock sufficient, proceed to payment; otherwise, show failure.

13

State diagram shows an object's possible states and transitions. Example order states: Pending Payment → Paid → Shipped → Completed; or Pending Payment → Cancelled; or Paid → Refund In Process → Refunded.

14

Component diagram focuses on software components and their dependencies. Example components: Order Service, Inventory Service, Payment Service, User Service, Messaging Component, Authentication Component.

15

Deployment diagram shows where software artifacts are physically deployed on hardware nodes. Example nodes: Web server, application server, database server, Redis server, Kafka cluster.

16

The same e‑commerce system can be described by different UML diagrams depending on the aspect you want to highlight: use‑case (who uses it and what functions), class (static structure), sequence (temporal interaction), activity (process flow), state (lifecycle), component (software dependencies), deployment (physical placement). The key question is "Which side of the system am I trying to express?" not "Which diagram is best?"

17

A summary table maps system aspects to diagram types: who uses the system → use‑case; classes, attributes, methods → class; time‑ordered interaction → sequence; business process steps → activity; object state changes → state; software components and dependencies → component; hardware nodes for deployment → deployment.

Self‑test

What are the five main activities of requirement engineering? Answer: acquisition, analysis, specification, validation, management.

What methods are common for requirement acquisition? Answer: interview, questionnaire, observation, meeting, prototype, document analysis, business‑process analysis.

What does requirement analysis do? Answer: classifies, clarifies, models, prioritises, and discovers conflicts and omissions.

What does SRS stand for? Answer: Software Requirements Specification.

What is the difference between functional and non‑functional requirements? Answer: functional describes what the system does; non‑functional describes how well it does it (performance, security, availability, reliability, etc.).

What does a use‑case diagram describe? Answer: the relationship between actors and system functions for capturing functional requirements.

What does a class diagram describe? Answer: the static structure of the system, including classes, attributes, methods, and relationships.

What does a sequence diagram describe? Answer: the interaction of objects over time via message passing.

What is the difference between activity and state diagrams? Answer: activity diagrams describe business processes; state diagrams describe an object's states and transitions.

What is the difference between component and deployment diagrams? Answer: component diagrams describe software components and their dependencies; deployment diagrams describe where software is deployed on hardware nodes.