🗄️ OLD — Requirements Engineering and Analysis Modeling (consolidated)

CSS Computer Science (Optional) — Paper-I, Section-B, Topic V. This is FPSC's single most reliable Software Engineering topic — some form of it has appeared in 5 of the last 7 available papers (2019, 2020, 2021, 2022, 2025). Do not under-prepare this page.

The Requirements Engineering Process

Elicitation (gather needs from stakeholders — interviews, workshops, observation) → Analysis (resolve conflicts and ambiguities between stakeholders) → Specification (write it down, usually as a Software Requirements Specification, or SRS) → Validation (check with the customer that this is actually what they need) → Management (track changes as requirements evolve across the project's life).

Functional vs Non-Functional Requirements

• Functional requirements: statements of what the system must do — specific features, behaviors, and services (e.g. "the system shall allow a user to reset their password").
• Non-functional requirements: constraints on how well the system does it — performance, security, usability, reliability, scalability, portability. A system can satisfy every functional requirement and still fail if it violates a non-functional one (e.g. correct output that takes 30 seconds to compute).

Verification vs Validation

The distinction FPSC returns to again and again — memorize the two questions, not just the two words.

Analysis Modeling

Translating validated requirements into structured models — before design begins, not instead of it:

• Data Flow Diagrams (DFDs): show how data moves through the system, level by level, starting from a single-bubble context diagram and decomposing into finer detail.
• Use-Case Diagrams: capture functional requirements from the end user's point of view — actors (external users/systems), use cases (goals the actor can achieve), and associations between them, plus <<include>> (a use case always incorporates another) and <<extend>> (a use case optionally extends another under specific conditions). Useful as a non-technical communication bridge between stakeholders and developers, and as the basis for later test-case design.
• Class Diagrams: structural, not behavioral — candidate classes, their attributes, and the relationships between them. Contrast with use-case diagrams if a question invites comparison: class diagrams show structure, use-case diagrams show behavior.
• State Diagrams: model event-driven behavior — the states an object/system can be in, and the events that trigger transitions between them. Most relevant for reactive or embedded-style systems.

🔥

Repeated in past papers: 2019 Q7(c) — functional vs non-functional requirements in a web-engineering context. 2020 Q8(b) — the role of validation and verification in requirements engineering. 2021 Q8(b) — functional/non-functional requirements for a website. 2022 Q7(c) — writing a user requirement vs a system requirement from a natural-language description. 2025 Q7(b) and Q8(a) — verification vs validation testing techniques, and requirements engineering's role in web engineering. See 🔥 Most Repeated — Software Engineering for full worked model answers, including a full requirements-conflict scenario question.

Requirements Sign-off (2017)

The formal step at the end of the RE process where the customer/client and relevant stakeholders formally review, agree to, and approve the documented requirements (the SRS) — marking them as the officially agreed baseline for the rest of the project.

• Why it matters: it's the practical enforcement point for "Validation" above — without formal sign-off there's no agreed reference point to measure "did we build the right product" against, and scope disputes become far harder to resolve later.
• What it protects against: scope creep (uncontrolled, informal addition of requirements after development starts), disputes over what was actually agreed, and wasted rework from building against requirements that were never truly finalized.
• Typical elements: a reviewed, version-numbered SRS document; documented stakeholder approval; a defined change-control process for any requirement changes after sign-off (further changes go through formal change requests, not informal asks).
• Where it sits in the process: sign-off is the formal culmination of validation, and happens after validation confirms requirements meet stakeholder needs but before design begins — once signed off, requirements shift from negotiable to being the fixed baseline that verification activities are measured against.

MCQ Trap

• A requirement that is correct but was never confirmed with the customer is a validation failure, not a verification failure — verification only checks against the written spec, which can itself be wrong.
• "User requirement" (high-level, in the customer's own language) vs "system requirement" (detailed, technical, for developers) is a distinct but related pairing FPSC has also tested directly.
• Sign-off happens after validation and before design — placing it earlier, or treating it as an ongoing rather than a formal milestone, is a common error.