Lesson 2.

2: Requirements
Elicitation

🎓 Lecture 2.2: Requirements Elicitation

(Based on Laurendeau, Bruegge & Dutoit, and David Kung)

🧩 1️⃣ Learning Outcomes

By the end of this lecture, you should be able to:

Extract functional and non-functional requirements from a problem

description.

Construct a functional model (using use cases and scenarios).

Incorporate traceability into every work product — ensuring every

requirement can be tracked through design, implementation, and testing.

That last one, traceability, is crucial — it’s how we ensure that nothing the client
asked for gets “lost” in development.

🧠 2️⃣ What Is Requirements Elicitation?

Definition
“Elicitation” literally means drawing out information — it’s not about inventing
features but discovering what stakeholders truly need.
It’s the process of acquiring information:

It flows from the client → to the development team.

So instead of “writing code,” this stage is about understanding.

You’re not building the system yet — you’re building a mental model of it.

Lesson 2.2: Requirements Elicitation 1

 What Are Requirements?
A requirement is simply:

A statement of what the client wants the system to do, and under what
constraints.

We can group them into two main types:

1. Functional Requirements (FRs) –

What the system does.
→ e.g., “The system shall allow users to log in.”

2. Non-Functional Requirements (NFRs) –

Constraints on how well the system performs its functions.
→ e.g., “The system shall respond to login attempts within 2 seconds.”

🔁 3️⃣ The Iterative Nature of Elicitation

Elicitation is highly iterative and incremental.
You rarely get perfect requirements in one go. Instead, you:

1. Map out initial functionality.

2. Propose it to the client or end-users.

3. Refine it based on feedback.

This process repeats several times — much like sculpting.

Each iteration removes ambiguity and fills in missing pieces.

Think of it as a conversation loop — not a one-time interview.

⚠️ 4️⃣ The Challenges of Requirements Elicitation

Elicitation is arguably the hardest part of software engineering, because it’s
deeply human.

Lesson 2.2: Requirements Elicitation 2

 🧩 Wicked Problem
The term “wicked problem” means a problem that is difficult or impossible to
solve completely because:

Requirements are incomplete or contradictory.

Stakeholders have conflicting needs.

The environment changes during development.

In short: you can’t fully understand the problem until you start solving it.

💬 Communication Barriers
Clients often don’t know what’s technically possible.
They may ask for features that sound simple but are complex, or vice versa.

(“Just add a button that predicts stock prices.”)

Developers may misunderstand the domain language.

A “transaction” to a bank teller means something very different than to a

programmer.

This leads to mismatched expectations — one of the top causes of project failure.

⚙️ Impact of These Challenges

If these difficulties are underestimated:

Non-functional requirements are often missed or understated.

(For instance, “system uptime” or “security” may be assumed rather than

specified.)

Requirements change as the project evolves — known as requirements

volatility.

That’s why we must build flexibility into our process — expecting change rather
than fearing it.

🪜 5️⃣ The Requirements Elicitation Steps

Lesson 2.2: Requirements Elicitation 3
 This diagram usually shows a flowchart or lifecycle that includes:

1. Identifying stakeholders (who provides information).

2. Collecting information (through interviews, documents, observations).

3. Analyzing and negotiating (resolving conflicts and prioritizing).

4. Documenting requirements (in a specification).

5. Validating (confirming with the client that everything is correct).

Each step feeds into the next in a feedback loop — not a one-way process.

🧾 6️⃣ Information Collection Techniques

Gathering requirements requires skillful communication — it’s both art and
method.

Here’s what that diagram typically lists and how each technique works.

🗣️ 1. Interviews
The most direct and common method.

Structured or open-ended discussions with clients and users.

Useful for gathering detailed and subjective information.

Example questions:

“What do you like about your current system?”

“What problems occur most frequently?”

“If you could change one thing, what would it be?”

👥 2. Questionnaires and Surveys

Efficient for reaching many users.

Good for quantifying preferences or measuring satisfaction.

Example: “Rate the importance of mobile access on a scale of 1–5.”

Lesson 2.2: Requirements Elicitation 4

 🔍 3. Document and Workflow Analysis
Study existing manual procedures, paper forms, or legacy system
documentation.

Helps reveal implicit requirements — features people take for granted.

🧩 4. Observation (“Shadowing”)
Watch users perform their tasks in the real environment.

You’ll often notice steps they forget to mention in interviews.

🧪 5. Prototyping
Build a quick, throwaway model to visualize functionality.

Helps clarify vague requirements.

🗺️ 6. Brainstorming and Workshops

Gather all stakeholders in a room to generate ideas collectively.

Promotes collaboration and fast consensus.

🧭 7. Scenarios and Storyboards

Create “story-like” walkthroughs of how users interact with the system.

Excellent for visual thinkers and clients who prefer concrete examples.

🧠 8. Group Decision Techniques

Delphi method, voting, or prioritization exercises.

Useful when stakeholders disagree on feature importance.

💬 9. Asking the Right Questions

When discussing with clients, always ask:

What is your business, and how does it operate?

Lesson 2.2: Requirements Elicitation 5

 What’s the system’s environment or context?

What are your existing business processes — inputs, outputs, and

interactions?

What problems exist in the current system?

Who are the users, and what are their roles and priorities?

What are your quality, performance, and security expectations?

These questions drive the discovery of both functional and non-functional

needs.

🧱 Diagram Reference – “Requirements Elicitation Work Products”

(Refer to the diagram showing “Requirements → Analysis” and “Client–Team
interaction.”)

This diagram highlights how the outputs of elicitation feed into analysis:

Inputs: Problem statement (from client).

Outputs: Functional model and Non-functional requirements.

These form the foundation for later modeling (use cases, state machines,
etc.).

🧩 7️⃣ Requirements Elicitation Concepts

Now that we understand the process, let’s define the key concepts you’ll apply.

🔹 Functional Requirements (FRs)

These describe what the system will do, not how it does it.

Focus: Features and behaviors.

They must be design-independent — you’re not specifying algorithms or UI

elements.

Example FRs:

“The system shall allow a student to register for courses.”

Lesson 2.2: Requirements Elicitation 6

 “The system shall generate a receipt upon successful payment.”

They capture interactions between the system and its environment.

🔹 Non-Functional Requirements (NFRs)

These describe user-visible constraints on the system’s operation.
They must be:

Quantifiable

Testable

Example:

“System uptime shall be at least 99.9%.”

Common NFR Categories:

Category Example

Usability UI must be easy to navigate; provide online help.

Reliability Must perform under heavy load; tolerate network failures.

Performance Response time < 2 sec; throughput ≥ 100 transactions/sec.

Supportability Easy to maintain; portable across OSes.

Implementation Built using Java and PostgreSQL.

Interface Must integrate with PayPal API.

Operations Simple installation and updates.

Packaging Include installer for Windows/macOS.

Legal Must comply with GDPR and copyright laws.

These NFRs shape architecture as much as functionality does.

🔹 Feasibility Study
Not every idea is realistic.
A feasibility study determines whether the proposed system is practical and
achievable given:

Lesson 2.2: Requirements Elicitation 7

 Technology (Do we have the tools?)

Time (Is there enough schedule?)

Resources (Do we have the team and budget?)

Regulatory constraints (Are there industry rules?)

For example: a small startup might not have the resources to implement
enterprise-level encryption.

🔹 Requirements Specification
The requirements specification (SRS) is the formal written agreement between
client and developers.

It must be:

Complete – nothing missing.

Consistent – no contradictions.

Unambiguous – each statement interpretable only one way.

Correct – matches what the client actually needs.

Think of it as the contract:

“We will build exactly what’s written here.”

It contains:

Functional requirements (the functional model).

Non-functional requirements.

🔹 Traceability
Traceability means cradle-to-grave accountability for every requirement.
Each requirement is traceable through:

Use cases

Design components (objects, modules)

Source code functions

Lesson 2.2: Requirements Elicitation 8

 Test cases

This enables change management — if one requirement changes, we can trace

every artifact affected.
Achieved through:

Numbering schemes (e.g., FR-01, NFR-12).

Requirements Traceability Matrix (RTM) — a table mapping requirements to

design and test elements.

🔹 Requirements Validation
After documentation, we must verify and validate requirements.

Type Question Focus

Verification “Are we building the product right?” Checks process correctness.

Validation “Are we building the right product?” Checks requirement correctness.

Validation involves both client and developers ensuring:

Completeness

Consistency

Clarity

Correctness

Realism

Verifiability

Traceability

Only after this step can we “lock in” the requirements baseline.

🧭 8️⃣ Requirements Elicitation Activities

Let’s move into how we actually perform elicitation in practice.

1️⃣ Identifying Actors

Lesson 2.2: Requirements Elicitation 9
 Actors are external entities that interact with the system:

End-users (people).

External systems (databases, APIs, payment services).

Identifying actors defines the system boundary — what’s inside vs. outside the
system.
You find actors by asking:

Who uses the system?

Who provides or consumes data?

Which external systems must it connect to?

2️⃣ Identifying Scenarios

Scenarios describe the system through interactions with actors.
They are instances of use cases — concrete examples of single user goals.

This table shows:

Actor: Matilda (Student) interacting with RegistrarSystem and FinanceSystem.

Step-by-step flow:

1. Matilda selects a course.

Lesson 2.2: Requirements Elicitation 10

 2. Systems validate holds and prerequisites.

3. Matilda receives confirmation.

This textual format communicates clearly with both clients and developers.

3️⃣ Identifying Use Cases

A use case is an abstraction of related scenarios.
Each use case is initiated by an actor and represents a user goal.

Why it matters:

Helps communicate with clients visually and textually.

Helps developers define scope and identify dependencies.

Each use case is documented in a table with:

Name, ID

Actors

Flow of events

Entry & exit conditions

Quality requirements

Traceability references (e.g., FR-17, NFR-28)

Lesson 2.2: Requirements Elicitation 11

 These examples illustrate full tables showing:

Participating actors.

Flow of events.

Conditions.

Performance requirements (e.g., “response time ≤ 20 seconds”).

Traceability links.

These serve as early documentation of expected system behavior.

4️⃣ Identifying Use Case Relationships

Use cases can relate in three ways:

Relationship Meaning

Include Common behavior factored out into a reusable sub-use case.

Extend Adds optional or exceptional behavior under certain conditions.

Inheritance One use case is a specialized version of another.

🔸 Include Example:

Lesson 2.2: Requirements Elicitation 12

 “RegisterCourse” includes “CheckPrerequisites” and “CheckForHolds”.
→ The base use case always executes the included ones.

🔸 Extend Example:

Lesson 2.2: Requirements Elicitation 13

 “ResponseTimeout” extends “RegisterCourse” when a system fails to respond.
→ Only triggered under special conditions (timeout).

🔸 Inheritance Example:

Lesson 2.2: Requirements Elicitation 14

 Rare, but can be used for subtypes like “RegisterGraduateCourse” inheriting from
“RegisterCourse”.

Lesson 2.2: Requirements Elicitation 15

 These visuals show actors (Student, RegistrarSystem, FinanceSystem) connected
to use cases with lines labeled include, extend, or inherits — illustrating system
structure and relationships.

5️⃣ Identifying Initial Analysis Objects

Now we move closer to analysis.

You find initial analysis objects by scanning every use case and scenario for
recurring nouns or real-world entities:

Student, Course, RegistrarSystem, FinanceSystem, Instructor.

This list becomes the starting glossary for your system’s object model — the
bridge to UML class diagrams.

Lesson 2.2: Requirements Elicitation 16

 6️⃣ Identifying Non-Functional Requirements
We revisit NFRs here to ensure they are explicitly documented.
This includes:

Usability (interface clarity)

Performance (response times)

Reliability (uptime)

Supportability (ease of maintenance)

Implementation, Interface, Operations, Packaging, Legal constraints.

Prioritizing these early prevents future rework.

7️⃣ Applying Agile Principles

Agile emphasizes:

Active client involvement (continuous feedback).

Capturing high-level requirements early.

Building minimum viable models quickly.

(“Good enough for this iteration.”)

Elicitation doesn’t need to be perfect — it needs to be validated and adaptable.

🎮 9️⃣ ARENA Case Study

(Refer to the “ARENA” diagrams in slides 51–58.)
ARENA is a recurring case study from Bruegge & Dutoit. It describes a system
that:

Supports virtual game communities.

Allows registration of games and players.

Organizes tournaments and tracks scores.

Provides frameworks for developers (game integration) and advertisers.

Lesson 2.2: Requirements Elicitation 17

 Example Use Cases in ARENA
Register New Player

Register New Game

Organize Tournament

Track Scores

Manage Ads

Each use case defines the interactions between users (players, organizers,
developers) and the system (ARENA framework).

Purpose of the Case Study

The ARENA example demonstrates:

How to apply elicitation to a complex, multi-actor domain.

How to structure requirements for different stakeholder types.

How to use use case diagrams to capture and communicate system

boundaries effectively.

🧾 10️⃣ Dorc Slayer Case Study (Exercise)

As practice:

Identify actors and system boundaries.

Define high-level use cases and relationships.

Then expand them into detailed use cases.

This helps you apply everything from this lecture in a practical setting.

🧠 11️⃣ Recap – Key Takeaways

Concept Summary

Elicitation Goal Discover what the client needs, not what you assume.

Outputs Functional & non-functional requirements, use cases, scenarios.

Lesson 2.2: Requirements Elicitation 18

 Concept Summary

Core Artifacts Requirements Specification, Traceability Matrix.

Tools Interviews, observations, UML use case diagrams.

Activities Identify actors, scenarios, use cases, relationships, and objects.

Case Studies ARENA and Dorc Slayer illustrate real-world application.

💬 Reflection Questions
1. Why is requirements elicitation an iterative process rather than linear?

2. How do functional and non-functional requirements differ in purpose and

format?

3. What is the role of traceability in managing system changes?

4. In what cases would an extend relationship be more appropriate than include?

5. How does Agile philosophy affect the way we perform elicitation?

Lesson 2.2: Requirements Elicitation 19