System Analysis and Requirements Engineering
Domain 3 is about turning stakeholder needs into validated, traceable, testable requirements and about modelling them correctly. Case questions typically present an SRS excerpt or a data-flow diagram and ask what is wrong with it.
Elicitation and modelling
- Techniques: interviews, questionnaires, observation, document analysis, prototyping, and facilitated workshops (JAD), which compress elicitation by putting users, developers and a facilitator in one room.
- Structured analysis uses DFDs with four element types: process, data flow, data store and external entity. The data dictionary and mini-specs (structured English, decision tables) complete the model.
- Levelled DFD rules: every flow crossing a parent process boundary must appear in its child diagram; data cannot move directly between two external entities, or between two stores, without a process; no process may have output without input (a miracle) or input without output (a black hole).
Requirements engineering process
- Sequence: elicitation, analysis and negotiation, specification, validation, then management through traceability and change control.
- A good SRS is correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable and traceable. GB/T 9385-2008 aligns with IEEE 830 on this structure.
- Non-functional requirements must be quantified: throughput, response time, availability, security level, maintainability, portability.
- Prioritisation schemes include MoSCoW (must, should, could, won't) and Kano's basic, performance and excitement categories; a traceability matrix links each requirement forward to design and tests, and backward to its source.
Worked example
A level-0 diagram shows external entity Customer sending an order flow into process 1 Process Order, and process 1 writing to store Order. In the child diagram, the Customer flow must enter some process inside 1, and the flow to the Order store must leave some process inside 1. If the child shows the Customer flow entering process 1.1 and the store flow leaving 1.2, the diagram balances. If the child adds a flow from Customer to an entity outside process 1, the parent boundary has changed and must be redrawn.
Traps
- Treating a DFD as a flowchart: DFDs show data, not control or sequence.
- Drawing a control arrow between processes to show ordering.
- Accepting a requirement that says fast, user-friendly or where appropriate as verifiable.
- Confusing validation (did we build the right system?) with verification (did we build the system right?).