Visit here for our full IIBA CBAP exam dumps and practice test questions.
Question 76
A business analyst is working with stakeholders to prioritize requirements for a new customer relationship management system. The stakeholders have conflicting opinions about which features are most important. Which technique would be most effective for achieving consensus on requirement priorities?
A) Brainstorming session
B) MoSCoW prioritization
C) Delphi technique
D) SWOT analysis
Answer: B
Explanation:
MoSCoW prioritization is the most effective technique for achieving consensus on requirement priorities when stakeholders have conflicting opinions. This structured approach categorizes requirements into four distinct groups: Must have, Should have, Could have, and Won’t have, providing a clear framework for stakeholders to understand and agree upon priorities.
The MoSCoW method works particularly well in situations with conflicting stakeholder opinions because it forces explicit discussion about the criticality of each requirement. Must have requirements are those critical for project success and without which the solution would be considered a failure. Should have requirements are important but not vital, and the solution can still function without them in the short term. Could have requirements are desirable but less critical, often implemented if time and resources permit. Won’t have requirements are explicitly excluded from the current implementation scope.
This technique facilitates consensus by providing a common language and structure that all stakeholders can understand and use. It removes ambiguity by requiring stakeholders to make clear choices about priority levels rather than simply stating everything is important. The collaborative nature of MoSCoW prioritization encourages dialogue among stakeholders, helping them understand different perspectives and reach agreement through structured discussion.
Brainstorming sessions are excellent for generating ideas and requirements but do not provide a structured mechanism for prioritization or conflict resolution. The Delphi technique involves anonymous expert input through multiple rounds, which can be time-consuming and may not facilitate the direct stakeholder engagement needed for consensus building. SWOT analysis is a strategic planning tool used to identify strengths, weaknesses, opportunities, and threats, but it does not directly address requirement prioritization or conflict resolution among stakeholders.
The business analyst facilitates the MoSCoW prioritization session, ensuring all stakeholder voices are heard while guiding the group toward consensus. This structured approach combined with skilled facilitation makes it highly effective for resolving conflicting priorities in business analysis work.
Question 77
During requirements elicitation, a business analyst discovers that different stakeholder groups use the same term to describe different concepts. What should the business analyst create to address this issue?
A) Context diagram
B) Glossary
C) Use case diagram
D) Process flow
Answer: B
Explanation:
A glossary is the most appropriate artifact for addressing terminology confusion where different stakeholder groups use the same term to describe different concepts. The glossary serves as a centralized reference that defines key terms, acronyms, and abbreviations used throughout the project, ensuring all stakeholders share a common understanding of terminology.
Creating a glossary is essential for establishing a ubiquitous language across the project. When different stakeholder groups interpret the same term differently, it creates significant risk for miscommunication, misunderstood requirements, and ultimately incorrect solution delivery. The glossary eliminates this ambiguity by providing clear, agreed-upon definitions that all stakeholders commit to using consistently.
The business analyst typically identifies terms that need definition during elicitation activities, stakeholder interviews, workshops, and document reviews. Each term in the glossary includes its definition, context of use, and potentially examples or synonyms. For terms with multiple interpretations, the glossary explicitly states which definition applies to the project and may note alternative meanings to prevent confusion.
The glossary becomes a living document that evolves throughout the project lifecycle. As new terms emerge or existing definitions require refinement, the business analyst updates the glossary and communicates changes to stakeholders. This ensures ongoing alignment and prevents terminology drift that could compromise requirement clarity.
A context diagram shows the system boundary and external entities that interact with the system but does not address terminology standardization. Use case diagrams illustrate system functionality and actor interactions but do not resolve semantic ambiguities in terminology. Process flows document workflow sequences and activities but similarly do not establish common definitions for terms.
By creating and maintaining a comprehensive glossary, the business analyst establishes clear communication foundations that support accurate requirements definition, validation, and implementation. This seemingly simple artifact plays a critical role in project success by preventing costly misunderstandings rooted in inconsistent terminology usage.
Question 78
A business analyst needs to assess the value and feasibility of proposed solution options. Which analysis technique compares the benefits and costs of each option to determine the most viable solution?
A) Gap analysis
B) Cost-benefit analysis
C) Root cause analysis
D) Risk analysis
Answer: B
Explanation:
Cost-benefit analysis is the technique specifically designed to compare benefits and costs of different solution options to determine which option provides the most value and is most viable for implementation. This quantitative and qualitative assessment helps organizations make informed decisions about solution investments by weighing expected returns against required expenditures.
Cost-benefit analysis examines both tangible and intangible factors associated with each solution option. Tangible costs include development expenses, hardware and software purchases, implementation costs, training, and ongoing maintenance. Tangible benefits include increased revenue, cost savings, improved efficiency, and reduced operational expenses. Intangible factors such as improved customer satisfaction, enhanced brand reputation, employee morale, and competitive advantage are also considered, though these may be more challenging to quantify.
The business analyst conducts cost-benefit analysis by first identifying all relevant costs and benefits for each solution option. Costs are categorized as one-time or recurring, and benefits are projected over the expected solution lifespan. Financial metrics such as return on investment, net present value, payback period, and internal rate of return help quantify the financial viability of each option. The analysis considers timeframes, as benefits may accrue over time while certain costs are immediate.
This technique enables objective comparison across multiple solution options by providing a common framework for evaluation. Decision makers can see which option delivers the best value proposition based on organizational priorities and constraints. The analysis also supports stakeholder communication by presenting clear rationale for solution selection grounded in financial and business value considerations.
Gap analysis identifies differences between current and desired states but does not evaluate solution costs and benefits. Root cause analysis investigates underlying problems but does not assess solution viability. Risk analysis examines potential threats and uncertainties but focuses on negative impacts rather than comprehensive cost-benefit comparison. While these techniques support decision making, cost-benefit analysis directly addresses the need to compare solution value and feasibility.
Question 79
A business analyst is documenting requirements and needs to show how data flows through a system. Which modeling technique would be most appropriate?
A) Entity relationship diagram
B) State diagram
C) Data flow diagram
D) Class diagram
Answer: C
Explanation:
A data flow diagram is the most appropriate modeling technique for showing how data flows through a system. DFDs provide a graphical representation of data movement, illustrating where data comes from, what processes transform it, where it goes, and where it is stored within the system.
Data flow diagrams use four basic symbols to represent system components: external entities that provide data to or receive data from the system, processes that transform data, data stores where information is held, and data flows that show data movement between components. This simple notation makes DFDs accessible to both technical and non-technical stakeholders, facilitating communication and requirements validation.
DFDs can be created at different levels of abstraction. A context diagram represents the highest level, showing the system as a single process with external entities and data flows crossing the system boundary. Lower-level DFDs decompose processes into more detailed subprocesses, revealing increasingly specific views of data movement and transformation. This hierarchical approach allows the business analyst to present appropriate detail levels to different audiences.
The primary value of data flow diagrams is their focus on data perspective rather than control flow or timing. They clearly show what data enters and exits each process, helping stakeholders understand information requirements and identify missing or incorrect data flows. This makes DFDs particularly valuable during requirements analysis for systems with significant data processing components.
Entity relationship diagrams model data structures and relationships between entities but do not show data movement through processes. State diagrams illustrate how objects transition between states based on events but do not depict data flows. Class diagrams represent object-oriented designs showing classes, attributes, and relationships but focus on static structure rather than data movement. While each modeling technique serves important purposes, data flow diagrams specifically address the need to visualize how data flows through a system.
Question 80
During a requirements workshop, a business analyst notices that a key stakeholder is dominating the discussion while others remain silent. What facilitation technique should the business analyst use?
A) Round-robin participation
B) Parking lot
C) Voting
D) Affinity grouping
Answer: A
Explanation:
Round-robin participation is the most effective facilitation technique when one stakeholder dominates discussion while others remain silent. This structured approach ensures every participant has an opportunity to contribute by systematically going around the room and giving each person a chance to speak in turn.
Round-robin participation addresses power dynamics and personality differences that often emerge in group settings. Some stakeholders naturally speak more, whether due to personality, position authority, or subject matter expertise, while others may be introverted, less confident, or culturally inclined toward deference. Without intervention, dominant voices can overshadow valuable perspectives from quieter participants, resulting in incomplete requirements and missed insights.
The business analyst implements round-robin by explaining the technique to participants and then methodically giving each person an opportunity to share their thoughts on the topic being discussed. Participants can pass if they have nothing to add, but the structure ensures everyone receives equal opportunity to contribute. This approach validates all stakeholders, signaling that their input matters equally regardless of their position or personality.
Round-robin participation offers several benefits beyond balanced participation. It slows down rushed discussions, allowing time for reflection and thoughtful responses. It surfaces diverse perspectives that might otherwise remain hidden. It reduces groupthink by encouraging independent thinking before hearing others’ views. The technique also helps quieter stakeholders become more comfortable participating, often leading to increased engagement throughout the workshop.
A parking lot captures off-topic items for later discussion but does not address participation imbalance. Voting allows decision making but does not ensure all voices are heard before the vote. Affinity grouping organizes ideas into categories but does not specifically address the participation dynamics described. While these are valuable facilitation techniques, round-robin participation directly addresses the need to balance contributions when some stakeholders dominate while others remain silent.
Question 81
A business analyst is defining the scope for a new project. Which document formally defines what is included and excluded from the project and solution scope?
A) Business case
B) Project charter
C) Scope statement
D) Requirements document
Answer: C
Explanation:
The scope statement is the document that formally defines what is included and excluded from the project and solution scope. This critical artifact establishes clear boundaries for the initiative, helping prevent scope creep and ensuring all stakeholders share a common understanding of what the project will and will not deliver.
A comprehensive scope statement includes several key elements. It describes the solution scope by defining the features, functions, and characteristics that the solution will possess. It articulates the project scope by specifying the work required to deliver the solution. Importantly, the scope statement explicitly identifies what is out of scope, preventing assumptions and misunderstandings about deliverables. It may also define acceptance criteria, constraints, assumptions, and dependencies that affect scope.
The scope statement serves multiple important purposes throughout the project lifecycle. It provides the foundation for detailed requirements elicitation by establishing boundaries for investigation. It guides the project team in making decisions about what work to pursue and what falls outside their mandate. It supports stakeholder communication by providing a reference point when questions arise about whether specific items are included. The scope statement also becomes the baseline against which scope change requests are evaluated.
Business analysts typically develop the scope statement collaboratively with stakeholders during project initiation. The process involves identifying business needs, understanding organizational objectives, and negotiating scope boundaries based on available resources, timelines, and priorities. Once stakeholders approve the scope statement, it becomes a controlled document requiring formal change management for modifications.
The business case justifies the project investment but does not define detailed scope boundaries. The project charter authorizes the project and assigns the project manager but typically provides only high-level scope information. The requirements document details specific requirements but is developed based on the scope defined in the scope statement. While these documents relate to scope, the scope statement specifically and formally defines inclusion and exclusion boundaries.
Question 82
A business analyst needs to trace requirements back to their originating business objectives. What is this practice called?
A) Requirements validation
B) Requirements traceability
C) Requirements decomposition
D) Requirements prioritization
Answer: B
Explanation:
Requirements traceability is the practice of creating and maintaining links between requirements and their sources, including business objectives, stakeholder needs, and solution components. This systematic approach ensures requirements remain aligned with business goals throughout the project lifecycle and enables impact analysis when changes occur.
Requirements traceability typically operates in multiple directions. Forward traceability links requirements to their implementation in design, code, and test cases, ensuring every requirement is addressed in the solution. Backward traceability connects requirements to their origin points such as business objectives, stakeholder requests, or regulatory mandates. This bidirectional traceability creates a complete chain demonstrating why each requirement exists and how it will be realized.
The business analyst establishes traceability using various tools and techniques. Traceability matrices document relationships between different artifact types in a tabular format. Requirements management tools often provide built-in traceability features allowing analysts to create and visualize requirement relationships. Regardless of the tool used, the analyst must actively maintain traceability throughout the project as requirements evolve and new information emerges.
Traceability provides significant value across the project lifecycle. It helps identify orphaned requirements that lack business justification, enabling removal of unnecessary scope. It supports impact analysis by revealing which requirements, designs, and tests are affected when business objectives or requirements change. It facilitates compliance by demonstrating how regulatory requirements are addressed in the solution. Traceability also aids validation by confirming that all business objectives have corresponding requirements and solution components.
Requirements validation confirms that requirements accurately represent stakeholder needs but does not establish linkages to business objectives. Requirements decomposition breaks high-level requirements into detailed specifications but does not create traceability relationships. Requirements prioritization ranks requirements by importance but does not link them to originating objectives. While these practices are valuable, requirements traceability specifically addresses the need to maintain relationships between requirements and their sources.
Question 83
A business analyst is working on a project where requirements are expected to change frequently. Which approach would be most suitable?
A) Waterfall methodology
B) Agile methodology
C) Spiral model
D) V-model
Answer: B
Explanation:
Agile methodology is most suitable for projects where requirements are expected to change frequently. Agile embraces change as a natural and valuable aspect of solution development, providing frameworks and practices that accommodate evolving requirements while maintaining project progress and stakeholder satisfaction.
Agile approaches recognize that detailed upfront requirements are often impossible or counterproductive when dealing with complex problems, uncertain environments, or innovative solutions. Instead, Agile teams work in short iterations or sprints, typically lasting one to four weeks, during which they deliver working solution increments. Requirements are elaborated just-in-time rather than all at once, allowing teams to incorporate new learning, changing business conditions, and stakeholder feedback continuously.
The business analyst role adapts in Agile environments. Rather than creating comprehensive requirements documentation upfront, analysts work collaboratively with the team and stakeholders throughout each iteration. They facilitate backlog refinement sessions where requirements are discussed, estimated, and prepared for upcoming sprints. They write user stories describing functionality from the user perspective, including acceptance criteria that define done. They participate in daily standups, sprint planning, reviews, and retrospectives, ensuring requirements remain clear and aligned with business value.
Agile’s iterative nature provides multiple benefits when requirements change frequently. Stakeholders see working solution increments regularly, providing concrete feedback that shapes subsequent development. Prioritization occurs continuously, ensuring the team always works on the most valuable requirements. The short feedback loops reduce risk by catching misunderstandings early before significant investment occurs. Teams can pivot direction based on new information without scrapping extensive documentation or designs.
Waterfall methodology follows sequential phases with requirements defined comprehensively upfront, making it unsuitable for frequent changes. The spiral model incorporates risk analysis and iterative development but is more heavyweight than Agile. The V-model emphasizes testing corresponding to development phases but assumes relatively stable requirements. While these approaches have appropriate applications, Agile methodology specifically addresses environments with frequent requirement changes.
Question 84
A business analyst is evaluating a solution to ensure it meets the defined requirements and solves the business problem. What type of evaluation is being performed?
A) Solution evaluation
B) Requirements validation
C) Requirements verification
D) Performance testing
Answer: A
Explanation:
Solution evaluation is the systematic assessment performed to determine whether an implemented solution meets defined requirements and effectively addresses the business problem it was designed to solve. This evaluation occurs after solution implementation and focuses on actual performance, value delivery, and business outcome achievement.
Solution evaluation encompasses multiple dimensions of assessment. It verifies that the solution performs required functions correctly according to specified requirements. It assesses whether the solution delivers expected business value and benefits outlined in the business case. It examines solution performance against key metrics and success criteria established during planning. The evaluation also considers whether the solution creates the anticipated business change and improves organizational capability.
The business analyst plays a central role in solution evaluation by defining evaluation approaches, identifying metrics, collecting performance data, and analyzing results. Evaluation activities may include acceptance testing to confirm the solution meets requirements, user feedback collection to assess satisfaction and usability, performance measurement against defined metrics, and business impact assessment to determine value realization. The analyst compares actual outcomes to expected outcomes, identifying gaps that require attention.
Solution evaluation provides insights that drive multiple decisions. It informs acceptance decisions about whether the solution is ready for full deployment. It identifies defects, gaps, or areas needing improvement, feeding input to enhancement planning. It validates whether the original business problem has been solved or whether additional work is needed. The evaluation also generates lessons learned that improve future projects and helps the organization refine its estimation and planning capabilities.
Requirements validation confirms requirements accurately represent stakeholder needs before solution development begins. Requirements verification checks that requirements are well-formed and complete. Performance testing examines specific technical performance characteristics. While these activities relate to quality assurance, solution evaluation specifically focuses on assessing implemented solutions against requirements and business objectives to determine overall success.
Question 85
During requirements analysis, a business analyst identifies a requirement that conflicts with an existing constraint. What should the business analyst do first?
A) Remove the requirement
B) Document the conflict and escalate to stakeholders
C) Modify the constraint
D) Implement the requirement anyway
Answer: B
Explanation:
When a business analyst identifies a requirement that conflicts with an existing constraint, the first step is to document the conflict thoroughly and escalate it to appropriate stakeholders for resolution. This approach ensures transparency, enables informed decision making, and prevents the analyst from making assumptions about priorities or making unilateral decisions that may not align with organizational needs.
Documenting the conflict requires the business analyst to clearly articulate the nature of the incompatibility. The documentation should describe the requirement in question, specify the constraint it violates, explain why the conflict exists, and outline potential implications if either the requirement or constraint is maintained unchanged. This comprehensive documentation provides stakeholders with the information needed to understand the situation and make appropriate decisions.
Escalation involves engaging stakeholders who have the authority and context to resolve the conflict. Depending on the situation, this might include the project sponsor, product owner, business owner, or a designated decision-making body. The business analyst facilitates the resolution discussion by presenting the conflict, explaining options, and describing the consequences of various resolution approaches. Possible resolutions include modifying the requirement, relaxing or removing the constraint, accepting the conflict with documented justification, or seeking alternative approaches that satisfy the requirement within the constraint.
This escalation approach respects organizational governance and stakeholder accountability. Requirements and constraints both exist for valid business reasons, and their relative importance depends on factors like strategic priorities, risk tolerance, and resource availability that individual business analysts may not fully appreciate. By escalating rather than independently resolving the conflict, the analyst ensures decisions reflect appropriate organizational perspective and authority.
Removing the requirement without discussion may eliminate important functionality. Modifying the constraint without authorization may violate policies or create unacceptable risk. Implementing the conflicting requirement disregards the constraint and could create problems. While these actions might eventually result from stakeholder decisions, the business analyst should first document and escalate to enable informed resolution.
Question 86
A business analyst needs to understand the current state business processes before defining future state requirements. Which technique is most effective for documenting existing workflows?
A) Process modeling
B) Prototyping
C) Benchmarking
D) Interface analysis
Answer: A
Explanation:
Process modeling is the most effective technique for documenting existing workflows and understanding current state business processes. This technique creates visual and textual representations of how work flows through an organization, including activities, decisions, inputs, outputs, roles, and systems involved in business processes.
Process modeling uses various notations and techniques to represent workflows. Business Process Model and Notation provides standardized symbols for activities, events, gateways, and flows, enabling detailed process documentation. Flowcharts offer simpler visualization using basic shapes to represent process steps and decision points. Swimlane diagrams organize process activities by role or department, clearly showing handoffs and responsibilities. Value stream maps highlight value-adding and non-value-adding activities, helping identify waste and improvement opportunities.
The business analyst conducts process modeling by engaging with process participants and subject matter experts. Through observation, interviews, workshops, and document reviews, the analyst learns how work actually flows rather than how it theoretically should flow. This current state understanding is essential because documented procedures often differ from actual practice due to workarounds, informal adaptations, and undocumented knowledge. The analyst captures this reality in process models that accurately represent existing workflows.
Understanding current state processes through modeling provides multiple benefits. It establishes a baseline for comparison when defining future state requirements. It identifies pain points, inefficiencies, bottlenecks, and gaps that the solution should address. It reveals dependencies and integration points that affect solution design. Process models also facilitate stakeholder communication by providing concrete visualizations that are easier to understand and validate than textual descriptions alone.
Prototyping creates preliminary solution representations but does not document existing processes. Benchmarking compares organizational performance to industry standards but focuses on metrics rather than detailed workflow documentation. Interface analysis examines how systems interact but does not comprehensively document business processes. While these techniques have value, process modeling specifically addresses the need to understand and document current state workflows before defining future requirements.
Question 87
A business analyst is working with stakeholders who have different levels of authority and influence over the project. What analysis should the business analyst perform to understand stakeholder dynamics?
A) SWOT analysis
B) Stakeholder analysis
C) Risk analysis
D) Gap analysis
Answer: B
Explanation:
Stakeholder analysis is the technique specifically designed to understand stakeholder dynamics including their levels of authority, influence, interests, attitudes, and potential impact on the project. This systematic assessment helps business analysts develop appropriate engagement strategies and manage stakeholder relationships effectively throughout the initiative.
Stakeholder analysis examines multiple dimensions of stakeholder characteristics. Power or authority represents the stakeholder’s decision-making capability and control over resources. Interest reflects how much the stakeholder cares about the project and its outcomes. Influence indicates the stakeholder’s ability to affect project success through persuasion, relationships, or expertise even without formal authority. The analysis also considers stakeholder attitudes ranging from supportive champion to resistant blocker, and assesses each stakeholder’s communication preferences, availability, and level of engagement required.
The business analyst typically documents stakeholder analysis using various tools. A stakeholder matrix maps stakeholders along two dimensions such as power versus interest, creating quadrants that suggest management strategies. High power, high interest stakeholders require close management and regular engagement. High power, low interest stakeholders need satisfaction but may not require detailed involvement. Low power, high interest stakeholders should be kept informed and may serve as valuable sources of requirements and feedback. Low power, low interest stakeholders require monitoring but minimal active engagement.
Stakeholder analysis informs critical business analysis decisions. It determines who should participate in requirements elicitation activities and at what level. It guides communication planning by identifying what information different stakeholders need and how often. It reveals potential sources of resistance that may require change management attention. The analysis also helps identify key decision makers whose approval is essential and influencers who can champion the initiative.
SWOT analysis examines organizational strengths, weaknesses, opportunities, and threats but does not assess stakeholder dynamics. Risk analysis identifies project threats and opportunities but focuses on events rather than people. Gap analysis compares current and future states but does not evaluate stakeholder characteristics. While these techniques support project success, stakeholder analysis specifically addresses understanding stakeholder authority, influence, and dynamics.
Question 88
A business analyst has completed requirements elicitation and now needs to organize and structure the information gathered. What is this process called?
A) Requirements analysis
B) Requirements management
C) Requirements validation
D) Requirements communication
Answer: A
Explanation:
Requirements analysis is the process of organizing, structuring, and refining the information gathered during elicitation to develop a comprehensive understanding of requirements. This analytical work transforms raw stakeholder input into well-defined, prioritized, and structured requirements that guide solution development.
Requirements analysis involves multiple activities that add clarity and structure to elicited information. The business analyst examines requirements for completeness, identifying gaps where additional information is needed. Analysis reveals relationships between requirements, such as dependencies where one requirement relies on another or conflicts where requirements contradict each other. The analyst decomposes high-level requirements into more detailed specifications, creating hierarchical structures that organize requirements logically.
During analysis, the business analyst applies various modeling techniques to represent requirements from different perspectives. Process models show workflow and activities. Data models represent information structures and relationships. Use cases describe user interactions with the system. State diagrams illustrate how objects change over time. These complementary views provide comprehensive understanding that textual requirements alone cannot achieve.
Requirements analysis also involves prioritization, helping stakeholders decide which requirements are most important based on business value, risk, dependencies, and constraints. The analyst facilitates discussions about requirement priority using techniques like MoSCoW, ranking, or weighted scoring. This prioritization guides decisions about scope, phasing, and trade-offs when resources or time are limited.
The output of requirements analysis includes organized, structured, and prioritized requirements ready for validation and communication. Analysis ensures requirements are clear, complete, consistent, and aligned with business objectives before significant investment occurs in solution design and development.
Requirements management encompasses the ongoing activities of tracking, maintaining, and controlling requirements throughout the project lifecycle. Requirements validation confirms requirements accurately represent needs. Requirements communication involves sharing requirements with stakeholders. While these activities are essential, requirements analysis specifically addresses organizing and structuring elicited information.
Question 89
A business analyst needs to determine whether the business need justifies the investment required to implement a solution. What should the business analyst create?
A) Feasibility study
B) Business case
C) Risk assessment
D) Requirements specification
Answer: B
Explanation:
A business case is the document that determines whether the business need justifies the investment required to implement a solution. This comprehensive analysis provides decision makers with the information needed to evaluate whether pursuing the initiative makes sound business sense based on costs, benefits, risks, and strategic alignment.
The business case examines the problem or opportunity driving the initiative, describing the current situation, its impact on the organization, and consequences of not addressing it. It articulates the business need in terms that resonate with decision makers, quantifying pain points and opportunity costs where possible. This problem definition establishes why the organization should consider investing resources in a solution.
A thorough business case analyzes potential solution options, often presenting multiple approaches with varying scopes, costs, and benefits. For each option, the business case estimates implementation costs including technology, resources, training, and change management expenses. It projects expected benefits such as increased revenue, cost savings, efficiency gains, risk reduction, or improved customer satisfaction. Financial analysis using metrics like return on investment, net present value, and payback period helps quantify the value proposition.
The business case also addresses risks, assumptions, and constraints that affect the recommendation. It considers strategic alignment, evaluating how well each option supports organizational goals and priorities. Implementation timeline, resource requirements, and organizational readiness are discussed to ensure feasibility. Based on this comprehensive analysis, the business case presents a recommendation with justification, enabling informed decision making about whether to proceed with investment.
Business case development often occurs early in the initiative lifecycle, sometimes before detailed requirements work begins. The business analyst typically leads business case creation, collaborating with financial analysts, subject matter experts, and stakeholders to gather necessary information and validate assumptions.
A feasibility study examines technical, operational, and economic viability but may not provide comprehensive investment justification. Risk assessment focuses specifically on threats and opportunities. Requirements specification documents what the solution must do but does not justify the investment. While these artifacts provide valuable information, the business case specifically addresses whether business need justifies solution investment.
Question 90
A business analyst is reviewing requirements documentation to ensure it contains no errors, ambiguities, or inconsistencies. What activity is the business analyst performing?
A) Requirements validation
B) Requirements verification
C) Requirements elicitation
D) Requirements prioritization
Answer: B
Explanation:
Requirements verification is the activity of reviewing requirements documentation to ensure it contains no errors, ambiguities, inconsistencies, or other quality defects. This quality control process examines whether requirements are well-formed, clear, complete, and compliant with organizational standards before they are baselined and used for solution development.
Requirements verification focuses on the internal quality characteristics of requirements themselves rather than whether they represent actual stakeholder needs. The business analyst checks that each requirement is clear and unambiguous, using precise language that prevents multiple interpretations. Verification confirms requirements are complete, containing all necessary information without requiring readers to make assumptions. The analyst ensures requirements are consistent with each other, identifying and resolving contradictions or conflicts.
Verification also examines requirements against quality criteria defined by the organization. Requirements should be testable, meaning their satisfaction can be objectively determined. They should be feasible given available technology, resources, and constraints. Requirements must be traceable, with clear relationships to their sources and to other requirements. The analyst verifies that requirements follow established templates, standards, and documentation conventions.
Various techniques support requirements verification. Peer reviews bring multiple perspectives to examine requirements for defects. Structured walkthroughs systematically present requirements to reviewers following defined procedures. Checklists ensure consistent evaluation against quality criteria. Automated analysis tools can identify certain defects like ambiguous terms, incomplete attributes, or formatting inconsistencies.
Requirements verification typically occurs multiple times throughout the requirements lifecycle. The business analyst performs ongoing verification while developing requirements. Formal verification reviews happen at key milestones before requirements are baselined. This iterative verification improves requirements quality progressively, reducing costly defects that would otherwise be discovered during later project phases.
Requirements validation confirms requirements represent actual stakeholder needs and will deliver expected value, focusing on external correctness rather than internal quality. Requirements elicitation gathers information from sources. Requirements prioritization ranks requirements by importance. While these activities are essential, requirements verification specifically addresses checking requirements documentation for errors, ambiguities, and quality defects.