SCHOOL OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING

Requirement Engineering (SEng3051 )
CHAPTER 8
Requirement Engineering Techniques
By: Mekuanent M.

1
 8. Methods for RE
At the end of this chapter you abele to:-
 Understood Requirements Elicitation Methods
 Know Requirements Analysis & Negotiation Methods
 Understood Requirements Documentation Methods
 List Requirements Validation Methods
 Understood Requirements Management Methods
 Identify and understood Viewpoint-oriented Requirements
Methods and their type

2
 Conn...
“Methods for RE” usually refers to methods used in Requirements Engineering.
There are a clear, organized list of the main categories and commonly used methods.
8.1. Requirements Elicitation Methods
Used to discover and gather requirements from stakeholders.
8.1.1 Interactive Methods: Interactive methods involve direct communication with
stakeholders to gather requirements.
They include interviews, workshops/JAD sessions, focus groups, brainstorming, and
surveys, each suited for different types of requirement discovery.

3
 [Link] Interview
• A one-to-one or small group discussion between the analyst and stakeholders to understand
their needs. It may
A. Structured Interviews
• Predefined set of fixed questions
• Same questions asked to all participants
• Formal and controlled
B. Semi-Structured Interviews
• Mix of prepared questions and open discussion
• Allows follow-up questions
• Most commonly used method

4
Conn…
C. Unstructured Interviews
• No fixed questions
• Free-flow conversation
• Informal
• Encourages creativity
• Hard to analyze
• Time-consuming

5
 [Link] Workshops / JAD Sessions

• A workshop is a structured, face-to-face meeting where the business analyst,

developers, and multiple stakeholders come together to discuss and gather
requirements.
Key features of workshop
 Interactive group meeting
 Faster than doing separate interviews
 Encourages collaboration and idea sharing
 Helps resolve conflicts between stakeholders
 Produces agreed requirements quickly

6
• JAD is a special type of workshop that is more formal and structured.
It brings users, clients, and developers together to work intensively on
defining system requirements.
Key Features:
• Highly structured
• Led by a trained JAD facilitator
• Involves experts (SMEs), users, analysts, developers
• Produces detailed and documented requirements quickly
• Usually happens over 2–5 days in dedicated sessions
Benefits:
• Reduces time to gather requirements
• Minimizes misunderstandings
• Ensures all stakeholders agree
• Produces high-quality requirements
7
 Difference Between Workshops & JAD Sessions

Workshops JAD Sessions

General group meeting for discussions Highly structured, formal sessions

No strict format Uses facilitator, scribe, agenda

Focus on broad ideas Focus on detailed system requirements

Less intensive More intensive, longer sessions

Used in many domains Mainly in system development

8
[Link] Focus Groups
A moderated discussion with selected users to gather opinions, expectations, and
feedback.
Characteristics
• 6–10 participants
• Guided by a moderator
• Encourages discussion and interaction
• Good for usability requirements
• Dominant participants may influence others

9
 [Link] Brainstorming
• A creative group technique used to generate ideas and possible requirements
and it used to Encourages innovation. But Ideas may be unrealistic.
Rules:
• No criticism
• Encourage all ideas
• Quantity over quality initially
Process:
• Idea generation
• Idea grouping
• Evaluation

10
[Link] Surveys & Questionnaires
A method of collecting requirements by asking stakeholders to respond to written
questions.

• Closed-ended (Yes/No,):- Closed-ended questions are questions that have fixed,

predefined answers. The respondent must choose from the given options.

• Open-ended:- Open-ended questions allow respondents to answer freely in their

own words without predefined options.

11
8.1.2 Observational Methods

A. Job Shadowing:- is an observational method where a researcher or learner

closely follows a professional during their normal workday.

• The observer watches how tasks are performed, decisions are made, and how the
worker interacts with others and their environment.

• The observer does not interfere but learns through direct exposure to real work
situations.

12
 B. Ethnographic Studies
• Ethnographic studies involve long-term observation of people in their natural social or
cultural setting.
• The researcher immerses themselves in the group or community to understand
behaviors, beliefs, customs, and interactions from the participants’ perspective.
C. Field Observations
• Field observation is a method where behavior is observed and recorded in a real-world
setting without manipulation or control by the researcher.
• The observer may remain unobtrusive to ensure natural behavior.
• It is useful for studying how individuals or groups act in everyday environments such
as schools, workplaces, or public spaces.
13
8.1.2 Research-Based Methods
• Research-Based Methods
• Document analysis
• Market research & competitive analysis
• User feedback analysis
8.1.2 Model-Based Methods
• Use cases / user stories
• UML diagrams
• Process modeling (DFD, BPMN)

14
 8.2 Requirements Analysis & Negotiation Methods
• Used to refine, structure, and resolve conflicts in requirements. Such as:-
8.2.1 Prioritization techniques: Prioritization decides which backlog items should
be worked on first based on value, urgency, and effort.
A. MoSCoW groups requirements into four priority levels.
 M – Must Have
Critical features without which the system fails.
 S – Should Have
Important but not critical; workaround exists.
 C – Could Have
Nice-to-have features; low impact if skipped.
 W – Won’t Have (this release)
Not included in the current version.
15
 B. WSJF (Weighted Shortest Job First)
• WSJF prioritizes work by maximizing business value and minimizing time.
WSJF = Cost of Delay / Job Size
Cost of Delay includes:
• Business value
• Time criticality
• Risk reduction or opportunity enablement
Feature Cost of Delay Job Size WSJF
A 20 5 4
B 15 3 5 ← higher priority

16
 8.3. Requirements Documentation Methods
• Ways to represent and record requirements.
A. SRS (Software Requirements Specification)
A formal document that clearly defines functional and non-functional requirements
of a system.
B. User Stories / Acceptance Criteria
Short, user-focused statements describing what a user needs and why.
Acceptance criteria define conditions that must be met for the story to be considered
complete.
C. Use Case Specifications
Detailed descriptions of interactions between users (actors) and the system.
They capture main flows, alternate flows, and exceptions for specific functionalities.

17
D. Models and Diagrams (UML, ERD)
 Visual representations that show system structure, data relationships, or business
processes.
 They help stakeholders quickly understand complex requirements and
workflows.
E. Wireframes & Mockups
Simple visual layouts showing screen structure and user interface elements.
They focus on layout and usability rather than full design or functionality.
F. Prototypes (Low or High Fidelity)
Interactive representations of the system used to validate requirements early.
Low-fidelity prototypes are rough sketches, while high-fidelity prototypes closely
resemble the final product.
18
8.4 Requirements Validation Methods
• Used to check requirements for quality, correctness, and completeness.
A. Reviews & walkthroughs
A structured or semi-structured examination of requirements documents by
stakeholders, analysts, developers, and testers.
How it validates requirements:
• Checks clarity, consistency, and completeness of requirements
• Identifies ambiguities, conflicts, and missing requirements
• Ensures requirements align with business goals and stakeholder expectations
• Walkthroughs allow authors to explain requirements step-by-step and receive feedback
Key strength: Early detection of errors at low cost.
19
 B. Prototyping
Creating a preliminary version or mock-up of the system (e.g., UI screens or
workflows) to represent requirements.

How it validates requirements:

• Helps stakeholders visualize requirements

• Confirms correctness of functional and usability requirements

• Reveals missing or misunderstood requirements, especially user interface needs

• Encourages stakeholder feedback and refinement

Key strength: Reduces misinterpretation by making requirements tangible.

20
C. Model validation
Verifying requirements models such as use case diagrams, data models, process
flows, or UML diagrams.

How it validates requirements:

• Ensures models are accurate, consistent, and complete

• Confirms relationships, rules, and constraints are logically correct

• Detects gaps between different models (e.g., data vs. process models)

Key strength: Validates complex requirements in a structured and visual way.

21
D. Simulation
Executing models or scenarios to observe how the system would behave under
defined conditions.

How it validates requirements:

• Tests dynamic behavior of requirements over time

• Validates business rules, workflows, and performance constraints

• Identifies logical errors or unrealistic assumptions

Key strength: Allows “what-if” analysis before actual system development.

22
E. Acceptance criteria testing
Validating requirements against predefined acceptance criteria that specify
conditions for success.

How it validates requirements:

• Confirms requirements are testable and measurable

• Ensures requirements meet business and user expectations

• Validates completeness by checking all criteria are covered

Key strength: Directly links requirements to verification and testing.

23
F. Stakeholder approval sessions
Formal meetings where stakeholders review and formally approve requirements.

How it validates requirements:

• Confirms correctness and alignment with stakeholder needs

• Ensures completeness from a business and operational perspective

• Provides official sign-off, reducing future disputes

Key strength: Establishes shared understanding and accountability.

24
8.5 Requirements Management Methods
Used to track, update, and maintain requirements throughout the project.
A. Version Control for Requirements
Version control means keeping track of every change made to requirements over time, just
like version control for code. It used to:-

• Saves multiple versions of each requirement (R1 v1, R1 v2, etc.)

• Records who changed it, when, and why

• Allows rollback to older versions

• Enables comparison between versions

• Prevents accidental overwriting of requirements

25
B. Traceability Matrices
A traceability matrix links each requirement to design, implementation, and testing
elements.

Example: Requirement R1 → Design D1 → Code C1 → Test Case T1

Traceability Matrices used to :-

• Ensures no requirement is forgotten
• Helps identify impact when a requirement changes
• Supports verification & validation
Forward traceability (R → Design → Code → Test)
Backward traceability (Test → Code → Design → R)

26
C. Change Control Processes
A structured method for handling changes to requirements.
Steps for change control process:
• A change request (CR) is submitted

• Requirement Change is evaluated

• Impact analysis (cost/time/quality)

• Approval or rejection

• Requirements documents updated

• Change communicated to the team

change control process to avoid uncontrolled changes (“scope creep”).

27
What is scoop creeping?
Scope Creep means uncontrolled or unplanned growth of project scope when new
features, tasks, or requirements keep getting added without proper review, approval,
or change control.

Scope creep = adding more work to a project than originally planned, without
adjusting time, cost, or resources.

If these changes are accepted without updating timeline/budget, it becomes scope

creep.

28
Why Does Scope Creep Happen?
Scope Creep can Happen when:-
• Stakeholders keep requesting “small changes”
• Requirements not clearly defined
• No formal change control process
• Poor communication
• Lack of documentation
• Client keeps adding new features after the project starts

29
Effects of Scope Creep
• Project delays
• Increased cost
• Team stress
• Lower product quality
• Missed deadlines
How to Prevent Scope Creep
• Clear and complete requirements
• Defined scope statement
• Formal change control process
• Stakeholder approvals
• Regular communication
• Proper documentation and version control

30
 D. Baseline management
A baseline is a frozen set of verified requirements at a specific point in time.
It used to Avoids confusion over which requirements are final during development.
Once baselined:
• Requirements cannot change without formal approval
• Provides a stable reference for design & development
Types of baselines:
• Requirements baseline
• Design baseline
• Test baseline

31
“Freeze approved requirements” means locking or fixing the requirements so
that no one can change them anymore without formal approval.

When requirements are frozen, they become final and unchangeable unless a
formal change request is made.

We freeze requirements to make sure the development team works on a stable
and confirmed set of requirements.

32
Cont.…
• Example
Before development starts, the team agrees on these features:
• Login
• Dashboard
• Profile page
Once they are reviewed and approved, they are frozen. meaning:
• No one can suddenly say “Add a chat feature”
• No one can modify or remove existing requirements
• Any change must go through change control

33
 What happens after requirements are frozen?
• They form the Requirements Baseline

• Project planning, design, coding, and testing rely on this baseline

• Changes require formal approval (impact analysis, cost/time review)

Why is freezing important?
• Avoids scope creep
• Prevents confusion between team members
• Ensures clear planning
• Controls cost and schedule
• sure the development team works on a stable and confirmed set of requirements.

34
8.6 Viewpoint-oriented Requirements Methods

• Viewpoint-Oriented Requirements Methods are techniques used in Requirements

Engineering to gather and analyze requirements by considering the perspectives
(viewpoints) of different stakeholders.

• Viewpoint-oriented methods treat each stakeholder group as a separate

viewpoint and collect requirements from each one individually, because every
group sees the system differently.

35
 Why Viewpoint Methods Are Needed
In any project, different people have different needs:
• Managers
• Users
• Developers
• Customers
• Regulators
• Support staff
A viewpoint method ensures everyone’s concerns are captured, not just the loudest or
highest-ranking person.

36
Example
For a Hospital Management System:

• Doctors’ viewpoint: want patient history quickly

• Nurses’ viewpoint: need medication schedules

• Receptionists’ viewpoint: need appointment management

• Administrators’ viewpoint: want reports & billing

• Government viewpoint: requires privacy compliance

Each viewpoint provides different requirements.

37
Types of Viewpoints (according to various methods)
1. Interactors
• People or systems that interact directly with the software.
(e.g., users)
2. Indirect Stakeholders
• People who influence requirements but do not use the system.
(e.g., managers)
3. Domain Viewpoints
• Rules, regulations, laws, and domain knowledge.
(e.g., safety standards, legal requirements)

38
Benefits of Viewpoint-Oriented Methods

• Ensures complete requirements

• Improves clarity of stakeholder needs

• Helps identify conflicts early

• Reduces missing requirements

• Better communication among stakeholders

39
Who Are Indirect Stakeholders?

• Indirect stakeholders are people or groups who do not directly use the system, but
their decisions, interests, rules, or responsibilities affect the requirements of the
system.

• They influence what the system must or must not do, even though they don’t
interact with it daily.

40
Key Characteristics of Indirect Stakeholders
They don’t operate the system themselves
(not end-users)
They have authority or influence
Their input affects design, features, rules, and constraints.
They can impose requirements
• Security rules
• Legal constraints
• Business goals
• Policies
• Budget limits
Their viewpoint is essential
Ignoring them can cause project failure.

41
Why Indirect Stakeholders Matter
• If their needs are ignored:
• System may violate laws
• Project may exceed budget
• Business goals might be missed
• High-level features may get rejected later
They ensure the system aligns with:
• Business strategies

• Legal constraints

• Organizational rules

42
43
Quiz 3
1. What is Viewpoint-oriented Requirements Methods?
2. Why requirements freezing is important?
3. How to Prevent Scope Creep? Write at least four(4).

44