Specifications & Modeling
An analyst turns vague wishes into artifacts the team can build from without guessing. This topic is about three languages of that formalization: text (requirements and specifications), pictures (UML diagrams), and strict contracts (SOAP/XML, still alive in the enterprise). A good requirement is unambiguous, atomic, and testable; a good diagram saves a page of prose; a good contract stops two systems from disagreeing on a format.
We cover how to write a requirement that generates no developer questions; how a user story differs from a use case and from an SRS; when a diagram beats text and which one to draw; and why banks and government still hold on to SOAP. Along the way we name the interview traps: "a non-functional requirement is a formality", splitting a story by architectural layer, confusing aggregation with composition, and believing XSD describes JSON. The full map is in the layers below.
Topic map
- Specifications — functional and non-functional requirements, the marks of a good requirement, user stories and acceptance criteria, use cases, the SRS structure, traceability, MoSCoW prioritization, ТЗ/ЧТЗ.
- UML diagrams — which diagrams an analyst draws and when: use-case, class, sequence, activity, state, component/deployment; ER for data; BPMN for processes; when a picture beats prose.
- SOAP & XML — the SOAP envelope, the WSDL contract, XSD validation, namespaces, SOAP versus REST, XML versus JSON, and where SOAP still fits.
Common traps
| Mistake | Consequence |
|---|---|
| Writing "the system must be fast" | The requirement is untestable; QA has nothing to check and the fight over "fast" leaks into production |
| Treating non-functional requirements as a formality | Missed load limits and SLAs surface as an outage under peak |
| Splitting a user story by layer (UI → backend → DB) | No slice delivers value or can be tested on its own |
| Confusing a user story, a use case, and an SRS | The wrong level of detail: either too coarse or a 200-page document |
| Confusing aggregation (hollow diamond) and composition (filled) | A wrong deletion model: parts either outlive the whole or die with it |
Calling XSD a JSON schema, or REST a protocol like SOAP | The wrong validation tool and the wrong integration contract |
Interview relevance
The topic is asked to check whether you can formalize a system so a developer, a QA, and the customer all understand it. A candidate who phrases a requirement as an "observable and measurable outcome" and draws the right diagram for the task immediately gets ahead of one reciting templates from memory.
Typical checks:
- The difference between functional and non-functional requirements and the marks of a good one (unambiguous, atomic, testable).
- How a user story differs from a use case, and when you write an SRS or ТЗ/ЧТЗ instead of a backlog.
- Which UML diagrams an analyst draws, and when a diagram is clearer than text.
- The make-up of a SOAP message, the roles of WSDL and XSD, and when SOAP is still preferred over REST.
Common wrong answer: "a requirement is when you write down what the system should do". In reality a requirement is useless until you can verify it: with no measurable acceptance criterion, "should" turns into an argument at the demo instead of a green test.