Once requirements are elicited, which models are used to document them, and what does each one capture?
Three modelling views — a system component diagram (components + interfaces), a use case diagram (actors + functions) and a business object model (business objects + relationships) — plus screen flows, the screens themselves and the outputs, with anything left over listed and referenced explicitly.
* Each model answers a different question about the same system, which is why one alone is never enough. *
Each model answers a different question about the same system, which is why one alone is never enough:
| Model | Captures | The question it answers |
|---|---|---|
| System component diagram | Components and their interfaces | What parts does the system have, and where do they meet? |
| Use case diagram | Actors and functions | Who uses it, and what can each of them do? |
| Business object model | Business objects and their relationships | What things does the business deal in, and how do they relate? |
| Screen flow | Screens and the navigation between them | How does a user move through the system? |
| Screen | One screen and a description of its content | What is on this page, and what does each field mean? |
| Output / result | Printouts, PDFs, generated documents | What does the system hand back, and in what form? |
Structure is the point: a component diagram makes an interface — and therefore a trust boundary — visible in a way a paragraph of prose never does, and a business object model exposes a relationship ("one customer, many addresses") that stakeholders assume but never state.
Two habits keep the set usable. First, anything that does not fit a model still has to be written down — the leftover requirements get listed explicitly rather than lost. Second, referencing and clear description are mandatory: every screen, component and object needs an unambiguous identifier so that a defect report, a test case and a requirement can all point at the same thing and be known to mean it.
Tip: If a requirement cannot be pointed at by a reference, it cannot be tested, traced or signed off — and in practice it will be implemented by whoever remembers it best.
Go deeper:
Use case diagram (Wikipedia) — actors and functions, with the notation spelled out.- Component diagram (Wikipedia) — components and the interfaces where they meet.
Domain model (Wikipedia) — the business object model under its more common name.