IAI SP1 common mistakes
IAI SP1 · Understand the traps and how to avoid them.
Answering framework questions by describing generic 'systems engineering best practice' instead of naming the specific SP1 framework stages, inputs, outputs, and decision gates, and using the framework's own vocabulary for artefacts and reviews.
Candidates skim the framework chapter once, then rely on prior industrial experience; the exam's framework questions are precise about stage boundaries and artefact names, so a plausible generic answer sounds right but misses the marking points.
What to do instead
Build a one-page map of the framework: each stage, its purpose, entry/exit criteria, key artefacts, and who approves. For every artefact write one sentence on what it contains and which stage produces it. Practise restating a scenario in framework vocabulary before answering.
Treating 'holistic' as a synonym for 'consider everything' and writing broad answers that list many factors without identifying system boundary, emergent behaviour, or the interactions between elements.
Systems thinking vocabulary is familiar from everyday speech, so candidates produce expansive prose that never demonstrates boundary judgement or emergence; the exam rewards showing how parts interact, not enumerating parts.
What to do instead
For each scenario, explicitly state the boundary and what is excluded, then name at least one emergent property and one interaction that produces it. Practise the distinction between analysis (decompose) and synthesis (recombine) and show both in answers.
Listing stakeholders as a flat roster of job titles and then jumping straight to requirements, without recording each stakeholder's concerns, influence, interest, or how conflicting concerns were reconciled.
Stakeholder tables feel like administrative overhead, so candidates produce a list and move on; the exam tests whether engagement outputs actually feed the requirements and the context description.
What to do instead
Use a stakeholder table with columns for concern, influence, interest, engagement method, and where the concern is addressed downstream. Always show at least one conflict and its resolution or escalation route, and trace each concern to a requirement or a documented exclusion.
Writing requirements that mix several needs in one sentence, embed design solutions ('the system shall use a relational database'), or use unverifiable words such as 'fast', 'user-friendly', or 'robust'.
Candidates draft requirements the way they write prose at work, and solution-embedding feels helpful because it shows expertise; without a checking habit, these defects survive into the exam answer.
What to do instead
Apply a written checklist to every requirement: single thought, no design, verifiable, necessary, unambiguous, and traceable to a source. Rewrite vague qualifiers into measurable thresholds with conditions and tolerances, and split compound sentences before submitting.
Presenting an architecture as a single diagram with no rationale, no view of concerns such as function, information, and deployment, and no record of the alternatives that were rejected.
Candidates equate architecture with a block diagram because that is what they produce at work; the exam asks for the reasoning behind structure, which a diagram alone cannot show.
What to do instead
For every architecture answer provide the view, the concern it addresses, the key decisions, and the rejected alternatives with reasons. Practise producing at least two consistent views of the same system and stating how they map onto each other.
Drawing a model with no legend, no defined notation, and no statement of what question the model answers, then describing the diagram in prose instead of using the model to derive a conclusion.
Candidates learn notation superficially and focus on producing a picture; exam questions on modelling reward correct syntax plus interpretation, and a picture without semantics earns little.
What to do instead
Before drawing, write the question the model must answer and the notation standard used. Label every element, include a legend, and finish with two or three findings the model reveals that the prose alone would not.
Performing trade-off evaluation by scoring options on invented criteria with no weights, no justification for scores, and no sensitivity check, then declaring a single winner as if the result were objective.
Weighted matrices look rigorous and are easy to fill in, so candidates produce numbers without defending them; the exam tests judgement about criteria derivation and the limits of the method.
What to do instead
Derive criteria from stakeholder concerns and requirements, state weights and their source, justify each score with evidence, and test whether plausible changes in weights alter the ranking. Report the recommendation with its assumptions and residual risk, not just the top score.
Using verification and validation interchangeably, and describing integration as 'putting the parts together' without an integration strategy, interface checks, or a stated sequence and its rationale.
The terms are conflated in everyday engineering speech, and integration is treated as an assembly task rather than a planned activity with its own risks; candidates therefore lose the marks attached to the distinction.
What to do instead
Memorise the distinction as 'built right' versus 'right system' and always state the object, method, and evidence for each. For integration, name the strategy (big bang, incremental, top-down, bottom-up), justify it against interface risk, and specify interface verification before assembly.
Describing lifecycle as a list of phase names in sequence, ignoring iteration, decision gates, configuration control, and how changes propagate back into earlier artefacts.
Candidates recall a waterfall picture and reproduce it; the exam tests whether they understand lifecycle as managed evolution with baselines and change impact, not as a calendar.
What to do instead
For each lifecycle question, state the model chosen, why it fits the risk and uncertainty, where iteration occurs, what baselines exist at each gate, and how a change is assessed and approved. Include one worked example of a change propagating through requirements, architecture, and tests.
Answering governance and professional practice questions with generalities about 'good communication' or 'following standards', without naming the applicable standard, the review type, the ethical dilemma, or the escalation path.
Professional practice feels like common sense, so candidates write soft answers; the exam expects concrete references to standards, review and audit mechanisms, competence boundaries, and named obligations.
What to do instead
Prepare a short list of the standards and review types relevant to the syllabus with one line each on when they apply. For ethics or conflict scenarios, state the competing obligations, the affected parties, the disclosure or escalation route, and the record kept.