The waterfall model is best suited to projects where:

Requirements are stable and fully known upfront

Requirements change constantly throughout development

The team has no access to the customer

The spiral model is distinguished from a simple iterative model chiefly by its:

Explicit risk analysis at every loop of the spiral

Complete absence of any planning

Requiring exactly one iteration only

Forbidding any customer involvement

Test-driven development, a practice associated with Extreme Programming, means:

Writing the test for a piece of functionality before writing the code that implements it

Testing only after the entire product is complete

Having the customer write all the code

A use case in requirements modelling is best described as:

A named interaction between an actor and the system, described via a main success scenario and its alternative flows

A finished, tested piece of source code

A statement of a non-functional performance constraint only

A diagram with no textual description

Which of the following are true of Agile software development, as distinct from a rigid waterfall process? (More than one option may be correct.)

It favours working software over comprehensive documentation

It favours responding to change over following a rigid plan

It typically delivers in short, iterative cycles rather than one long sequential pass

It favours working software over comprehensive documentation

It favours responding to change over following a rigid plan

It has no defined roles, ceremonies or engineering practices at all

It typically delivers in short, iterative cycles rather than one long sequential pass

Software Process Models and Requirements Engineering

GATE CS has no Software Engineering section at all — its ten official sections run from Discrete Mathematics to Computer Networks with nothing in between on process, requirements, design, quality, estimation, testing or configuration management. So all of Unit 6 is new ground, even for a GATE candidate. This chapter opens it with process models (including the Agile family) and requirements engineering.

The Generic Process Model: Framework Activities, Task Sets and Patterns

Every software process, whatever specific model it follows, is built from the same generic framework activities: COMMUNICATION (with the customer, to understand the problem), PLANNING (a roadmap), MODELING (analysis and design), CONSTRUCTION (code and test) and DEPLOYMENT (delivery, feedback). A task set defines the actual work items, milestones and deliverables that realise one framework activity for a given project, and a process pattern is a reusable description of a process-related problem and its solution within one context — the standard vocabulary for describing software processes at a level general enough to apply across specific models.

Prescriptive process models
Model	Shape and when it fits
Waterfall	Strictly sequential phases (requirements → design → implementation → testing → maintenance), each completed before the next begins — fits well only when requirements are stable and fully known upfront, since going back a phase is expensive.
Incremental model	Delivers the system in a series of usable increments, each adding functionality — gets a working (partial) product to the customer early, unlike waterfall.
Spiral model	Combines iterative development with EXPLICIT risk analysis at every loop of the spiral — chosen specifically for large, high-risk projects where identifying and managing risk early is the priority.
Component-based development	Assembles a system largely from pre-existing, reusable software components rather than building everything from scratch — reduces cost and time when suitable components already exist.

Agile Process Models

Extreme Programming (XP): emphasises very short release cycles, PAIR PROGRAMMING (two developers at one workstation), TEST-DRIVEN DEVELOPMENT (write the test before the code it tests), continuous integration, and 'the customer is always available' — a small, close-knit team's answer to volatile requirements.
Scrum: organises work into fixed-length SPRINTS (typically 2–4 weeks) drawing from a prioritised PRODUCT BACKLOG; daily brief stand-up meetings (the daily scrum) surface blockers early; three defined roles — the Product Owner (owns the backlog and priorities), the Scrum Master (facilitates the process and removes impediments) and the Development Team (self-organising, delivers the increment).
Other named agile models: Adaptive Software Development emphasises speculate-collaborate-learn cycles over rigid planning; the Dynamic System Development Model provides a full lifecycle framework built around fixed time and cost with variable features; Feature Driven Development plans and builds around a list of client-valued FEATURES rather than tasks; Crystal is a family of lightweight methods scaled to team size and project criticality rather than one fixed process. All share the Agile Manifesto's core preference: individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a rigid plan.

⚠️ Agile is not 'no process' — it is a different set of priorities

A common misreading is that agile methods have no discipline or planning at all. In fact Scrum has fixed ceremonies (sprint planning, daily scrum, sprint review, retrospective) and defined roles, and XP has strict engineering practices (TDD, pair programming, continuous integration) — agile trades a heavyweight, sequential, document-driven process for a lightweight, iterative, working-software-driven one, not discipline for chaos.

Functional and Non-Functional Requirements, Use Cases and the SRS

A functional requirement states WHAT the system must do (a specific behaviour or feature — 'the system shall allow a user to reset their password'); a non-functional requirement states a QUALITY or CONSTRAINT the system must satisfy while doing it (performance, security, usability, reliability, portability — 'the system shall respond within 2 seconds under normal load'). Requirements elicitation gathers these from stakeholders (interviews, questionnaires, observation, prototyping); requirements analysis and modelling organises and refines them (often via USE CASES — a named interaction between an ACTOR and the system, described by a main success scenario and its alternative/exception flows); requirements review checks the gathered set for completeness, consistency and testability before it is frozen into the Software Requirements Specification (SRS) document, the formal contract between stakeholders and developers about what will be built.

⚠️ A performance target is non-functional even though it sounds like a number the system 'does'

The test is not whether the statement contains a verb or a number — it is whether the statement describes a distinct piece of BEHAVIOUR (functional) or a QUALITY that behaviour must exhibit (non-functional). 'The system shall calculate tax' is functional; 'the system shall calculate tax in under 100 ms' bundles a functional requirement with a non-functional constraint on it, and questions sometimes test whether a candidate can separate the two halves of such a combined statement.

Web Engineering and Formal Methods

Web engineering applies systematic software-engineering discipline to building web-based applications specifically, which differ from conventional software in needing to account for a much wider and less predictable range of client devices/browsers, continuous (rather than versioned/release-based) evolution, and content that itself changes independently of the application's code.
Formal methods use mathematically precise specification languages (e.g. Z notation, VDM) to describe a system's behaviour unambiguously and, where feasible, to PROVE properties about it (correctness, absence of certain classes of error) rather than merely testing for them — costly to apply in full, so typically reserved for safety- or security-critical components where the cost of a residual defect is unusually high.

Key takeaways

Every process realises the same generic activities (communication, planning, modeling, construction, deployment); a task set and a process pattern describe how one activity is carried out.
Waterfall suits stable, known requirements; spiral adds explicit risk analysis per iteration for large/high-risk projects; agile trades heavyweight sequential process for lightweight iterative delivery, not discipline for chaos.
Scrum has fixed sprints, a product backlog and three defined roles (Product Owner, Scrum Master, Development Team); XP emphasises pair programming and test-driven development.
A functional requirement states what the system does; a non-functional requirement states a quality/constraint on that behaviour — a combined statement can bundle both.
Formal methods prove properties mathematically rather than merely testing for them, at a cost that reserves them for safety/security-critical components.

Practice questions (8)

Attempt each one before opening the answer. Every explanation names the tempting wrong option as well as the right one, because that is where marks are lost.

The waterfall model is best suited to projects where:
1. Requirements are stable and fully known upfront
2. Requirements change constantly throughout development
3. No requirements exist at all
4. The team has no access to the customer
Show answer
Answer: A — Requirements are stable and fully known upfront
Waterfall's strictly sequential phases make going back to an earlier phase expensive, so it fits best when requirements are settled before development begins rather than evolving alongside it.
The spiral model is distinguished from a simple iterative model chiefly by its:
1. Explicit risk analysis at every loop of the spiral
2. Complete absence of any planning
3. Requiring exactly one iteration only
4. Forbidding any customer involvement
Show answer
Answer: A — Explicit risk analysis at every loop of the spiral
The spiral model combines iteration with a dedicated risk-analysis activity in every cycle, which is precisely why it is chosen for large, high-risk projects over a plain iterative approach without that discipline.
In Scrum, the role responsible for owning the product backlog and its priorities is the:
1. Product Owner
2. Scrum Master
3. Development Team
4. Project sponsor's auditor
Show answer
Answer: A — Product Owner
The Product Owner owns the backlog and its priorities; the Scrum Master facilitates the process and removes impediments; the Development Team is self-organising and delivers the increment — three distinct roles with distinct responsibilities.
Test-driven development, a practice associated with Extreme Programming, means:
1. Writing the test for a piece of functionality before writing the code that implements it
2. Never writing any tests at all
3. Testing only after the entire product is complete
4. Having the customer write all the code
Show answer
Answer: A — Writing the test for a piece of functionality before writing the code that implements it
In TDD, a failing test is written first to define the expected behaviour, and code is then written specifically to make that test pass — the reverse of writing code and testing it afterward.
'The system shall respond within 2 seconds under normal load' is best classified as a:
1. Non-functional requirement
2. Functional requirement
3. Use case
4. Process pattern
Show answer
Answer: A — Non-functional requirement
This statement describes a QUALITY (performance) the system's behaviour must exhibit, not a distinct piece of behaviour itself, which is the defining test for a non-functional requirement.
A use case in requirements modelling is best described as:
1. A named interaction between an actor and the system, described via a main success scenario and its alternative flows
2. A finished, tested piece of source code
3. A statement of a non-functional performance constraint only
4. A diagram with no textual description
Show answer
Answer: A — A named interaction between an actor and the system, described via a main success scenario and its alternative flows
A use case captures a goal-directed interaction from an actor's perspective, including what happens when things go as expected and what happens in exceptional/alternative paths — a structured way to elicit and organise functional requirements.
Which of the following are true of Agile software development, as distinct from a rigid waterfall process? (More than one option may be correct.)
1. It favours working software over comprehensive documentation
2. It favours responding to change over following a rigid plan
3. It has no defined roles, ceremonies or engineering practices at all
4. It typically delivers in short, iterative cycles rather than one long sequential pass
Show answer
Answer: A — It favours working software over comprehensive documentation; B — It favours responding to change over following a rigid plan; D — It typically delivers in short, iterative cycles rather than one long sequential pass
Agile methods are highly disciplined in their own way — Scrum has fixed ceremonies and roles, XP has strict engineering practices — so 'no discipline at all' is the standard misreading rather than a true property of Agile.
Name the formal document that freezes the gathered, reviewed requirements into a formal contract between stakeholders and developers about what will be built.
Numerical answer — type the value.
Show answer
Answer: SRS
The Software Requirements Specification (SRS) is the frozen, reviewed baseline that both sides agree describes what the system will do, used as the reference point for later design, testing and change management.