Requirements engineering Study Guide

📖 Core Concepts Requirements Engineering (RE) – The discipline of discovering, analyzing, documenting, validating, and managing stakeholder needs throughout a system’s life‑cycle. Stakeholder – Anyone (person, group, organization) who has a vested interest in the system’s functions or outcomes. Requirements Specification – The formal, validated artifact (often called an SRS) that captures all approved requirements in text and/or graphics. Traceability – The ability to link each requirement back to its source (stakeholder, need) and forward to design, implementation, and test artifacts. Scope Management – Controls what is included in the project’s deliverables; closely tied to RE because scope is defined by agreed‑upon requirements. 📌 Must Remember RE is not a one‑time phase; it continues from inception through operation (waterfall vs. iterative/RUP). Key RE activities: Elicitation → Analysis & Negotiation → Specification → Validation → Management. Major problems to watch for: Incomplete requirements Moving targets (changing stakeholder needs) Time‑boxing pressures Communication gaps, ambiguous terminology, poor traceability, unclear responsibilities. Standards: IEEE 12207 (software life‑cycle) and SWEBOK (comprehensive RE chapter). 🔄 Key Processes Elicitation Meet stakeholders → ask open‑ended questions → capture needs (use cases, user stories). Analysis & Negotiation Review elicited items → identify conflicts → iterate to add/modify requirements → resolve via stakeholder negotiation. Specification Write formal Requirements Specification (text + graphics). Include use cases, UML/LML diagrams as needed. Validation Check specification for consistency, completeness, and stakeholder alignment (reviews, walkthroughs). Management Track changes, maintain traceability, update artifacts, control scope throughout development and operation. 🔍 Key Comparisons Elicitation vs. Analysis Elicitation: gathering raw stakeholder needs. Analysis: structuring, refining, and resolving conflicts among those needs. Use Cases vs. User Stories Use Cases: detailed, scenario‑driven, often include pre/post‑conditions. User Stories: brief, “As a … I want … so that …” format, agile‑focused. Waterfall RE vs. Iterative RE Waterfall: RE done once, early, before design. Iterative (RUP): RE revisited continuously, allowing evolving requirements. ⚠️ Common Misunderstandings “Requirements are fixed after specification.” – In practice, RE activities are interleaved; changes are managed, not forbidden. “A good model = a complete requirement set.” – Models (UML/LML) support understanding but do not replace textual specifications or validation. “Traceability is optional.” – Without traceability, you cannot prove that each requirement is satisfied or assess impact of changes. 🧠 Mental Models / Intuition “Requirement as a contract” – Think of each requirement as a promise between stakeholder and developer; any change requires renegotiation (i.e., analysis). “Traceability chain” – Visualize a linked list: Stakeholder need → Requirement → Design → Code → Test. Breaks anywhere cause “missing link” bugs. 🚩 Exceptions & Edge Cases Time‑boxing may force a partial validation; document deferred requirements explicitly. Moving targets: If a stakeholder’s need changes, treat it as a new requirement, not a simple edit to an existing one, to preserve traceability. Terminology clashes: When two stakeholders use the same term differently, create a glossary entry to disambiguate before formalizing requirements. 📍 When to Use Which Use Cases → When you need detailed interaction sequences and system boundaries (especially for complex, safety‑critical systems). User Stories → When working in agile, need lightweight, customer‑focused requirements that can be rapidly prioritized. UML/LML diagrams → When visualizing architecture, data flow, or state machines aids stakeholder understanding. Formal Specification → When regulatory compliance or rigorous verification is required (e.g., aerospace). 👀 Patterns to Recognize “Incomplete requirement” pattern: Statements like “The system shall be fast” without measurable criteria → likely incomplete. “Moving target” cue: Frequent stakeholder change requests after baseline → indicates scope creep risk. “Ambiguous language” pattern: Use of words like efficient, user‑friendly, optimal without definition → flag for clarification. 🗂️ Exam Traps Distractor: “Requirements are only gathered at project start.” – Wrong; RE is continuous. Distractor: “Traceability is only needed for testing.” – Incorrect; traceability supports validation, impact analysis, and change management. Distractor: “UML diagrams replace the need for a written specification.” – False; diagrams supplement but do not substitute textual specs. Distractor: “Time‑boxing eliminates the need for validation.” – Misleading; validation must still occur, possibly in a trimmed form, and be documented.