Visit here for our full IIBA CBAP exam dumps and practice test questions.
Question 46
A business analyst is conducting a stakeholder analysis for a new enterprise resource planning system implementation. Which technique is most effective for identifying stakeholders who have high power but low interest in the project?
A) RACI matrix
B) Power/Interest grid
C) Organizational chart review
D) Brainstorming sessions
Answer: B
Explanation:
The Power/Interest grid is specifically designed to categorize stakeholders based on two critical dimensions: their level of power or influence over the project and their level of interest in the project outcomes. This makes it the most effective technique for identifying stakeholders who have high power but low interest, as requested in the question.
The Power/Interest grid divides stakeholders into four quadrants. High power and high interest stakeholders require close management and regular engagement. High power but low interest stakeholders need to be kept satisfied without overwhelming them with excessive information. Low power but high interest stakeholders should be kept informed, while low power and low interest stakeholders require minimal monitoring. Understanding where stakeholders fall on this grid helps business analysts develop appropriate engagement strategies.
For stakeholders with high power but low interest, the business analyst must maintain their satisfaction and prevent them from becoming obstacles to the project. These stakeholders might include senior executives who have authority over project resources but are not involved in day-to-day operations. The strategy involves periodic updates on key milestones and ensuring their concerns are addressed without burdening them with excessive details.
A RACI matrix is useful for defining roles and responsibilities by identifying who is Responsible, Accountable, Consulted, and Informed for specific tasks or deliverables. While valuable for clarifying accountability, it does not systematically assess stakeholder power and interest levels, making it less suitable for the specific analysis described.
Organizational chart review helps identify stakeholders based on their formal positions within the organizational hierarchy. However, it does not provide insights into their actual level of interest in the project or the degree of influence they may exert beyond their formal authority.
Brainstorming sessions can help generate a comprehensive list of potential stakeholders through collaborative discussion. However, this technique does not inherently categorize stakeholders according to their power and interest levels, requiring additional analysis tools to complete the assessment effectively.
Question 47
During requirements elicitation, a business analyst discovers conflicting requirements from two key stakeholder groups. What is the best approach to resolve this conflict?
A) Prioritize requirements from the stakeholder with higher authority
B) Facilitate a collaborative workshop to find common ground
C) Document both requirements and let the project manager decide
D) Implement the requirement that is technically easier to achieve
Answer: B
Explanation:
Facilitating a collaborative workshop to find common ground is the most effective approach for resolving conflicting requirements because it brings stakeholders together to understand each other’s perspectives, identify underlying needs, and work toward a mutually acceptable solution. This approach aligns with best practices in business analysis and stakeholder management.
Collaborative workshops create an environment where stakeholders can openly discuss their requirements, explain the business rationale behind their needs, and explore the impacts of different options. A skilled business analyst acts as a neutral facilitator, helping stakeholders focus on business objectives rather than positional arguments. Through structured dialogue and techniques such as consensus building, stakeholders often discover that their requirements are not truly conflicting but can be reconciled through creative problem solving or by identifying a higher-level business goal that satisfies both parties.
This approach also builds stakeholder buy-in and commitment to the solution. When stakeholders participate in resolving conflicts, they develop a sense of ownership over the outcomes and are more likely to support the final requirements. The collaborative process helps surface hidden assumptions, clarify misunderstandings, and ensure that all perspectives are considered before making decisions.
Prioritizing requirements based solely on stakeholder authority may create resentment and disengagement among other stakeholders. While organizational hierarchy matters, effective business analysis considers the validity and business value of requirements rather than simply deferring to positional power.
Documenting both conflicting requirements and delegating the decision to the project manager avoids the business analyst’s responsibility to facilitate requirement resolution. This approach can lead to suboptimal decisions made without full understanding of the business context and stakeholder needs.
Implementing the technically easier requirement ignores business value and stakeholder needs. Technical feasibility is an important consideration, but it should not be the primary driver for resolving requirement conflicts without understanding the underlying business objectives and priorities.
Question 48
A business analyst needs to verify that requirements are complete, consistent, and testable. Which requirements quality characteristic is being addressed?
A) Feasibility
B) Validity
C) Verifiability
D) Traceability
Answer: C
Explanation:
Verifiability is the requirements quality characteristic that ensures requirements can be confirmed as complete, consistent, and testable. This characteristic is fundamental to ensuring that requirements can be validated and that the implemented solution can be verified against the stated requirements.
Verifiable requirements are written in a way that allows stakeholders to determine whether the solution meets the specified criteria. This means requirements must be specific, measurable, and unambiguous enough that tests can be designed to confirm compliance. For example, a requirement stating that a system must process transactions quickly is not verifiable, while a requirement stating that the system must process 95% of transactions within 2 seconds is verifiable because it provides specific criteria that can be measured and tested.
Completeness ensures that requirements fully describe the necessary functionality without gaps. Consistency means that requirements do not contradict each other or contain conflicting information. Testability ensures that objective criteria exist to verify that the solution satisfies each requirement. All three aspects are essential components of verifiability, as they enable stakeholders to confirm that requirements have been properly implemented.
Feasibility refers to whether requirements can be implemented within the constraints of budget, time, technology, and organizational capabilities. While important, feasibility does not specifically address whether requirements are complete, consistent, and testable.
Validity ensures that requirements actually address the business need and deliver value to stakeholders. Valid requirements solve the right problem, but this characteristic does not specifically focus on completeness, consistency, or testability.
Traceability is the ability to link requirements to their sources and to track relationships between requirements and other project artifacts such as design elements, test cases, and business objectives. While traceability supports verification activities, it is not the characteristic that directly addresses completeness, consistency, and testability of individual requirements.
Question 49
Which diagram type is most appropriate for modeling the flow of data through different processes in a system?
A) Use case diagram
B) Data flow diagram
C) Entity relationship diagram
D) State diagram
Answer: B
Explanation:
A Data Flow Diagram (DFD) is specifically designed to model how data moves through different processes in a system, making it the most appropriate choice for this purpose. DFDs provide a graphical representation showing processes, data stores, external entities, and the flow of data between these components.
Data flow diagrams use standard notations including circles or rounded rectangles to represent processes that transform data, arrows to show data flows, parallel lines or open rectangles to represent data stores, and squares or rectangles to represent external entities that interact with the system. This notation allows business analysts to illustrate complex data movements in a clear and understandable way.
DFDs are particularly valuable during requirements analysis because they help stakeholders visualize how information moves through the system without getting into implementation details. They can be created at different levels of abstraction, starting with a context diagram showing the system as a single process, then decomposing into more detailed levels that show individual processes and their data flows. This hierarchical approach helps manage complexity while ensuring all data movements are captured.
Use case diagrams model the functional requirements of a system by showing actors and their interactions with the system through use cases. While useful for capturing system functionality from a user perspective, use case diagrams do not specifically illustrate data flow between processes.
Entity relationship diagrams model the structure of data by showing entities, their attributes, and relationships between entities. ERDs are excellent for database design and understanding data structures, but they do not show how data flows through processes or transforms as it moves through the system.
State diagrams model the behavior of objects or systems by showing different states and the transitions between those states in response to events. They are useful for modeling lifecycle behavior but do not focus on data flow between processes.
Question 50
A business analyst is prioritizing requirements using the MoSCoW technique. A requirement is classified as “Should Have.” What does this classification mean?
A) The requirement is critical and must be included in the current release
B) The requirement is important but not critical for the current release
C) The requirement would be nice to have if time and resources permit
D) The requirement will not be implemented in the foreseeable future
Answer: B
Explanation:
In the MoSCoW prioritization technique, “Should Have” requirements are important and should be included if possible, but they are not critical for the current release. This classification indicates that while the requirement adds significant value, the solution can still function and deliver core benefits without it in the initial release.
MoSCoW is an acronym where M stands for Must Have, S stands for Should Have, C stands for Could Have, and W stands for Won’t Have this time. This technique provides a structured approach to prioritizing requirements by categorizing them based on their importance to business objectives and project success.
Should Have requirements typically address important pain points or provide valuable functionality, but they have workarounds or the business can operate temporarily without them. When time or resource constraints arise during project execution, Should Have requirements are the first candidates for deferral to a future release. However, too many deferrals of Should Have requirements may impact stakeholder satisfaction or the overall value delivered by the solution.
Must Have requirements are non-negotiable and critical for the solution to be viable. Without these requirements, the project fails to deliver minimum acceptable functionality. These requirements address legal compliance, core business processes, or fundamental system capabilities that cannot be omitted or worked around.
Could Have requirements are desirable but have minimal impact if left out. They represent nice-to-have features that improve user experience or add convenience but are not essential for achieving business objectives. These are typically included only if time and budget allow after Must Have and Should Have requirements are satisfied.
Won’t Have this time requirements are explicitly acknowledged as out of scope for the current release but may be considered for future releases. This category helps manage stakeholder expectations by documenting requirements that have been discussed but will not be implemented in the near term.
Question 51
During solution evaluation, a business analyst identifies that the implemented solution does not meet several approved requirements. What should be the first course of action?
A) Report the deficiencies to the project sponsor immediately
B) Investigate and document the gaps with supporting evidence
C) Recommend rolling back to the previous system version
D) Update the requirements to match the implemented solution
Answer: B
Explanation:
Investigating and documenting the gaps with supporting evidence should be the first course of action when a business analyst identifies that the implemented solution does not meet approved requirements. This systematic approach ensures that the business analyst has accurate information before taking further action or making recommendations.
The investigation process involves thoroughly analyzing each identified gap to understand its nature, severity, and impact on business operations. The business analyst should gather evidence by testing the solution, reviewing design and implementation documentation, comparing actual functionality against requirement specifications, and collecting input from users and technical teams. This evidence-based approach prevents misunderstandings and ensures that reported deficiencies are legitimate rather than based on incomplete information or miscommunication.
Documentation should clearly describe each gap, reference the specific requirements that are not met, explain the impact on business processes and users, and include any supporting evidence such as test results, screenshots, or stakeholder feedback. Well-documented gaps provide a solid foundation for decision-making and help stakeholders understand the severity and implications of the deficiencies.
Once gaps are properly investigated and documented, the business analyst can then work with appropriate stakeholders to determine the best course of action, which might include defect remediation, requirement changes, workarounds, or other solutions. This measured approach ensures that decisions are based on facts rather than initial impressions.
Reporting deficiencies to the project sponsor immediately without proper investigation may lead to unnecessary alarm or incorrect conclusions. While transparency is important, the business analyst should first confirm that the perceived gaps are actual deficiencies rather than misunderstandings or user errors.
Recommending a rollback to the previous system version is a significant decision that should only be considered after thorough investigation and analysis of alternatives. Such recommendations require complete understanding of the gaps and their business impact.
Updating requirements to match the implemented solution is generally inappropriate as it compromises the integrity of the requirements process and may result in a solution that does not meet business needs.
Question 52
A business analyst is creating a context diagram for a new customer relationship management system. What should be included in this diagram?
A) All internal system processes and their interactions
B) The system as a single process with external entities and data flows
C) Database tables and their relationships
D) Detailed business rules and validation criteria
Answer: B
Explanation:
A context diagram, also known as a level 0 data flow diagram, represents the system as a single process and shows its interactions with external entities through data flows. This high-level view provides stakeholders with an understanding of the system’s boundaries and its relationship with the external environment without delving into internal system details.
The context diagram serves as the starting point for data flow diagram decomposition and helps establish the scope of the system being analyzed. It clearly identifies what is inside the system boundary and what is outside, which is crucial for managing stakeholder expectations and preventing scope creep. External entities represent people, systems, or organizations that interact with the system but are not part of it, such as customers, suppliers, external systems, or regulatory agencies.
Data flows in a context diagram show information moving between external entities and the system. These flows are labeled to indicate the nature of the data being exchanged, such as customer orders, payment confirmations, or inventory reports. By showing these interactions, the context diagram helps stakeholders understand the system’s primary inputs and outputs without being overwhelmed by internal complexity.
The simplicity of the context diagram makes it an excellent communication tool for stakeholders who may not be familiar with detailed technical representations. It provides a common understanding of what the system does from an external perspective and serves as a foundation for more detailed analysis in lower-level data flow diagrams.
All internal system processes and their interactions are shown in lower-level data flow diagrams, not in the context diagram. The context diagram deliberately abstracts away internal details to provide a high-level view.
Database tables and their relationships are documented in entity relationship diagrams, which focus on data structure rather than data flow through the system.
Detailed business rules and validation criteria are typically documented in requirements specifications, business rule catalogs, or decision tables rather than in data flow diagrams, which focus on data movement.
Question 53
Which elicitation technique is most effective when stakeholders have difficulty articulating their requirements or envisioning the future solution?
A) Questionnaires
B) Document analysis
C) Prototyping
D) Surveys
Answer: C
Explanation:
Prototyping is the most effective elicitation technique when stakeholders have difficulty articulating their requirements or envisioning the future solution because it provides a tangible representation that stakeholders can interact with, evaluate, and provide feedback on. This hands-on approach helps overcome the limitations of abstract discussions and written descriptions.
Prototypes can range from simple paper sketches and wireframes to interactive mockups and working software models. By seeing and interacting with a prototype, stakeholders can better understand how the solution will work, identify gaps in their original thinking, and recognize requirements they had not previously considered. This iterative process of prototype creation, review, and refinement helps elicit more complete and accurate requirements than traditional interview or workshop techniques alone.
Prototyping is particularly valuable when dealing with user interfaces, workflows, and complex business processes where visualization significantly enhances understanding. Stakeholders can experiment with the prototype, discover usability issues, and provide specific feedback based on their experience rather than trying to imagine how something might work. This concrete feedback is more actionable and leads to better solutions.
The technique also helps manage stakeholder expectations by providing early visibility into what the solution will look like and how it will behave. This reduces the risk of misunderstandings and disappointment when the final solution is delivered. However, business analysts must clearly communicate whether a prototype is throwaway or evolutionary to prevent confusion about the maturity of the solution.
Questionnaires involve distributing written questions to stakeholders and collecting their responses. While useful for gathering information from large groups, questionnaires are not effective when stakeholders cannot articulate their requirements, as they rely on stakeholders being able to express their needs in written form.
Document analysis involves reviewing existing documentation such as policies, procedures, and system specifications. This technique provides valuable background information but does not directly address stakeholders’ difficulty in envisioning future solutions.
Surveys are similar to questionnaires and face the same limitation when stakeholders struggle to articulate requirements or envision solutions without a concrete reference point.
Question 54
A business analyst is conducting a SWOT analysis for a proposed business intelligence solution. In which quadrant should “increasing competition in the market” be classified?
A) Strengths
B) Weaknesses
C) Opportunities
D) Threats
Answer: D
Explanation:
Increasing competition in the market should be classified as a Threat in SWOT analysis because it represents an external factor that could negatively impact the organization or the success of the proposed business intelligence solution. Understanding how to properly categorize factors in SWOT analysis is essential for strategic planning and decision-making.
SWOT analysis is a strategic planning technique that examines four key dimensions: Strengths (internal positive factors), Weaknesses (internal negative factors), Opportunities (external positive factors), and Threats (external negative factors). The distinction between internal and external factors is crucial, as is understanding whether each factor is favorable or unfavorable to the organization.
Threats are external conditions or trends that exist in the business environment and could potentially harm the organization’s performance, competitive position, or ability to achieve its objectives. Increasing competition represents such a threat because it can lead to market share loss, pricing pressure, reduced profitability, and increased costs for customer acquisition and retention. In the context of a business intelligence solution, heightened competition makes it even more critical for the organization to make data-driven decisions, which actually strengthens the business case for implementing the solution.
By identifying increasing competition as a threat, the business analyst helps stakeholders understand the urgency and importance of the proposed solution. The business intelligence system can provide competitive advantages through better insights, faster decision-making, and improved understanding of market dynamics, which are valuable capabilities when facing intensified competition.
Strengths are internal positive attributes such as skilled workforce, proprietary technology, or strong brand reputation. Competition is external, so it cannot be a strength.
Weaknesses are internal negative factors such as outdated technology, limited resources, or inefficient processes. Since competition is external to the organization, it cannot be classified as a weakness.
Opportunities are external positive factors such as emerging markets, technological advances, or regulatory changes that favor the organization. Increasing competition is negative rather than positive, so it is not an opportunity.
Question 55
Which requirements modeling technique uses “actors” and “use cases” to represent system functionality from a user perspective?
A) Data flow diagram
B) Use case diagram
C) State diagram
D) Activity diagram
Answer: B
Explanation:
Use case diagrams specifically employ actors and use cases to represent system functionality from a user perspective, making them the correct answer to this question. This modeling technique is fundamental to understanding and documenting functional requirements in a user-centric manner.
In use case diagrams, actors represent external entities that interact with the system, including human users, other systems, or hardware devices. Actors are typically shown as stick figures for human users or with stereotypes for non-human actors. Each actor has a specific role when interacting with the system, such as customer, administrator, or billing system.
Use cases represent specific pieces of functionality or services that the system provides to actors. They describe what the system does from the actor’s perspective without specifying how the system accomplishes the task internally. Use cases are shown as ovals or ellipses with descriptive names, typically using verb-noun format such as “Process Order” or “Generate Report.” The relationships between actors and use cases are shown with lines indicating which actors can initiate or participate in which use cases.
Use case diagrams provide a high-level view of system functionality that is easily understood by both technical and non-technical stakeholders. They help identify system boundaries, clarify user roles, and ensure that all user interactions are considered during requirements analysis. The diagrams can also show relationships between use cases through include and extend relationships, which help manage complexity and promote reuse.
Data flow diagrams model how data moves through processes in a system using processes, data stores, external entities, and data flows. While they show external entities, they do not use the actor and use case concepts specific to use case modeling.
State diagrams model the different states an object can be in and the transitions between those states triggered by events. They focus on object behavior rather than user interactions with system functionality.
Activity diagrams model workflows and business processes by showing the sequence of activities and decision points. While they can show actions, they do not specifically use actors and use cases to represent system functionality.
Question 56
A business analyst discovers that a critical requirement was missed during elicitation and is now needed for the current release. What is the appropriate action?
A) Add the requirement immediately without formal approval
B) Document the requirement and submit it through change control
C) Wait until the next release to include the requirement
D) Blame the stakeholder who failed to mention it earlier
Answer: B
Explanation:
Documenting the requirement and submitting it through the established change control process is the appropriate action when a critical requirement is discovered after initial elicitation. This approach ensures proper evaluation, approval, and management of the requirement addition while maintaining project governance and stakeholder alignment.
The change control process exists to manage modifications to the approved requirements baseline in a systematic and controlled manner. When a new requirement is identified, regardless of its criticality, it must go through change control to assess its impact on scope, schedule, budget, and other project constraints. The process typically involves documenting the proposed change, analyzing its implications, obtaining necessary approvals from change control board members or designated authorities, and updating relevant project documentation.
Submitting the requirement through change control ensures that all stakeholders are aware of the proposed addition and its potential impacts. This transparency allows for informed decision-making about whether to include the requirement in the current release or defer it to a future release. The change control board evaluates factors such as business value, technical feasibility, resource availability, and impact on existing commitments before making a decision.
Even though the requirement is described as critical, the formal change control process must be followed to maintain project discipline and avoid scope creep. The business analyst should emphasize the criticality and business impact in the change request documentation to help stakeholders make an informed decision quickly. However, bypassing the process could set a dangerous precedent and undermine project governance.
Adding the requirement immediately without formal approval violates project governance and can lead to scope creep, budget overruns, and schedule delays. It also fails to properly communicate the change to all affected stakeholders and team members.
Waiting until the next release without evaluation may be unnecessarily conservative if the requirement is truly critical and can be accommodated within current project constraints. The change control process exists to make these evaluations systematically.
Blaming stakeholders is unprofessional and counterproductive. Requirements evolve as understanding deepens, and discovering new requirements is a normal part of business analysis work that should be handled professionally through established processes.
Question 57
During requirements validation, which activity ensures that requirements align with business goals and objectives?
A) Verification
B) Validation
C) Inspection
D) Testing
Answer: B
Explanation:
Validation is the activity that ensures requirements align with business goals and objectives, making it the correct answer to this question. Understanding the distinction between validation and verification is fundamental to effective requirements management and quality assurance.
Validation answers the question “Are we building the right thing?” It focuses on ensuring that requirements address the actual business needs and will deliver value to stakeholders when implemented. During validation, business analysts work with stakeholders to confirm that requirements support strategic objectives, solve the intended business problems, and provide expected benefits. This involves reviewing requirements against business cases, strategic plans, and stakeholder expectations.
The validation process includes activities such as structured walkthroughs with stakeholders, reviewing requirements against business objectives, assessing whether requirements deliver expected business value, and confirming that the complete set of requirements addresses the business problem. Validation ensures that even if requirements are perfectly implemented, the resulting solution will actually meet business needs.
Effective validation requires strong stakeholder engagement and business knowledge. Business analysts must understand the organizational context, business strategy, and operational environment to properly validate that requirements align with goals. When misalignment is discovered, requirements must be revised or new requirements added to ensure the solution delivers intended value.
Verification answers the question “Are we building the thing right?” It focuses on ensuring requirements are correctly specified, complete, consistent, unambiguous, and follow standards. Verification checks the quality of requirement statements themselves rather than their alignment with business goals.
Inspection is a formal review technique used during verification to examine requirements for defects, ambiguities, and quality issues. While important for requirements quality, inspection focuses on the correctness of requirement specifications rather than business alignment.
Testing validates that the implemented solution meets requirements, but this occurs after development rather than during requirements validation. Requirements validation ensures requirements are right before development begins, preventing costly rework later in the project lifecycle.
Question 58
A business analyst needs to understand the sequence of activities in a business process, including decision points and parallel activities. Which modeling technique is most appropriate?
A) Use case diagram
B) Entity relationship diagram
C) Activity diagram
D) Context diagram
Answer: C
Explanation:
Activity diagrams are the most appropriate modeling technique for understanding the sequence of activities in a business process, including decision points and parallel activities. This diagram type provides comprehensive capabilities for modeling workflow, process flow, and business logic in a clear visual format.
Activity diagrams use a standardized notation that includes various elements to represent different aspects of process flow. Activities are shown as rounded rectangles representing individual steps or tasks in the process. Decision points are represented by diamonds where the process flow branches based on conditions or business rules. Parallel activities are shown using fork and join notations, indicating where process flows split to execute simultaneously and where they synchronize back together.
The diagram also includes start and end nodes to clearly mark process boundaries, swimlanes to show responsibilities across different roles or departments, and arrows to indicate the flow of control from one activity to the next. This rich notation allows business analysts to capture complex business processes with multiple paths, concurrent activities, and conditional logic in a single, coherent visualization.
Activity diagrams are particularly valuable during process analysis and improvement initiatives. They help identify bottlenecks, redundant activities, and opportunities for automation or streamlining. Stakeholders can easily follow the process flow and provide feedback on accuracy and completeness. The diagrams also serve as a foundation for developing requirements for workflow automation or business process management systems.
Use case diagrams show system functionality from a user perspective through actors and use cases, but they do not model the detailed sequence of activities or process flow. They focus on what the system does rather than how processes execute.
Entity relationship diagrams model data structures by showing entities, attributes, and relationships. They are essential for database design but do not represent process flows, sequences, or decision points.
Context diagrams provide a high-level view of a system and its interactions with external entities through data flows. They show system boundaries but do not detail internal process sequences or activities.
Question 59
Which technique helps a business analyst identify the underlying cause of a problem by repeatedly asking “why” until the root cause is discovered?
A) Pareto analysis
B) Five Whys
C) Fishbone diagram
D) Force field analysis
Answer: B
Explanation:
The Five Whys technique helps business analysts identify the underlying root cause of a problem by repeatedly asking “why” until the fundamental issue is discovered. This simple yet powerful technique was developed by Toyota as part of their production system and has become widely adopted across industries for root cause analysis.
The technique works by starting with a problem statement and asking why it occurred. The answer to that question becomes the basis for the next “why” question, continuing this iterative process typically five times or until the root cause is identified. The number five is not rigid; sometimes fewer or more iterations are needed depending on the complexity of the problem. The key is to continue asking why until reaching a cause that can be directly addressed through corrective action.
For example, if a problem is “customers are complaining about delayed shipments,” the first why might reveal “orders are not being processed on time.” Asking why orders are delayed might reveal “the warehouse is understaffed.” Further investigation into why the warehouse is understaffed might uncover “recent turnover has not been replaced,” and asking why positions remain unfilled might reveal “the hiring process takes too long.” Finally, asking why the hiring process is slow might identify “there is no standardized hiring procedure,” which represents an actionable root cause.
The Five Whys technique is valuable because it is simple to use, requires no special tools or training, and can be conducted quickly in collaborative settings. It helps teams move beyond treating symptoms to address underlying causes, preventing problem recurrence. However, it requires honest and thorough analysis to be effective, as superficial answers can lead to incorrect conclusions.
Pareto analysis uses the 80-20 rule to identify the most significant factors contributing to a problem by analyzing frequency or impact data. While useful for prioritization, it does not specifically dig into root causes through iterative questioning.
Fishbone diagrams, also called cause-and-effect or Ishikawa diagrams, help identify multiple potential causes organized into categories. They provide a broader view of contributing factors but do not use the iterative why-questioning approach.
Force field analysis identifies forces supporting and opposing a change, helping with change management and decision-making rather than root cause analysis.
Question 60
A business analyst is working on a project following an agile methodology. When should requirements be documented in detail?
A) Before the project begins, in a comprehensive requirements document
B) Progressively throughout the project as user stories are developed
C) Only after development is complete for validation purposes
D) Requirements documentation is not needed in agile projects
Answer: B
Explanation:
In agile methodologies, requirements are documented progressively throughout the project as user stories are developed and refined, rather than being fully detailed upfront. This approach aligns with agile principles of responding to change, delivering value incrementally, and maintaining flexibility throughout the development process.
Agile requirements are typically captured initially as user stories in the product backlog. These stories are intentionally brief, using a simple format such as “As a [user role], I want [functionality] so that [business value].” User stories serve as placeholders for conversations and are elaborated with additional details only when they are selected for an upcoming iteration or sprint. This just-in-time elaboration ensures that effort is not wasted documenting requirements that may change or be deprioritized.
As user stories move closer to implementation, they are refined through backlog grooming sessions where the team adds acceptance criteria, clarifies details, breaks down large stories, and estimates effort. During sprint planning, selected stories receive further elaboration through team discussions with the product owner. Throughout development, the team maintains ongoing collaboration with stakeholders to clarify requirements and adapt to new insights.
This progressive elaboration approach offers several advantages. It reduces waste by avoiding detailed documentation of requirements that may never be implemented. It maintains flexibility to respond to changing business needs and market conditions. It encourages continuous stakeholder engagement and feedback. It allows requirements to evolve as the team gains better understanding through working software and user feedback.
Comprehensive upfront requirements documentation contradicts agile principles that emphasize working software over comprehensive documentation and responding to change over following a plan. While some documentation is created, it is minimal and sufficient rather than exhaustive.
Documenting requirements only after development for validation purposes defeats the purpose of requirements, which should guide development rather than simply record what was built.
Requirements documentation is still needed in agile projects, but it takes different forms such as user stories, acceptance criteria, and lightweight models rather than traditional comprehensive specifications.