What are the main CPRE requirements elicitation techniques?

The principal techniques covered here are interviews, surveys, workshops, observation, apprenticing, document analysis, and brainstorming. The correct choice depends on the information source, stakeholder situation, and immediate objective.

What is the difference between elicitation and requirements documentation?

Elicitation obtains and develops information about needs, goals, constraints, and system context. Documentation represents that information in a requirement, model, glossary, scenario, or another work product.

When should interviews be used in requirements engineering?

Use interviews when one or a few stakeholders hold specialized knowledge, when detailed exploration is needed, or when immediate follow-up questions matter. They are less efficient than surveys for large populations.

When is a workshop better than an interview?

A workshop is preferable when several roles must interact, expose dependencies, establish shared terminology, or resolve conflicting expectations. An interview is stronger when knowledge is concentrated in one person.

Why is observation useful for requirements elicitation?

Observation reveals actual work, tacit knowledge, environmental factors, exceptions, and workarounds that users may omit or find difficult to explain. Follow-up questions may still be needed to understand motivation.

Is brainstorming a requirements validation technique?

No. Brainstorming generates candidate ideas and possible solutions. The ideas must later be analyzed, documented, and validated for relevance, feasibility, completeness, and stakeholder agreement.

Why should existing documents be analyzed during elicitation?

Documents can reveal regulations, contracts, policies, business rules, data, interfaces, and process information efficiently. They may be outdated or incomplete, so important findings should be clarified.

How should I choose an elicitation method in a CPRE exam scenario?

Identify the immediate objective and where the relevant knowledge resides. Select interviews for expert depth, surveys for broad comparable input, workshops for interaction, observation for hidden work, document analysis for recorded constraints, and brainstorming for idea generation.

CPRE requirements elicitation techniquesrequirements elicitation techniquesCPRE Foundation elicitation

Choosing the Right Requirements Elicitation Technique for CPRE Foundation Scenarios

CPRE requirements elicitation techniques are ways of obtaining and developing knowledge about stakeholder needs, the system context, desired capabilities, and constraints.

guide•10/6/2026•18 min read

Choosing the Right Requirements Elicitation Technique for CPRE Foundation Scenarios editorial illustration

CPRE requirements elicitation techniques are ways of obtaining and developing knowledge about stakeholder needs, the system context, desired capabilities, and constraints. In an IREB Foundation exam question, the technique name is rarely the real challenge. The important clue is usually the kind of evidence that is missing.

A passenger may describe a frustrating airport check-in, an operations manager may know why a queue forms, and a regulation may already define a mandatory retention period. These sources cannot be investigated effectively in exactly the same way. The Requirements Engineer therefore selects a method according to the source of knowledge, the intended result, the number of participants, and the amount of interaction required.

Use the missing evidence as the decision point

When reading a CPRE Foundation scenario, first identify what the Requirements Engineer cannot yet explain. The following distinctions are more useful than simply counting stakeholders.

Depth: A small number of people possess specialist knowledge, reasoning, or sensitive information. The task calls for probing and clarification.
Breadth: A large or distributed population must provide comparable information about usage, frequency, or preferences.
Interaction: Several roles hold connected or conflicting views and must hear, challenge, or reconcile one another.
Reality: The stated process may differ from operational behavior, or important knowledge may be tacit and embedded in routine work.
Recorded evidence: Relevant rules, obligations, interfaces, or historical decisions may already exist in documents and other artifacts.
Possibilities: The team has not yet explored a useful range of capabilities or solution ideas.

This framing prevents a common error: choosing a technique because it could produce some information rather than because it addresses the central uncertainty in the scenario.

Interviews: turn individual knowledge into examinable information

Requirements engineering interviews are purposeful conversations with one stakeholder or a small group. They work well when the knowledge is concentrated in an expert, when the subject is confidential, or when each answer may lead to a different follow-up question.

The structure can be adapted to the objective. A structured interview uses the same prepared questions for every participant and supports comparison. A semi-structured interview establishes planned topics while leaving room to investigate unexpected answers. An open interview gives the stakeholder more freedom to describe goals, concerns, and context before the Requirements Engineer narrows the discussion.

What makes an interview valuable

Immediate clarification of unfamiliar terminology.
Investigation of assumptions, motivations, decision rules, and exceptions.
Access to knowledge that is not recorded elsewhere.
Discovery of additional stakeholders or related requirements sources.

Imagine that a museum registrar asks for a system that “flags unusual acquisitions.” That statement is only a starting point. An interview could explore which attributes make an acquisition unusual, who decides, what evidence is required, what happens after a flag appears, and whether the rule differs for donations and purchases.

The limitation is perspective. An interview captures what the participant knows, remembers, believes, or wants. It may describe an ideal process rather than actual practice, and a confident expert may still represent only one department. Important findings may need comparison with other stakeholders, observation, or existing artifacts.

CPRE clue: A scenario featuring one domain expert, confidential information, or a need for adaptive follow-up generally points toward an interview rather than a large-scale questionnaire.

Surveys: measure patterns across a population

Surveys use written questions to collect information from many respondents. They are useful when users are geographically dispersed, difficult to convene, or numerous enough that individual conversations would be inefficient. Standardized questions make answers easier to compare.

A utility provider might survey customers about outage-notification channels, the frequency of missed alerts, and preferred contact methods. The results can show whether a problem is widespread and which options deserve further investigation. They usually cannot explain the complete circumstances of one customer’s missed notification.

Closed questions support aggregation, ranking, and frequency estimates. Open questions may reveal unexpected concerns, but they often lack the context and follow-up available in an interview. Survey quality also depends on clear wording, appropriate sampling, sufficient response, and consistent interpretation of terms.

A survey response is evidence, not automatic organizational agreement. A high percentage selecting an option does not prove that the option is feasible, legally permitted, or sufficiently precise as a requirement. Unexpected or important results may lead to interviews, observation, or a workshop.

CPRE clue: Large respondent numbers plus a need for independent, comparable answers favor a survey. A complex exception that requires explanation favors another technique.

Workshops: expose relationships between viewpoints

A workshop is a facilitated collaborative session with a defined purpose. Its distinguishing characteristic is interaction. Participants can react to one another, challenge assumptions, reveal dependencies, and establish shared terminology while the topic is being discussed.

Consider a hospital discharge process. Clinical staff focus on patient safety, finance needs complete billing information, and transport coordinators need reliable timing. Separate interviews would capture each perspective. A workshop can show where the perspectives intersect, which conditions conflict, and which terms need a common definition.

What a workshop needs

A clear objective and an agreed expected outcome.
Participants who represent the relevant viewpoints.
Facilitation that manages dominance, digression, and unresolved disagreement.
A visible record of decisions, assumptions, open questions, and conflicts.

Workshops are not automatically better because many stakeholders exist. A very large population may be suitable for a survey, while a small group with no shared decision to make may be better handled through separate interviews. Group pressure, missing participants, or unclear authority can also create an appearance of agreement without resolving the underlying issue.

CPRE clue: If the scenario emphasizes conflicting roles, shared meaning, dependencies, or collaborative definition of a process, the interaction supplied by a workshop is usually the decisive feature.

Observation: investigate behavior rather than recollection

Observation examines work in its operational setting. It is especially useful when users omit routine actions, when workarounds have become habitual, or when environmental conditions influence the task. A Requirements Engineer may see interruptions, handoffs, physical constraints, informal notes, and exception handling that no participant thought to mention.

For example, a retail employee may say that stock adjustments are entered directly into a terminal. Watching the task could reveal that the employee first records quantities on a paper tally because the terminal is located away from the shelves. The observed workaround may explain inaccurate inventory more effectively than a general interview response.

Observation requires a defined focus and disciplined recording. The Requirements Engineer should separate what was seen from assumptions about why it happened. The presence of an observer can influence behavior, and privacy, safety, security, or access restrictions may limit the technique. Observation shows behavior in context, but follow-up questioning may still be necessary to understand motivation or desired future behavior.

Document analysis: start with available authority and context

Document analysis examines existing artifacts for potentially relevant requirements information. Possible sources include regulations, contracts, policies, manuals, process descriptions, forms, reports, interface definitions, support records, and legacy-system material.

This method is particularly useful when obligations or technical boundaries are already recorded. Before designing a new customs declaration service, for example, the Requirements Engineer could inspect applicable forms, interface specifications, and organizational policies to identify data fields, deadlines, terminology, and constraints.

Existing material is evidence, not guaranteed truth. A document may be obsolete, contradictory, incomplete, written for another audience, or concerned with the prescribed process rather than actual practice. Check its origin, purpose, date, owner, and relationship to other sources. Important interpretations still require clarification and validation.

Brainstorming: widen the solution space

Brainstorming helps a group generate candidate capabilities, improvements, or solution ideas when the future direction is not yet well formed. Participants initially create possibilities and defer detailed criticism until the generation phase is complete.

A city archive exploring a public access portal might produce ideas such as multilingual search, appointment scheduling, digital exhibits, or researcher workspaces. These proposals broaden the discussion; they do not prove that any proposal is necessary, feasible, affordable, or accepted by affected stakeholders.

Brainstorming is therefore different from validation and from discovering an authoritative rule. It is a useful starting technique when alternatives are missing, but its output must later be analyzed, documented, prioritized where appropriate, and validated.

One technique can reveal several requirement types

Do not memorize a fixed mapping such as “interview equals functional requirement” or “document analysis equals constraint.” Any method can reveal different categories of information. An interview may uncover a business goal, quality expectation, business rule, constraint, or functional need. Observation may expose usability concerns as well as process behavior. A contract may contain interface requirements and timing constraints.

The technique influences the evidence collected; it does not perform the Requirements Engineer’s classification work. A statement such as “The dashboard must be easy to use” expresses an expectation. It still needs clarification about users, tasks, context, and acceptable quality before it can be represented and checked properly.

Comparison: match the evidence gap to the method

CPRE requirements elicitation techniques by information problem
Information problem	Suitable method	Typical result	Main caution
A specialist holds detailed or sensitive knowledge	Interview	Explanations, assumptions, rules, goals, and exceptions	One perspective may not represent the organization
Many users need to answer comparable questions	Survey	Patterns, frequencies, rankings, and broad preferences	Limited context and possible sampling or wording bias
Roles have connected or conflicting views	Workshop	Shared terminology, dependencies, decisions, and open conflicts	Group dynamics may conceal disagreement
Actual work may differ from reported work	Observation	Task behavior, workarounds, interruptions, and tacit knowledge	Behavior is visible, but motivation may remain unclear
Rules or interfaces already exist in artifacts	Document analysis	Recorded obligations, data, terminology, and boundaries	Artifacts may be outdated or describe only the intended process
The team lacks alternative future possibilities	Brainstorming	Candidate capabilities and solution ideas	Ideas are not validated requirements

Keep elicitation, documentation, and validation separate

Suppose an analyst explains a payroll exception during an interview. Obtaining that explanation is elicitation. Recording the exception as a business rule or scenario is documentation. Asking relevant stakeholders to review its meaning, consistency, feasibility, and completeness is validation.

This distinction is central to CPRE elicitation questions. A method may produce valuable information without resolving ambiguity or proving agreement. When a scenario asks for the best technique, select the method that addresses the immediate evidence gap, then remember that the resulting information still has to be interpreted, represented, and checked.

Scenario clue map

Start with the information gap

Use the defining clue, not the most familiar method.

Knowledge is concentratedOne expert or a small group holds specialist rules, goals, or assumptions.

Interview

Roles disagreeSeveral perspectives must interact to clarify terminology, dependencies, or conflict.

Workshop

Work is hiddenRoutine behavior, exceptions, or workarounds are difficult for users to describe.

Observation

Input must scaleMany or distributed respondents need to provide comparable answers.

Survey

Evidence already existsRules, constraints, interfaces, or processes are recorded in artifacts.

Document analysis

Possibilities are missingThe team needs alternatives before it can assess or refine candidate ideas.

Brainstorming

Boundary check: the selected method obtains information; documentation represents it, and validation checks the resulting work product.

Observation: discovering work as it really happens

Observation examines stakeholders while they perform tasks in their operational environment. It is valuable when requirements are embedded in habits, physical surroundings, tacit knowledge, or workarounds that users may not mention in an interview.

Direct observation can reveal task sequences, interruptions, information exchanges, tools, environmental constraints, and exceptional situations. It is particularly useful for warehouse workers, nurses, maintenance technicians, and call-center agents. People often omit routine actions because those actions seem obvious to them.

The Requirements Engineer should define a focus before observing and distinguish what was actually seen from assumptions about why it happened. The presence of an observer may influence behavior. Access, privacy, safety, and security restrictions can also limit the technique.

Apprenticing and video-supported observation

Apprenticing is a participatory form of observation. The Requirements Engineer spends time in the work environment as a novice while experienced users explain how the work is done. Basic questions from the learner can expose implicit knowledge, but the Requirements Engineer should not take over the expert’s role.

Video may support later review of complex activities where permission and privacy requirements allow it. Neither video nor direct observation removes the need to ask questions. Observation shows what happens; it may not explain the underlying motivation, business rule, or desired future state.

Example: Operators claim that an existing scheduling screen is adequate, yet they regularly write values on paper before entering them. Observation is the strongest starting technique because the workaround may be difficult to articulate. Interviews afterward can help explain its cause.

Document analysis: using existing artifacts as requirements sources

Document analysis examines artifacts that contain relevant information. Sources may include laws, regulations, contracts, policies, process descriptions, manuals, forms, reports, support records, interface specifications, and legacy-system descriptions.

This method is efficient when an organization already has substantial information. It can reveal terminology, business rules, data items, interfaces, constraints, and historical decisions before stakeholder time is requested. It is often a sensible first step for regulated systems, supplier interfaces, or replacement of an existing system.

Documents are not automatically complete or authoritative. They may be outdated, inconsistent, written for another purpose, or describe an intended process rather than actual practice. The Requirements Engineer should consider the document’s origin, purpose, age, and responsible owner, then clarify significant findings.

Example: A payment service must comply with an internal security policy and an external regulation. Document analysis should identify the recorded constraints early. Interviews with legal and security stakeholders can then clarify ambiguous interpretations.

Choosing by knowledge characteristics

No technique guarantees a particular requirements type. An interview can uncover functional requirements, quality requirements, goals, constraints, or business rules. Observation can reveal functional behavior and usability problems. Document analysis can expose rules and constraints. The technique influences what is likely to be discovered, but the Requirements Engineer still needs to classify, refine, and validate the result.

Consider explicit and tacit knowledge. Explicit knowledge is recorded or readily explained. Tacit knowledge is embedded in experience and routine and may be difficult for an expert to articulate. Documents and interviews are often effective for explicit knowledge; observation and apprenticing are especially useful for tacit knowledge.

Also distinguish current-state investigation from future-state exploration. Observation and document analysis usually investigate how work or systems operate now. Brainstorming and some workshops can explore future possibilities. Interviews and surveys can support either purpose, depending on the questions asked.

Combining methods without confusing their purposes

Effective requirements elicitation is often iterative rather than dependent on one technique. A useful sequence is a set of complementary roles, not a mandatory universal process.

Review available evidence: Examine documents, records, interfaces, and existing work products to learn terminology and identify gaps.
Investigate stakeholder knowledge: Interview selected people or survey a broad population, depending on the source and scale of the information.
Examine actual work: Observe operations when descriptions appear incomplete or tacit knowledge is important.
Bring perspectives together: Use a workshop when several roles must build shared understanding or resolve conflict.
Expand possibilities: Use brainstorming when the goal is to generate alternatives rather than confirm an existing requirement.
Represent and check the result: Document the information and validate it with relevant stakeholders.

A regulated project may begin with documents. A new product with little existing material may begin with interviews or a workshop. A process with a large gap between stated and actual behavior may prioritize observation.

Triangulation increases confidence

When a requirement is important or uncertain, compare evidence from different sources. A procedure may say that every refund needs supervisor approval, an interviewee may describe automatic approval for small refunds, and observation may reveal a workaround. The contradiction is a signal for further elicitation, not an invitation to select one source without investigation.

Triangulation helps distinguish the prescribed process from the actual process, one person’s preference from an organizational requirement, a proposed solution from an underlying goal, a general rule from an exception, and a current limitation from a genuine requirement.

Record assumptions, unresolved issues, and conflicting statements. Do not silently turn uncertainty into a precise-looking requirement.

Common selection errors

Choosing a workshop merely because many stakeholders exist

A large population does not automatically justify a workshop. If the objective is independent, comparable input from hundreds of users, a survey may be better. Workshops are strongest when interaction and shared understanding are required and the group can be facilitated effectively.

Treating an interview answer as complete

“The system should be user-friendly” expresses an expectation but is not yet a sufficiently precise, validated requirement. Follow-up questions, suitable documentation, and validation are still needed.

Using observation to infer motivation

Observation shows what happens in context. It may not reveal why it happens. Ask users to explain significant observations and compare the explanation with other evidence.

Assuming documents are always authoritative

Existing artifacts may be obsolete, contradictory, or intended for another purpose. Check provenance and confirm important conclusions with responsible stakeholders.

Using brainstorming as validation

Brainstorming produces candidate ideas. It does not establish correctness, feasibility, completeness, or agreement.

Confusing elicitation with prioritization

A stakeholder may identify a requirement during an interview, but deciding whether it outranks another requirement is a separate prioritization activity.

Evidence cycle

Combine methods when one view is not enough

This is a reasoning model, not a compulsory sequence. Move between sources as uncertainty appears.

1. Establish context

Review artifacts to identify vocabulary, constraints, interfaces, and missing information.

2. Gather viewpoints

Use interviews for depth or surveys for broad, comparable stakeholder input.

3. Check reality

Observe operational work when routine behavior, exceptions, or workarounds may be hidden.

4. Reconcile views

Use a workshop to expose contradictions and build shared understanding among roles.

Triangulation signal

If a procedure, an interview, and observed behavior disagree, preserve the contradiction as an issue for clarification. Do not silently choose one source.

Elicit informationClassify and documentValidate the result

CPRE-style scenarios: choose the best starting point

Scenario 1: distributed user preferences

A digital library wants input from thousands of registered users about the usefulness of search filters. The users are distributed across several regions, and the results must be comparable.

Best starting technique: Survey. It provides broad, structured input efficiently. Follow-up interviews can investigate unusual or important findings.

Scenario 2: hidden exception handling

Dispatchers report that route planning works well, but late deliveries continue. Managers cannot explain the problem, and dispatchers perform manual steps during disruptions.

Best starting technique: Observation, potentially supported by permitted video review. The central issue is actual behavior and exception handling, not simply stated expectations.

Scenario 3: conflicting departmental rules

Finance requires approval before shipment, while the warehouse sometimes ships first for urgent orders. The new system must support an agreed process.

Best starting technique: Workshop with representatives of both roles and other affected stakeholders. Direct interaction is needed to expose the conflict and create shared understanding.

Scenario 4: specialized undocumented knowledge

A laboratory system must support a calculation used by three experienced analysts. The calculation is undocumented, and the analysts use similar but different terminology.

Best starting technique: Interviews with the analysts, followed by validation and possibly a workshop. The knowledge is concentrated, but differences must be made explicit.

Scenario 5: contractual interface constraints

A supplier is replacing an interface governed by a contract specifying response times, data fields, and error handling.

Best starting technique: Document analysis of the contract and interface material, followed by interviews to clarify ambiguous or outdated clauses.

Scenario 6: an unformulated opportunity

A team wants to improve a public transport application but has no agreed list of new services. Participants must first produce alternatives before assessing them.

Best starting technique: Brainstorming. The immediate purpose is idea generation, not confirmation of an existing requirement.

Comparison of requirements elicitation techniques

Technique	Primary purpose	Suitable sources or stakeholders	Strengths	Limitations
Interview	Explore knowledge, goals, expectations, rules, and concerns in depth.	Selected experts, users, customers, owners, regulators, or individual stakeholders.	Flexible and supports immediate follow-up.	Time-consuming; may reflect memory, personal preference, or an idealized process.
Survey	Collect broad, comparable input.	Large or geographically distributed populations.	Efficient at scale and useful for measuring common issues.	Limited depth; ambiguous questions and low response rates can distort results.
Workshop	Create shared understanding and resolve differences.	Representatives of multiple roles or departments.	Exposes dependencies and enables immediate clarification.	Requires preparation and facilitation; group dynamics may suppress views.
Observation	Discover actual behavior, tacit knowledge, exceptions, and workarounds.	Users performing operational tasks in context.	Reveals what people do rather than only what they remember.	Requires access and time; does not always explain motivation.
Apprenticing	Learn complex practical work through participatory observation.	Experienced users who can demonstrate and explain their work.	Exposes implicit knowledge through participation.	Requires significant access; the learner must not take over the role.
Document analysis	Identify recorded rules, processes, data, interfaces, and constraints.	Regulations, contracts, policies, manuals, forms, reports, and legacy specifications.	Uses existing evidence and can be an efficient starting point.	Artifacts may be incomplete, outdated, inconsistent, or idealized.
Brainstorming	Generate alternatives and innovative possibilities.	Stakeholders and team members with relevant domain perspectives.	Produces many ideas quickly and encourages exploration.	Ideas are not validated requirements and may be affected by group dynamics.

After elicitation: document and validate

The output of elicitation is information, not automatically a finished requirement. Depending on the situation, it may be represented as a natural-language requirement, a template-based requirement, a model, a glossary entry, a business rule, a scenario, or an issue requiring further investigation.

Documentation makes information understandable and usable. Natural language is accessible but can be ambiguous. Templates encourage consistent structure. Models can express relationships, behavior, data, or processes more clearly than prose. These are documentation choices, not elicitation techniques.

Validation then checks whether the documented result reflects stakeholder intent and satisfies relevant quality criteria. A review may reveal ambiguity, inconsistency, omission, infeasibility, or a mismatch with actual work. If reviewers disagree about the meaning of “authorized user,” another interview or workshop may be needed before the requirement can be revised.

This feedback loop explains why requirements engineering is not a one-time handoff. Elicitation, documentation, validation, negotiation, and requirements management influence one another. New information may reveal ambiguity or conflict, and changes should be controlled and communicated.

Rapid revision

Six signals, six starting choices

Distributed users

Thousands of users need comparable views on search filters.

Survey — breadth

Hidden exception work

Dispatchers use manual steps during late-delivery disruptions.

Observation — actual behavior

Conflicting rules

Finance and warehouse staff apply different urgent-shipment rules.

Workshop — interaction

Specialist knowledge

Three analysts hold an undocumented calculation.

Interview — depth

Recorded obligations

A contract specifies interface timing, data, and errors.

Document analysis — constraints

Unformed opportunity

A team needs alternative services before assessing them.

Brainstorming — possibilities

Exam rule: select the method that addresses the central information gap, not merely one that could produce some information.

Practical selection checklist

Use this checklist when a CPRE Foundation scenario asks for the most appropriate technique.

Identify the immediate objective. Is the team gathering facts, understanding behavior, generating ideas, comparing opinions, resolving conflict, or inspecting constraints?
Locate the information source. Is the knowledge held by one expert, many users, several conflicting roles, current work, or existing artifacts?
Check whether knowledge is explicit or tacit. Recorded information points toward document analysis; routine knowledge may require observation or apprenticing.
Assess the needed interaction. Interviews provide depth with selected people, surveys provide breadth, and workshops enable collaborative understanding.
Separate exploration from confirmation. Brainstorming expands possibilities. It does not validate the resulting ideas.
Consider practical constraints. Account for location, time, privacy, safety, access, availability, and participant numbers.
Plan what happens next. Decide how findings will be documented, clarified, validated, traced, and managed.
Look for a blind spot. Combine methods when recorded information, stated expectations, and actual behavior may differ.

For a single-choice question, choose the method that addresses the central problem, not merely one that could produce some information.

Interview: one or a few stakeholders hold detailed knowledge.
Survey: many or distributed respondents must provide comparable input.
Workshop: several perspectives must interact to reach shared understanding.
Observation: hidden behavior, tacit knowledge, exceptions, or workarounds matter.
Document analysis: relevant rules, constraints, or interfaces are already recorded.
Brainstorming: the immediate goal is to generate alternatives.

Keep the concept boundary clear

Elicitation obtains and develops information. Documentation represents that information in an appropriate work product. Validation checks whether the documented result is suitable, understandable, consistent, feasible, and aligned with stakeholder intent.

A strong exam answer follows the same order: identify the information gap, match it to the technique’s characteristic strength, and then remember that the result still needs analysis and validation. The technique is a starting point, not a guarantee of a complete requirement.

CPRE Foundation method compass

Read the clue, then test the fit

Use the dominant scenario signal as your first filter. The method shown is a starting point, not a guarantee that one technique will be sufficient.

CPRE requirements elicitation technique decision grid
Scenario signal	Likely first move	Why it fits	Check before relying on it
A calculation or rule lives with a few specialists.	Interview	Enables probing of terminology, assumptions, and exceptions.	One person’s account may not represent the whole organization.
A large or distributed population must be compared.	Survey	Standard questions support broad, measurable input.	Wording, sampling, and response rates can distort findings.
Different roles apply incompatible rules.	Workshop	Participants can challenge meanings and expose dependencies together.	Facilitation and representation must be adequate.
Reported work differs from observed work.	Observation	Shows routines, interruptions, exceptions, and workarounds in context.	Observation may show what happens without explaining why.
Rules or interface obligations are already recorded.	Document analysis	Surfaces constraints, terminology, data, and recorded decisions efficiently.	Verify currency, ownership, consistency, and intended versus actual practice.
The team needs alternatives before evaluation.	Brainstorming	Expands the pool of candidate capabilities or solutions.	Ideas still require analysis, documentation, and validation.

Laura Kovach

EdTech and certification trends analyst at FindExams

Substack

Medium