Software Requirements Engineering

Your Full-Mark
Final Exam Guide

Every concept, definition, technique, and trap from all 13 chapters — organized for exam success.

Ch 1: Fundamentals Ch 2: Inception Ch 3: Elicitation Process Ch 4: Elicitation Techniques Ch 5: Analysis & Modeling Ch 6: Writing Requirements Ch 7: Specification & SRS Ch 8: Standards & Templates Ch 9: NFRs Ch 10: Prioritization Ch 11: Data Requirements Ch 12: Validation Ch 13: Management
CH 01 Fundamentals of Software Requirements Engineering ▼
Core Definitions
Requirement A statement that translates or expresses a need and its associated constraints and conditions (IEEE/ISO/IEC 29148-2018).
Requirements Engineering (RE) The activity of development, elicitation, specification, analysis, and management of stakeholder requirements to be met by a new or evolving system.
User Requirement A desired goal or function that a user/stakeholder expects the system to achieve. Does NOT necessarily become a system requirement.
System Requirement Requirements for the system as a whole, describing services in detail.
Functional Requirement Defines functions/behaviors of the system — describes WHAT the system should do.
Non-Functional Requirement (NFR) Describes HOW WELL the product carries out its tasks. Three sub-categories: Quality Attributes, External Interfaces, Constraints.
Business Rule A requirement derived from business practices, government regulations, or standards. Can be functional or non-functional.
Domain Requirement Derived from the application domain; describes system characteristics that reflect the domain. May be new FRs or constraints.
RE Activities (The Process)
Inception
→
Elicitation
→
Analysis & Negotiation
→
Specification
→
Validation
→
Management
Inception Start the process: business need, feasibility study, system scope, risks.
Elicitation Requirements discovered through consultation with stakeholders.
Analysis & Negotiation Requirements analyzed; conflicts resolved through negotiation.
Specification A precise requirements document is produced.
Validation Document checked for consistency and completeness.
Management Needs and contexts evolve, and so do requirements.
NFR Sub-Categories
⚡Quality Attributes ("the -ilities"): performance, reliability, usability, availability, security, safety, robustness, etc.
🔌External Interfaces Connections to other SW, HW, users, and communication interfaces.
🔒Constraints Restrictions on developer options: language, process, cost, delivery, documentation standards.
10 Truths of RE
  1. Get requirements right or nothing else matters.
  2. Requirements development is discovery and invention, not just collection.
  3. Change happens.
  4. All stakeholder interests intersect in requirements.
  5. Customer involvement is the most critical quality contributor.
  6. The customer is not always right, but always has a point.
  7. First question: "Is this requirement in scope?"
  8. Even the best SRS cannot replace human dialogue.
  9. Requirements may be vague, but the product will be specific.
  10. You'll never have perfect requirements.
Why Does RE Matter? (Defect Stats)
🐛56% of all software defects originate from requirements.
💰82% of effort to fix defects goes toward requirement-origin defects.
🚀Mars Orbiter ($235.9M) lost due to metric/English unit mismatch — an interface requirement failure.
❌GIRES ($400M) cancelled because it couldn't cope with changing requirements.
RE Challenges
Lack of expertise Insufficient user involvement Overlookeed stakeholders Ambiguous requirements Conflicting requirements Creeping/changing requirements Unrealistic goals
CH 02 Requirements Inception & Vision and Scope ▼
What is Inception?
Goal Establish a shared understanding of the product's context — defining the underlying problem, proposed solution, boundaries, and benefits. Output: the Vision and Scope Document.

"Do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility." — Craig Larman

Vision and Scope Document — 3 Pillars
🎯1. Business Requirements Why the organization builds the system. Includes: Business Opportunity, Objectives, Success Metrics, Vision Statement, Risks, Assumptions & Dependencies.
📐2. Scope & Limitations What IS and IS NOT in scope. Includes: Major Features, Initial Release Scope, Subsequent Releases, Limitations & Exclusions.
🌍3. Business Context The environment. Includes: Stakeholder Profiles, Project Priorities, Deployment Considerations.
Vision Statement Template (Moore)
For [target customer]
Who [statement of need or opportunity]
The [product name]
Is a [product category]
That [key benefit]
Unlike [competitive alternative]
Our product [statement of primary differentiation]
Scope Representation Techniques
Context Diagram Shows system boundary + external entities that directly interface with it. Shows data flows in/out. Does NOT show internal workings.
Ecosystem Map Shows ALL related systems (direct and indirect). Broader view than context diagram.
Feature Tree Hierarchical visual of product features (L1 → L2 → L3). Scope defined by selecting features.
Event List Identifies external events triggering system behavior. User-triggered, time-triggered, or signal-triggered.
Key Distinctions
Concept Definition
Product Vision Applies to the product as a whole. Does NOT change between releases.
Project Scope Specific portion of the vision for a current project/release. More dynamic.
Scope Creep Uncontrolled growth of project scope. Prevented by Vision & Scope doc.
5 Steps of Problem Analysis
  1. Gain agreement on the problem definition.
  2. Understand root causes (the problem behind the problem).
  3. Identify stakeholders and create profiles.
  4. Define the solution system vision and boundary.
  5. Identify constraints to be imposed on the solution.
CH 03 Requirements Elicitation — Process ▼
What is Elicitation?
Definition The process of identifying the needs and constraints of the various stakeholders for a software system. It is a collaborative and analytical process — NOT just "gathering requirements."
Elicitation Goals
  1. Determine sources of requirements & select appropriate techniques.
  2. Elicit information on domain, problem, needs, and constraints.
  3. Produce a first document (may be incomplete, disorganized, inconsistent — that's OK).
3-Phase Elicitation Process
Phase 1 — Prepare Plan objectives, strategy, schedule, risks. Prepare questions, straw man models, agenda, scope. Identify stakeholders and their preferences.
Phase 2 — Perform Execute elicitation sessions. Take comprehensive notes: attendees, decisions, action items, outstanding issues, key points.
Phase 3 — Follow Up Review/update notes immediately. Consolidate input. Keep originals. Review with stakeholders. Document open issues and gaps.
Sources of Requirements
👥Stakeholders (clients, users, domain experts, developers, etc.)
💻Existing systems (not necessarily software)
📄Existing documentation
⚔️Competing systems
🔗Interfacing systems documentation
⚖️Standards, policies, legislation
When Are You Done Eliciting?
Users can't think of more use cases New scenarios don't yield new FRs Users repeat covered issues New features all out-of-scope New requirements all low priority Developers/testers have few questions
Challenges & Mitigations
Challenge Area Specific Issues Mitigation
Scope Inadequately defined; maintaining focus Use explicit in-scope/out-of-scope lists. Re-check before each session.
Requirements Assumed, implied, or missing Ask "What are we assuming here?" Analyze requirements.
Stakeholders Unavailability, conflict, lack of technical knowledge BA interpersonal skills. Consult domain experts.
Business Analyst Lack of expertise or domain knowledge Research domain, consult others.
CH 04 Elicitation Techniques ▼
Two Categories
🗣️Facilitated (with stakeholders) Interviews, Workshops, Focus Groups, Observations, Questionnaires. Primarily discovers user and business requirements.
🔍Independent (work alone) System interface analysis, User interface analysis, Document analysis. Finds functionality users may not be aware of.
Facilitated Techniques — Key Details
Interviews One-on-one or small groups. Strengths: fast domain learning, comfortable setting, suitable for busy executives. Tips: prepare questions, stay in scope, listen actively, paraphrase to confirm understanding.
Workshops (JAD) Structured meetings with multiple stakeholders concurrently. Strengths: effective for solving disagreements, good for tight schedules. Tips: enforce ground rules, parking lots for off-topic items, timebox, keep small but inclusive.
Focus Groups Representative users; generate subjective feedback. Valuable for commercial products. Participants typically lack decision-making authority.
Observations / Ethnography Shadow users "in the wild." Can be silent or interactive. Time-consuming but reveals insights other techniques cannot. Useful for high-risk tasks.
Questionnaires Survey large or distributed populations. Inexpensive. Tips: avoid suggestive questions, use consistent scales, mutually exclusive answers, test the questionnaire first.
Independent Techniques
System Interface Analysis Examine connected systems. Reveals functional requirements for data exchange and service integration.
User Interface Analysis Study existing or similar systems. Good for building a new version. Clarifies user input by relating to real-world examples.
Document Analysis Review existing documentation (may be outdated). Good for domain familiarization.
Use Cases & Misuse Cases
Use Case A sequence of interactions between a system and an external actor resulting in an outcome of value. User-centric (shifts from "what system does" to "what user needs to accomplish").
Scenario A single specific instance of a use case (specific actor, time, and data).
Actor Any entity that interacts with the system (person, org, external system, hardware). Reflects a ROLE, not a person.
<<include>> Mandatory functionality reused across multiple use cases. Arrow points TO the included use case.
<<extend>> Optional extension. Base case is meaningful on its own. Arrow points TO the base use case.
Misuse Case Negative scenario — goal desirable to a hostile misactor but undesirable to the business. Use <<threaten>> and <<mitigate>>. Elicits security/safety requirements early.
Prototyping
Type Description Pros Cons
Low-Fidelity Static/non-functional (paper sketches) Quick, cheap, great for interfaces Not interactive, may seem unprofessional
High-Fidelity Fully functional Deeper understanding, precise decisions Time-consuming, costly, false sense of security
Evolutionary Grows into the final product Users get working system early May lock in early design decisions
Throwaway Discarded after eliciting requirements Focuses on unknowns, cheap Pressure to release; wasted effort if over-built
Prototype Purposes (must be declared upfront!) 1) Clarify/validate requirements (requirements tool)  |  2) Explore design alternatives (design tool)  |  3) Create a subset that grows into the product (construction tool)
Factors for Choosing Elicitation Techniques
Conscious vs unconscious vs subconscious requirements Time & budget constraints Stakeholder availability BA experience with the technique
CH 05 Requirements Analysis & Modeling ▼
What is Analysis?
Goal Study customer and user needs to arrive at a definition of the problem domain and system requirements. Detect conflicts, negotiate priorities, elaborate requirements, classify and allocate to subsystems, evaluate for quality.
UML Diagrams — Most Relevant for RE
Use Case Diagram Behavioral. Shows actors and their interactions. Relationships: association, generalization, <<include>>, <<extend>>.
Sequence Diagram Models message exchange in a single use case. Shows timeline top-to-bottom. Parts: lifelines, activation bars, message arrows (sync=solid, async=open arrowhead), return messages, reflexive messages, fragments (alt, opt, loop, ref).
Class Diagram Domain modeling. Shows classes, attributes, operations, and relationships: Association, Multiplicity, Aggregation ("part of"), Composition (destroy whole→destroy part), Inheritance/Generalization ("is-a").
Activity Diagram Workflow / business process modeling. Can be swimlane-style.
State Machine Diagram Detailed behavioral specification. Shows states and transitions (event-driven objects).
Domain Modeling — Finding Elements
🟦Classes → Nouns/noun phrases in requirements. Must represent persistent data. Exclude: "System," "Database," "Web."
🔗Associations → Verbs/verb phrases. Must be structural, not transient operations. Remove derived associations.
📋Attributes → Noun + possessive phrase (e.g., Customer's address). Do NOT include IDs as attributes in domain models.
Common Modeling Pitfalls
Domain Modeling Errors Including "System," "Web," or "Database" as classes. Using IDs to relate classes. Over-generalizing hierarchies. Modeling operations as associations (transient focus).
Use-Case Modeling Errors Representing input/output devices (e.g., "Telephone") as actors. Use cases too large or too small. Treating "Login" as a functional use case (it's a security constraint). Treating model as a functional decomposition chart.
Sequence Diagram Elements
Element Description
Lifeline Vertical dashed line representing an object/participant
Activation Bar Rectangle on lifeline indicating object is active
Synchronous Message Solid arrowhead — sender waits for response
Asynchronous Message Open arrowhead — sender does not wait
Return Message Dashed arrow — indicates control returned to caller
Reflexive Message Arrow starts and ends on same lifeline
alt fragment if-then-else branching
opt fragment if-then (optional)
loop fragment Repetitive sequence
CH 06 Writing Excellent Requirements ▼
7 Characteristics of an Excellent Individual Requirement
Complete Contains all info for the reader to understand it. Use TBD for gaps. Resolve all TBDs before implementation.
Correct Accurately describes a capability meeting a stakeholder need. No conflict with parent requirements.
Feasible Implementable given system capabilities and project constraints (time, budget, staff).
Necessary Provides business value, differentiates product, or satisfies external regulation. If you can't justify it, remove it.
Prioritized Ranked by importance. Allows managers to respond to schedule overruns or resource losses.
Unambiguous Only ONE interpretation possible. Use peer reviews to catch differing interpretations.
Verifiable A tester can devise objective tests to determine if correctly implemented. Non-verifiable = matter of opinion.
Characteristics of a Requirements Collection (SRS)
Complete Consistent Modifiable Traceable
Consistent No conflicts between requirements. Record originator to trace back on conflict.
Modifiable Unique labels, change history, avoid redundancy, cross-reference related items.
Traceable Linkable backward to origin and forward to design/code/tests. Use unique identifiers.
Writing Style — Key Rules
  1. Use the keyword "shall" for mandatory requirements (consistent throughout).
  2. Write in active voice — identify who performs the action.
  3. Put the "punch line" first — statement of need/functionality before supporting details.
  4. Avoid and/or — can mean "any combination," leading to ambiguity.
  5. Watch for "unless," "except," "but" — each clause may hide a separate requirement.
  6. One requirement per sentence. Conjunctions (and, or, also) = danger sign of compound requirements.
  7. Do NOT describe how — describe what. No premature design.
Sources of Ambiguity
Fuzzy Words "user-friendly," "flexible," "approximately," "quickly," "reasonably" — unverifiable. Define in glossary.
A/B Construct Slashes (Delivery/Fulfillment) — could mean "and," "or," or a team name. Use explicit language.
Boundary Values "5 to 10 days" — does 5 or 10 count? Use "through," "inclusive," "exclusive," "longer than."
Negative Requirements "The system shall NOT do X" — hard to implement and verify. Rephrase as positive. Move exclusions to scope document.
Syntax Templates
[Optional precondition] [Optional trigger event] the system shall [expected system response]
The [user class or actor] shall be able to [do something] [to some object] [qualifying conditions]
Writing Pitfalls to Avoid
🚫Noise Text that carries no relevant information
🔇Silence A feature not covered by any text
⚠️Over-specification Describing solution, not problem
❗Contradiction Same feature defined incompatibly
🌀Wishful thinking Asking for the impossible (100% reliable)
🧩Jigsaw puzzle Distributing requirements and cross-referencing without clarity
CH 07 Requirements Specification & SRS ▼
What is an SRS?
SRS (Software Requirements Specification) The documented agreement among stakeholders about the product to be built. States functions, capabilities, characteristics, constraints, and system behaviors. Also called: BRD, functional specification, product specification, system specification.
What SRS is NOT It should NOT contain design, construction, testing, or project management details (except known implementation constraints).
SRS Audiences
👨‍💻Developers — what to build
📊Project Managers — scheduling & resource estimation
🧪Testers — develop requirements-based tests
⚖️Legal Staff — compliance with laws
🛠️Maintenance — understand product parts
📢Customers/Marketing — product expectations
🏗️Subcontractors — legally bound to requirements
📚Documentation Writers — user manuals
Requirements Labeling Methods
Method Example Pros Cons
Sequence Number FR-26, UC-9 Easy to move around; retained if requirement deleted No logical grouping; tells nothing about intent
Hierarchical Numbering 3.2.4.3 Simple, compact, familiar, word processor support Labels can grow long; numbers change if sections move (non-persistent!)
Hierarchical Textual Tags Product.Cart.Error Meaningful, unaffected by adding/deleting/moving Difficult to maintain uniqueness; longer
Best Practice Combine hierarchical naming with sequence numbers for small sets (e.g., Product.Cart.01). A number is NEVER reused when a requirement is deleted.
Volere Shell — Individual Requirement Template
#️⃣Unique ID & Requirement Type
📝Description (one-sentence statement)
💡Rationale — justification
👤Source — who raised it
📏Fit Criterion — measurable test of success
😊😞Stakeholder Satisfaction/Dissatisfaction (1–5 scale)
🔗Dependencies & Conflicts
📅History — creation and change records
Dealing with Incompleteness
TBD (To Be Determined) Flag missing information. Number them, assign a responsible person with a deadline, track to closure. TBDs won't resolve themselves — plan to resolve ALL before implementation.
CH 08 SRS Standards & Structural Templates ▼
Standards Evolution
📜IEEE 830-1998 "Recommended Practice for SRS." Describes content and qualities. Provides sample outlines. Now superseded.
🔧ISO/IEC/IEEE 29148:2011 Supersedes 830. Unified treatment across the system lifecycle. Defines: StRS, SyRS, SRS, OpsCon, ConOps.
Standard SRS Template — 8 Sections
  1. Introduction — Purpose, Document Conventions, Project Scope, References
  2. Overall Description — Product Perspective, User Classes, Operating Environment, Constraints, Assumptions & Dependencies
  3. System Features — Functional requirements by feature: Description/Priority, Functional Requirements, Error Handling
  4. Data Requirements — Logical Data Model, Data Dictionary, Reports, Data Acquisition & Retention
  5. External Interface Requirements — User Interfaces, Software Interfaces, Hardware Interfaces, Communications Interfaces
  6. Quality Attributes — Usability, Performance, Security, Safety + additional -ilities
  7. Internationalization & Localization — Currency, date formats, languages, time zones, physical standards
  8. Other Requirements — Legal, regulatory, financial compliance, audit trail
Specification Best Practices
Avoid information redundancy — use cross-references Maintain version control with revision history Each requirement must be objectively verifiable Focus on external behavior, not design Maintain a glossary for specialized terms
CH 09 Non-Functional Requirements (NFRs) ▼
SMART Mnemonic for NFRs
Specific
Measurable
Attainable
Relevant
Time-sensitive
External Quality Attributes (user-facing)
Availability Planned uptime when services are fully operational. Example: "The system shall be at least 95% available on weekdays 6AM–midnight."
Integrity Preventing information loss / protecting data correctness. Zero tolerance for error. Example: "System shall protect against unauthorized addition, deletion, or modification of data."
Performance Responsiveness under specific conditions. Example: "ATM withdrawal authorization ≤ 2.0 seconds."
Reliability Probability of failure-free execution over a time period. Example: "No more than 5 experimental runs out of 1,000 lost due to software failures."
Robustness Function properly despite invalid inputs, hardware defects, or unexpected conditions. Example: "Text editor shall recover content as of at most 1 minute before failure."
Safety Prevent injury to people or damage to property. Example: "Radiation machine shall allow irradiation only if proper filter is in place."
Security Block unauthorized access to functions or data. Example: "System shall lock account after 4 consecutive failed logon attempts within 5 minutes."
Usability Ease of learning, efficiency, memorability, error avoidance. Example: "A trained user shall submit a chemical request in ≤ 3 minutes on average."
Internal Quality Attributes (developer-facing)
Modifiability How easily code can be understood, changed, extended. (Includes portability — porting to another platform.)
Scalability Ability to grow to accommodate more users, data, or transactions.
Testability Ability to detect, isolate, and fix defects.
Reusability Percentage of requirements/design/code reused in new applications.
Trade-offs — Positive & Negative Relationships
Negative Impact (–) Increasing performance or efficiency often adversely affects modifiability, portability, and reusability.
Positive Impact (+) Increasing integrity or reliability often positively affects safety and usability.
Prioritization Method Use pairwise ranking spreadsheet: Elicit → Compare pairs → Bias conflict resolution toward higher-scoring attribute.
Availability Formula
Availability = MTBF / (MTBF + MTTR)

MTBF = Mean Time Between Failures
MTTR = Mean Time to Repair
CH 10 Requirements Prioritization ▼
Why Prioritize?
80/20 Rule 80% of a product's value comes from 20% of its functionalities. The remaining 80% of features offer a lower ROI while adding development costs and delays. Goal: identify and prioritize the critical 20%.
Prioritization Techniques
1 — In or Out

Simply decide: is each requirement IN or OUT of the current release? Fast, informal. Good for small projects.

2 — Three-Level Scale (Urgency × Importance Matrix)
Importance / Urgency High Urgency Low Urgency
High Importance 🔴 High Priority — MUST be in next release 🟡 Medium Priority
Low Importance ⚠️ "Waste" — urgent but not important; scrub or deprioritize 🟢 Low Priority
3 — MoSCoW
Must — required for success; non-negotiable
Should — important but not critical for success
Could — nice to have; postponed or eliminated
Won't — not in this release (may or may not be "never")
4 — $100 Method

Stakeholders "spend" $100 across requirements to reflect priorities. Tangible but allows "gaming." Good for groups.

5 — Wiegers' Semi-Quantitative
Priority = Value% / ((Cost% × Cost_Weight) + (Risk% × Risk_Weight))

Value% = (Benefit + Penalty) / Total
Higher priority = high value, low cost, low risk
6 — Kano Model
Basic (Must-be) Taken for granted. Absence = very dissatisfied. Presence = no increase in satisfaction.
Performance Explicitly requested. Satisfaction proportional to execution level.
Excitement (Delighters) Not expected. If present → high satisfaction. If absent → no dissatisfaction.
Indifferent Customer doesn't care either way.
Reverse Feature actually causes dissatisfaction if included.
Kano Survey Method Two questions per requirement: Functional ("How do you feel if it IS included?") + Dysfunctional ("How do you feel if it is NOT included?").
CH 11 Data Requirements & Modeling ▼
Data Dictionary
Definition A shared repository defining the meaning, composition, data type, length, format, and allowed values for every data element used in an application. Prevents inconsistent variable names, conflicting validation criteria, and system crashes.
Data Element Types
Primitive Cannot be further decomposed. Described with data type, length, range, allowed values.
Structure Composed of multiple elements separated by "+". E.g., Requester = Name + Employee Number + Department.
Repeating Group Multiple instances of an element. Enclosed in {min:max}. "n" = unlimited maximum.
Entity-Relationship Diagram (ERD)
Entity Physical items, people, or aggregations of data. Shown as rectangles, named with singular nouns.
Relationship Logical link between entities. Read in both directions.
Cardinality (Multiplicity) 1:1, 1:M (one-to-many), M:M (many-to-many).
ERD Notation Styles
Notation Entities Relationships Cardinality
Peter Chen Rectangles Diamonds Numbers/letters on lines
James Martin (Crow's Foot) Rectangles Label on line Vertical line=1, crow's foot=many, circle=0
UML Class Diagram Class boxes Lines Multiplicity notation (0..*, 1..5)
CH 12 Requirements Validation & Verification ▼
Validation vs. Verification — CRITICAL DISTINCTION
Validation Verification
Question "Are we building the RIGHT product?" "Are we building the product RIGHT?"
Focus Satisfies customer needs Product meets its requirements correctly
Activity Check with elicitation sources / stakeholders Check SRS against writing rules, standards, consistency
Peer Review Types
Informal Reviews Peer deskcheck, passaround, walkthrough. Useful for education and unstructured feedback. Good for catching errors but may miss ambiguities.
Formal Inspection (Fagan) Well-defined multi-stage process. Best-established formal review. Serves as a quality gate before baselining.
Inspection — Roles & Lifecycle
✍️Author Created the work; addresses defects
🎯Moderator Plans, leads, ensures follow-up
📖Reader Paraphrases requirements to the team
📋Recorder Captures defects and action items
1. Planning
→
2. Preparation
→
3. Inspection Meeting
→
4. Rework
→
5. Follow-Up
Key Rules Max 2 hours per meeting. 3–5 reviewers. Author's supervisor does NOT participate. Up to 75% of defects found during individual preparation. Re-inspect if >5% of document changes.
Other V&V Techniques
Prototyping Makes requirements tangible. Paper mock-ups → walk through use cases. Evolutionary prototypes → users see real behavior.
Functional Test Design Write tests before building. If tester can't describe expected behavior → requirement is vague. Traces tests to requirements.
Simple Checks (Traceability) Traceability matrix to verify requirements are well-written and all source requirements are addressed.
CH 13 Requirements Management ▼
Key Definitions
Requirements Management (RM) A systematic approach to eliciting, organizing, and documenting requirements, and a process that establishes/maintains agreement between customer and project team on changing requirements.
Baseline A non-modifiable (read-only) version of requirements agreed upon by stakeholders for a specific release. Any subsequent changes go through change control. Enables comparison and management.
Traceability A link or relationship defined between entities. "One CANNOT manage what cannot be traced."
Requirement Statuses
📬Proposed Requested but not yet approved
✅Approved Part of baseline; committed to implement
❌Rejected Evaluated and declined
⚙️Implemented Designed and coded
🧪Verified Relevant tests have passed
🗑️Deleted Removed from list (number NOT reused)
⏳Deferred Approved but planned for later release
Types of Traceability
Requirements–Source Links requirements to person or document that originated them.
Requirements–Requirements Links to other requirements that are dependent on them.
Requirements–Architecture Links to subsystems where requirements are implemented.
Requirements–Design Links to HW/SW components implementing the requirement.
Requirements–Tests Links to test cases verifying the requirement.
Traceability Matrix A table defining links between pairs of elements. Becomes large/sparse with hundreds of requirements → use Traceability List instead (lists of related requirement IDs alongside each requirement).
Change Management Process
1. Problem Identified
→
2. Change Request Submitted
→
3. Impact Analysis
→
4. CCB Decision
→
5. Implement
→
6. Verify
→
7. Close
CCB (Change Control Board) The body that decides which changes to implement. No design or implementation work on unapproved changes (except feasibility analysis).
RM Best Practices
  1. Establish a requirements change control process.
  2. Perform impact analysis on every requirements change.
  3. Establish baselines and control versions.
  4. Maintain a history of requirements changes.
  5. Track the status of each requirement throughout the project.
  6. Track requirements issues.
  7. Maintain a requirements traceability matrix.
  8. Use a requirements management tool.
BONUS Quick Exam Practice — Tap to Reveal Answers ▼
Q1 What is the difference between validation and verification?
Validation = "Are we building the RIGHT product?" (customer needs). Verification = "Are we building the product RIGHT?" (meeting requirements correctly).
Q2 Name the 7 characteristics of an excellent individual requirement.
Complete, Correct, Feasible, Necessary, Prioritized, Unambiguous, Verifiable.
Q3 What does the Availability formula look like?
Availability = MTBF / (MTBF + MTTR). MTBF = Mean Time Between Failures; MTTR = Mean Time to Repair.
Q4 What is the difference between <<include>> and <<extend>> in Use Case Diagrams?
<<include>>: mandatory shared functionality; arrow points TO the included use case. <<extend>>: optional extension; base case is meaningful on its own; arrow points TO the base use case.
Q5 What is a misuse case? What relationships does it use?
A misuse case captures a negative scenario from a hostile misactor's perspective. It uses <<threaten>> (misactor threatens a use case) and <<mitigate>> (mitigation use case neutralizes the threat).
Q6 What is a requirements baseline?
A non-modifiable (read-only) version of requirements agreed upon by stakeholders, typically for a specific release. All subsequent changes must go through formal change control.
Q7 What are the three categories of non-functional requirements?
1) Quality Attributes (the "-ilities": performance, reliability, security, usability, etc.) 2) External Interfaces (connections to other SW, HW, users) 3) Constraints (restrictions on developer options).
Q8 What is Wiegers' prioritization formula?
Priority = Value% / ((Cost% × Cost_Weight) + (Risk% × Risk_Weight)). Higher priority = high value, low cost, low risk.
Q9 Name the 4 roles in a Fagan Inspection.
Author (created the work), Moderator (plans/leads/follows up), Reader (paraphrases document to team), Recorder (captures defects and action items).
Q10 What is the 80-20 rule in the context of requirements prioritization?
80% of a product's value or revenue comes from 20% of its functionalities. The remaining 80% of features offer a lower ROI while adding costs and delays. Prioritization aims to identify that critical 20%.
Q11 What is the RE Process sequence?
Inception → Elicitation → Analysis & Negotiation → Specification → Validation → Management. It is iterative, not a one-time sequence.
Q12 What are the Kano model's 5 requirement categories?
Basic (Must-be), Performance, Excitement (Delighters), Indifferent, Reverse.
Q13 What does TBD mean and how should it be handled?
TBD = To Be Determined. It flags missing information. Must be numbered, assigned to a responsible person with a deadline, and tracked to closure. ALL TBDs must be resolved before implementation.
Q14 What is the difference between a Context Diagram and an Ecosystem Map?
Context Diagram shows only systems/entities that DIRECTLY interface with the system and their data flows. Ecosystem Map shows ALL related systems including those with indirect connections.