Preface (readership, history), Introduction, Glossary, User Requirements, System Architecture, System Requirements Specification, System Models, System Evolution, Appendices, Index. Different readers need different sections.
Advantages: expressive, understood by all, no special training. Disadvantages: ambiguity, over-flexibility, no modularity, mixed levels. Guidelines: standard format, consistent shall/should, highlight key parts, avoid jargon, add a rationale.
Following a requirement from origin through design, implementation and testing, and seeing links between requirements. Important for impact assessment, completeness checks and test coverage.
Store requirements, manage versions, change control, traceability links and reports. Functions: unique IDs, attributes (priority/status/source), linking, change workflows, query/reporting.
Shows interactions between the system and external actors. Elements: actors (stick figures), use cases (ellipses), links between them. Defines system boundaries and high-level functionality.
Class diagram: static structure - classes, attributes, operations, associations; for the object model. Sequence diagram: dynamic message sequence for a scenario; for a specific interaction/use case.
States (rounded rectangles), transitions (arrows labelled with events), actions/guards. Shows how an object reacts to events over time - its state and what changes it.
Models are the primary artefacts; code is generated. For: higher abstraction, platform independence, fewer errors. Against: models may not suit implementation; platform independence only helps long-lived systems; other concerns (requirements, security, testing) often matter more.