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
- Get requirements right or nothing else matters.
- Requirements development is discovery and invention, not just collection.
- Change happens.
- All stakeholder interests intersect in requirements.
- Customer involvement is the most critical quality contributor.
- The customer is not always right, but always has a point.
- First question: "Is this requirement in scope?"
- Even the best SRS cannot replace human dialogue.
- Requirements may be vague, but the product will be specific.
- 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
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]
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
- Gain agreement on the problem definition.
- Understand root causes (the problem behind the problem).
- Identify stakeholders and create profiles.
- Define the solution system vision and boundary.
- 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
- Determine sources of requirements & select appropriate techniques.
- Elicit information on domain, problem, needs, and constraints.
- 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?
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
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)
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
- Use the keyword "shall" for mandatory requirements (consistent throughout).
- Write in active voice — identify who performs the action.
- Put the "punch line" first — statement of need/functionality before supporting details.
- Avoid and/or — can mean "any combination," leading to ambiguity.
- Watch for "unless," "except," "but" — each clause may hide a separate requirement.
- One requirement per sentence. Conjunctions (and, or, also) = danger sign of compound requirements.
- 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
- Introduction — Purpose, Document Conventions, Project Scope, References
- Overall Description — Product Perspective, User Classes, Operating Environment, Constraints, Assumptions & Dependencies
- System Features — Functional requirements by feature: Description/Priority, Functional Requirements, Error Handling
- Data Requirements — Logical Data Model, Data Dictionary, Reports, Data Acquisition & Retention
- External Interface Requirements — User Interfaces, Software Interfaces, Hardware Interfaces, Communications Interfaces
- Quality Attributes — Usability, Performance, Security, Safety + additional -ilities
- Internationalization & Localization — Currency, date formats, languages, time zones, physical standards
- Other Requirements — Legal, regulatory, financial compliance, audit trail
Specification Best Practices
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
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
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
- Establish a requirements change control process.
- Perform impact analysis on every requirements change.
- Establish baselines and control versions.
- Maintain a history of requirements changes.
- Track the status of each requirement throughout the project.
- Track requirements issues.
- Maintain a requirements traceability matrix.
- 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.