2IRR00 · Topic 02
Development Processes & Requirements
Waterfall, V-model, Spiral, Agile/Scrum, requirement types, SMART
Development processes (Waterfall, V-Model, Spiral, Prototyping)
A software development process (SDLC) is a description for planning and managing development so it fulfils the customer's requirements. Models differ mainly in what to do when and how.
Waterfall: traditional, linear phases; feasible for clear/static requirements; clear phase distinction is unrealistic but good for documentation; assumes frozen requirements and delivers the whole system at once.
V-Model: an EXTENSION of Waterfall with a focus on testing and validation (each development phase has a matching test phase). Still a fixed linear process. Widely used in SAFETY-CRITICAL domains.
Prototyping: build a prototype for feedback and refine iteratively; often integrated into other processes. Faster customer feedback but risks excessive prototype testing, changing requirements, harder budgeting.
Spiral: integrates previous models; each loop = a waterfall producing a prototype; emphasises managing COST and RISK; number of loops varies. Powerful but complex and expensive.
Properties of the V-Model:
✔ Extension of the Waterfall with a focus on testing
✔ Assumes detailed specifications are fixed at the beginning
✔ Follows a fixed linear process
�’ NOT particularly useful for app prototypes
V-Model > Scrum for safety-critical because such domains:
✔ require extensive testing & documentation for audits
✔ often have well-defined requirements specified in regulations
�’ do NOT require flexibility to constant change (that's agile)
�’ customer involvement is not the reasonCommon mistakes
- Saying the V-Model is for rapid prototyping — it is the opposite (heavy specs/testing up front).
- Calling the V-Model a replacement for Waterfall; it is an extension of it.
Exam tips
- V-Model = Waterfall + testing emphasis + safety-critical + frozen specs + linear. Memorise these.
- Spiral disadvantages (commonly asked open Q): complex, expensive/resource-intensive, hard risk/time management.
- Traditional weaknesses: slow/inflexible, high cost, limited customer involvement.
Development processes (Waterfall, V-Model, Spiral, Prototyping) practice
2 questions
Agile & Scrum
Agile is a mindset (the Agile Manifesto) favouring flexibility and collaboration; Scrum is a concrete agile framework built around fixed-length Sprints that each produce a usable increment.
Agile Manifesto — four core values (X over Y, but Y is NOT ignored): Individuals & interactions over processes & tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.
Agile ≠ no process/documentation/planning. It is about the mindset.
Scrum artifacts: Product Goal (long-term objective), Product Backlog (ordered list of improvements), Sprint Backlog (items + plan for one Sprint), Increment (usable software each Sprint).
Scrum events: Sprint (≤1 month, the container), Sprint Planning (≤8h), Daily Scrum (15 min), Sprint Review (≤4h, show to customer), Sprint Retrospective (≤3h, improve process).
Scrum roles: Product Owner (owns the backlog), Scrum Master (ensures Scrum is implemented), Developers (create the increment).
Definition of Ready: when a backlog item is ready to be worked on. Definition of Done: criteria for an item to count as complete (reviewed, tested, CI passed, documented).
Common mistakes
- Reading the manifesto values as 'ignore the right-hand side'. The right side still has value.
- Confusing Definition of Ready (can we start?) with Definition of Done (is it finished?).
Exam tips
- MCQ trap: 'Processes and tools over individuals' is the REVERSED (wrong) value.
- Know the 3 roles, the 5 events with their purpose, and the artifacts.
- A 'done' backlog item results in an increment.
Agile & Scrum practice
2 questions
Requirements & SMART
A requirement is a documented condition/capability a system must meet. The three high-level types are Functional, Quality (non-functional), and Constraint.
Functional: a behaviour/function the system offers — 'the system must allow users to log in'.
Quality / non-functional: a quality of the system — 'the system must respond to a login within 1 second'.
Constraint: a fixed limit that cannot be changed — 'the system must be implemented using PHP 5' / 'must fulfil ISO 26262'.
Document with a template: tabular overview (ID, natural-language requirement, priority), separate tables per category.
MoSCoW prioritisation: Must / Should / Could / Won't.
SMART: Specific, Measurable, Achievable, Relevant (realistic), Traceable.
Conditions: 'as soon as' = temporal, 'if' = logical; avoid the ambiguous 'when'.
"If an order is placed, the system must send a
confirmation mail." → Functional
"The website should load within 1 second for at
most 1000 simultaneous requests." → Quality
"The system must allow customers to send feedback
via a contact form." → Functional
"The system must use PHP 5 in the backend." → Constraint
"The system must fulfil the standard ISO 26262." → ConstraintCommon mistakes
- Underspecifying quality requirements — always state the conditions (CPU, users, network) under which the quality must hold.
- Combining/mixing requirements: 'and'/'or' connectors are a warning sign; keep functional, quality, constraint separate.
- Using vague terms (few/many) instead of concrete numbers; mixing problem with solution.
Exam tips
- Performance/time/load → Quality. A named technology/standard → Constraint. A behaviour the user/system does → Functional.
- Negative functional requirements ('the system won't allow X', 'the system shall not do Y') are STILL Functional requirements — they describe system behaviour, just prohibiting it.
- Match questions penalise wrong selections (-0.5), so don't guess if unsure.
- MoSCoW keyword set is Must/Should/Could/Won't (e.g. 'May' is NOT a MoSCoW keyword; 'Could' is).
Requirements & SMART practice
1 questions