CCBA Requirements Elicitation and Collaboration 2 — Questions and Answers
Question 1: What is a 'prototype' primarily used for during requirements elicitation?
- To replace formal requirements documentation
- To provide stakeholders with a tangible model that helps them articulate and validate requirements (Correct answer)
- To test the performance of the final system
- To train end users before go-live
Correct answer: To provide stakeholders with a tangible model that helps them articulate and validate requirements
Prototypes give stakeholders something concrete to react to, helping them articulate needs they couldn't express abstractly and validating that the business analyst has understood requirements correctly.
Prototyping (creating low-fidelity or high-fidelity models of a solution) is an elicitation technique that helps stakeholders provide feedback on proposed functionality. When stakeholders see and interact with a prototype, they can identify what is correct, what is missing, and what is wrong much more effectively than when reviewing text-based requirements. Prototypes are especially valuable for UI requirements and complex workflows.
Question 2: During requirements elicitation, a key stakeholder consistently contradicts themselves. What should the business analyst do FIRST?
- Escalate to the project manager immediately
- Adopt the most recent statement and discard earlier ones
- Seek clarification by asking the stakeholder to explain the apparent contradiction (Correct answer)
- Document both contradictory statements and move on
Correct answer: Seek clarification by asking the stakeholder to explain the apparent contradiction
The first step is always to seek clarification directly with the stakeholder — contradictions often reflect complexity, context differences, or evolving understanding that needs to be explored.
When a stakeholder's statements appear contradictory, the business analyst should probe for clarification. Contradictions may arise from different contexts (a requirement that applies in some scenarios but not others), changing understanding as the stakeholder thinks through the problem, or genuine ambiguity. Direct, respectful inquiry ('Help me understand how these two statements work together') usually resolves apparent contradictions.
Question 3: In requirements elicitation, what is the primary purpose of 'mind mapping'?
- To create a formal hierarchical requirements document
- To visually brainstorm and organize complex topics and their relationships (Correct answer)
- To map database entity relationships
- To assign requirements to team members
Correct answer: To visually brainstorm and organize complex topics and their relationships
Mind mapping is a visual brainstorming technique that helps participants explore and organize complex topics by branching related concepts from a central idea.
Mind mapping supports elicitation by providing a flexible, non-linear structure for exploring requirements. Starting from a central topic, participants branch out to related sub-topics, ideas, and concepts. This free-flowing approach is particularly useful in early elicitation when the scope is not yet clear, helping stakeholders and business analysts explore the problem space together before more formal documentation begins.
Question 4: What distinguishes a 'structured interview' from an 'unstructured interview' in business analysis?
- Structured interviews are conducted in person; unstructured interviews are virtual
- Structured interviews use predetermined questions; unstructured interviews allow free-flowing conversation (Correct answer)
- Structured interviews involve multiple interviewers; unstructured interviews are one-on-one
- Structured interviews are only for technical stakeholders
Correct answer: Structured interviews use predetermined questions; unstructured interviews allow free-flowing conversation
Structured interviews follow a predefined set of questions to ensure consistency and coverage, while unstructured interviews allow flexible, exploratory conversation guided by stakeholder responses.
Structured interviews use a predetermined question list to ensure consistent coverage across multiple stakeholders and to maintain focus on specific topics. Unstructured interviews follow the stakeholder's lead, allowing the business analyst to explore emerging themes. Semi-structured interviews combine both approaches — starting with key planned questions but allowing follow-up exploration. The choice depends on the elicitation goal and stakeholder relationship.
Question 5: Which of the following represents a 'tacit knowledge' challenge in requirements elicitation?
- A stakeholder who refuses to participate in interviews
- A domain expert who finds it difficult to articulate how they perform a complex task (Correct answer)
- A stakeholder who provides excessive detail about low-priority requirements
- A project sponsor who changes requirements frequently
Correct answer: A domain expert who finds it difficult to articulate how they perform a complex task
Tacit knowledge is deeply embedded expertise that is difficult to articulate — domain experts often 'just know' how to perform complex tasks without being able to explain the steps.
Tacit knowledge refers to skills, know-how, and understanding that are embedded in expert practitioners but difficult to articulate explicitly. Domain experts may perform complex processes automatically without being able to describe the steps they follow. Business analysts address this challenge through observation, protocol analysis (asking experts to 'think aloud' while performing tasks), and apprenticeship (working alongside experts).
Question 6: What is the MAIN risk of relying solely on document analysis for requirements elicitation?
- Documents are always outdated and should never be used
- Documents may not reflect current actual practice or may be incomplete (Correct answer)
- Document analysis cannot be used with digital documents
- It requires too much time compared to other techniques
Correct answer: Documents may not reflect current actual practice or may be incomplete
Documents may reflect intended or historical processes rather than current actual practice, and may be incomplete, inconsistent, or contain outdated information.
Document analysis (reviewing existing policies, procedures, system specifications, forms, and reports) is useful for understanding the current state and organizational context. However, documents often lag behind reality — processes may have evolved informally, workarounds may exist, or documentation may never have been updated. Relying solely on documents risks capturing an inaccurate picture of the current state. Document analysis should be complemented with stakeholder interviews or observation.
CCBA Requirements Elicitation and Collaboration 2
What is a 'prototype' primarily used for during requirements elicitation?