This makes a delivery decision before analyzing the requested change and its impact.
Implementation should not begin before the change is analyzed and appropriately authorized.
Correct. Traceability identifies affected requirements and dependencies, while impact analysis determines the likely effect on scope, schedule, and the planned delivery.
A formal change authority may become involved later, but impact information is needed first for an informed decision.
A late requirement change should first be traced and analyzed for impact. This provides evidence about effects on the delivery date, scope, dependencies, and related requirements before implementation or a formal change decision.
Late requirement change -> trace affected requirements and perform impact analysis before implementation or formal change decision.
Brainstorming is effective for generating ideas and encouraging interaction among participants, but it normally involves a manageable group. It is not the most efficient technique when the objective is to collect structured information from a large number of users quickly.
A facilitated workshop is valuable when stakeholders need to collaborate, discuss requirements, resolve differences, or reach agreement. However, organizing workshops for a large user population requires coordination and participant availability, making it less suitable when time is limited.
Observation helps the business analyst understand how users actually perform their work and can reveal information that users may not explicitly communicate. However, observing many users is time-consuming and therefore does not fit the requirement to gather information from a large population in a short period.
Correct. A questionnaire allows the business analyst to distribute a consistent set of questions to many users simultaneously and collect structured responses efficiently. This directly addresses the two key conditions in the scenario: a large number of users and a short period of time.
The key clues are the size of the target population and the limited time available. When information must be collected from many users efficiently, a questionnaire is generally more scalable than interactive techniques such as brainstorming, workshops, or observation. The business analyst should select the elicitation technique based on the number of stakeholders, the type of information required, and the time available.
Large number of users + limited time -> think Questionnaire. Workshops and brainstorming -> collaboration and discussion. Observation -> detailed understanding of actual work.
Correct. A survey is well suited for collecting structured feedback, opinions, and satisfaction levels from a large and geographically distributed group of users. It allows the business analyst to efficiently measure how employees perceive the implemented solution.
Organization modeling describes organizational structures, roles, relationships, and responsibilities. It does not primarily measure users satisfaction with an implemented solution.
Focus groups can provide detailed qualitative feedback from selected participants, but they are less suitable when the objective is to efficiently gather satisfaction information from a large, geographically dispersed employee population.
Interface analysis examines interactions and information exchanges between systems, components, or users and systems. It does not primarily measure employee satisfaction with the solution.
The key requirement is to gather employee feedback about satisfaction with an implemented solution across a broad population. A survey provides a scalable and structured way to collect this type of information and can support quantitative analysis of satisfaction levels.
Satisfaction, opinions, or feedback from a large or distributed population -> think Survey. Focus groups provide deeper discussion with smaller groups, while organization modeling and interface analysis serve different analytical purposes.
This is incorrect according to the supplied source answer. Requirements traceability is related to alignment between requirements and delivered results, but it is not the cause identified by the source for this scenario.
A quality department design review does not directly address whether changed client requirements were correctly identified and reflected in the project documentation.
Correct according to the supplied source. If requirement changes were not properly identified, the product and its test plan could remain aligned with outdated documented criteria while no longer matching the client expected specification.
The scenario explicitly states that the product was successfully tested against the test plan. Therefore, inadequate execution of that test plan is not the issue described.
The scenario distinguishes successful testing against a defined test plan from satisfying the client expected requirements. According to the supplied source, the issue is that requirement changes were not properly identified in the project charter, allowing the product to pass documented tests while still failing to correspond to the client expected specification.
When a product passes its defined tests but the client says it does not meet expected requirements, investigate whether requirements and changes remained aligned with the client expectations. Pay attention to activities the scenario explicitly says were successfully completed.
Quality audits are used to evaluate processes and compliance with quality practices. They are not the primary purpose of Quality Function Deployment.
Correct. Quality Function Deployment helps translate customer needs and expectations into product characteristics and features. It therefore supports the relationship between what customers value and what the product should provide.
Control charts and run charts are statistical quality-control tools used to monitor process performance and variation. They do not primarily translate customer needs into product features.
Quality Function Deployment is not primarily about controlling effects between quality functions. Its focus is on connecting customer needs with product or solution characteristics.
Quality Function Deployment provides a structured way to capture the voice of the customer and translate customer needs into product characteristics. Therefore, when the scenario emphasizes connecting product features with customer value, QFD is the appropriate technique.
QFD -> Voice of the Customer -> Customer needs and value -> Product features. Do not confuse QFD with quality audits or statistical quality-control techniques such as control charts.
Correct. A defined decision-making process establishes how stakeholder disagreements, competing priorities, and requirement decisions will be resolved. Defining this as part of business analysis planning gives the business analyst an agreed mechanism to use when consensus cannot easily be reached.
Although project management planning may contain broader project governance and decision mechanisms, this scenario specifically concerns decisions about requirements and business analysis activities. The relevant approach belongs in the business analysis plan.
A communications approach defines how information will be communicated to stakeholders. The problem here is not primarily how information is communicated; it is how conflicting stakeholder positions will be resolved and decisions reached.
Project communications planning addresses broader project communication needs. It does not specifically establish the business analysis decision-making process required to resolve disagreements about requirements and priorities.
When stakeholders have conflicting priorities or viewpoints, the business analyst needs a predefined mechanism for reaching decisions. The business analysis plan should establish the decision-making approach, including how decisions will be made and how disagreements or lack of consensus will be handled.
Stakeholders cannot agree -> think Decision-Making Process. Who needs what information, when, and how -> think Communications Approach. Also distinguish the Business Analysis Plan from the broader Project Management Plan.
Reducing traceability artifacts before stakeholders understand their purpose could compromise the ability to manage requirements effectively. The business analyst should first explain why traceability provides value.
Correct. The business analyst should explain the value of requirements traceability. Traceability helps connect requirements to their origins, related requirements, solution components, and other artifacts, supporting impact analysis, change management, coverage, and verification throughout the initiative.
Schedule pressure alone is not sufficient justification for eliminating traceability. Removing it can make requirement changes, dependencies, coverage, and impacts more difficult to manage.
Starting development without the necessary traceability may create downstream problems and does not address the sponsor lack of understanding about its value.
When a stakeholder proposes eliminating an important business analysis activity simply to save time, the business analyst should first communicate its business and project value. Requirements traceability supports control of requirements throughout their lifecycle and provides essential information when analyzing changes and verifying coverage.
Pressure to skip an important BA activity -> first explain its value and consequences. For traceability, remember: origin -> requirements -> dependencies -> solution -> testing and verification -> change impact.
Observation can help the business analyst understand how employees perform their work and may provide useful evidence, but it does not by itself provide the structured analysis needed to identify the underlying cause of the unexpected performance problem.
Process modeling helps visualize activities, flows, roles, and interactions within a process. It may support the investigation, but the primary objective in this scenario is to determine the underlying reason for the deterioration in performance.
Correct. Root cause analysis is specifically used to investigate a problem and identify its underlying cause rather than merely addressing its symptoms. Since performance became worse instead of improving, the business analyst should determine what is causing the unexpected result.
Interviews can collect information from help-desk employees and other stakeholders, but they are an elicitation technique. Interviews may provide inputs to the investigation, while root cause analysis is the technique used to analyze those inputs and determine why the problem occurred.
The implemented solution produced a measurable result opposite to what was expected. The business analyst therefore needs to investigate the underlying reason for the performance gap. Root cause analysis is designed to move beyond the observed symptom, increased call-answering time, and determine the factors causing it.
Something went wrong and the question asks why or asks for the underlying problem -> think Root Cause Analysis. Observation and interviews gather information; root cause analysis determines the underlying cause.
Use-case development is useful for defining and analyzing interactions between users and a solution, but it is not the best technique here for validating the proposed solution requirements with stakeholders.
Reviewing the previous product version can provide useful historical information, but it does not directly validate whether the requirements for the new release reflect stakeholder needs.
Correct. A solution prototype gives stakeholders a tangible representation of the proposed solution. Reviewing it during an in-person validation session helps stakeholders confirm requirements, identify misunderstandings, and provide feedback before the solution is finalized.
Brainstorming is primarily used to generate ideas and alternatives. The scenario is focused on validating requirements rather than generating new ideas.
Prototyping is particularly valuable for requirements validation because stakeholders can interact with or review a representation of the proposed solution and determine whether it reflects their needs and expectations. This can reveal missing, incorrect, or misunderstood requirements before further development.
Validate requirements + stakeholders can see or review the proposed solution -> think Prototype. Generate ideas -> Brainstorming. Describe user-system interactions -> Use Cases.
SWOT analysis evaluates strengths, weaknesses, opportunities, and threats. It helps assess an organization situation, but its primary purpose is not to compare the current state directly with a desired future state.
Impact analysis evaluates the consequences of a proposed or requested change. It determines what may be affected by the change rather than identifying the difference between current and desired states.
Correct. Gap analysis compares the current state with the desired future state to identify the differences or gaps that must be addressed. Those gaps help determine the changes needed to achieve the desired business outcome.
Trend analysis examines patterns or changes in information over time. It may help predict future behavior, but it does not primarily compare the current business state with a defined desired state.
Gap analysis identifies the difference between where the organization is now and where it wants to be. Once these gaps are understood, the organization can identify the capabilities, processes, resources, or other changes required to move from the current state to the desired future state.
Current state vs. future or desired state -> Gap Analysis. Effect of a proposed change -> Impact Analysis. Strengths, Weaknesses, Opportunities, Threats -> SWOT. Patterns over time -> Trend Analysis.
Net present value calculates the present value of expected future cash flows after considering the time value of money. It produces a monetary value rather than the investment expected rate of return.
Payback period measures how long it takes for an investment to recover its initial cost. It focuses on recovery time rather than a percentage rate of return.
Return on investment compares the financial benefit of an investment with its cost and expresses profitability as a percentage. However, when the objective is to determine the rate at which the investment discounted cash flows break even, internal rate of return is the appropriate technique.
Correct. Internal rate of return identifies the discount rate at which the net present value of an investment cash flows equals zero. It provides a rate that can be used to compare the financial attractiveness of solution alternatives.
When stakeholders want a rate of return for comparing potential investments, internal rate of return is an appropriate financial analysis technique. IRR represents the discount rate at which the present value of expected benefits equals the present value of costs, resulting in a net present value of zero.
Rate of return or discount rate where NPV = 0 -> IRR. Value today of future cash flows -> NPV. Time required to recover the investment -> Payback Period. Benefit relative to investment cost -> ROI.
Rules modeling represents business rules, constraints, conditions, and decision logic. It does not primarily describe how a solution interacts with other systems.
Enterprise modeling provides a broader representation of the organization, including its structure, capabilities, goals, and business environment. It is not specifically focused on system-to-system interactions.
Correct. Interface modeling describes how a solution interacts with external systems, users, devices, or other components. It helps stakeholders understand the interfaces and interactions required between the proposed solution and existing systems.
Data modeling represents the structure, relationships, and organization of data. Although data may pass through system interfaces, data modeling does not primarily depict how systems interact.
The key clue is that stakeholders want to understand how the solution will work with the company existing systems. Interface modeling is used to represent these interaction points and helps identify what information or services must pass between the solution and other systems.
Interaction between solution and other systems -> Interface Modeling. Business rules and decision logic -> Rules Modeling. Organization and business capabilities -> Enterprise Modeling. Data entities and relationships -> Data Modeling.
Correct. A traceability matrix establishes relationships between requirements and their origins, objectives, business needs, solution components, and other related requirements. It enables the business analyst to verify that each requirement contributes to an identified business need and supports the intended scope.
A requirements package organizes and presents requirements to stakeholders for communication, review, or approval. It does not primarily establish the relationship between individual requirements and the underlying business need.
A reliability matrix is not the artifact used for requirements traceability. It does not provide the required relationship between requirements and business needs.
A requirements management plan defines how requirements will be documented, analyzed, traced, prioritized, approved, and controlled. It describes the management approach rather than providing the actual requirement-to-business-need relationships.
Traceability allows the business analyst to follow a requirement back to its business need or objective and forward to the solution elements that implement it. If a requirement cannot be traced to a legitimate business need, its inclusion in scope should be questioned.
Requirement to business need or objective -> Traceability Matrix. Think: Why does this requirement exist? Traceability should provide the connection.
Incorrect. Requirements do not necessarily have to be discussed in a group session before they can undergo peer review. Different elicitation and analysis techniques may have been used.
Incorrect. Sponsor sign-off normally represents a later approval or authorization activity. Peer review can occur before formal approval and can help prepare requirements for approval.
Correct. Requirements should be sufficiently complete and detailed before peer review. If important information needed to understand and define the required work is missing, the requirements are not mature enough for an effective review.
Incorrect. Traceability can be important, but mapping requirement reference codes to WBS attributes is not the fundamental criterion that determines whether requirements are ready for peer review.
Before requirements are subjected to peer review, they should meet appropriate quality criteria, including sufficient completeness, clarity, consistency, and level of detail. Missing information that prevents the work from being adequately defined indicates that further requirements analysis is necessary.
Not ready for review + missing information -> think Requirements Completeness/Quality. Formal approval normally comes after requirements have been adequately analyzed and reviewed.
Incorrect. Recording changes is important, but documentation alone does not provide a formal mechanism for evaluating impact, obtaining authorization, tracking decisions, and controlling implementation.
Incorrect. Approval authority depends on the defined governance approach. The project sponsor does not necessarily approve every requirements change.
Correct. A change control process establishes how proposed requirements changes are submitted, analyzed, evaluated, approved or rejected, documented, and tracked. This provides the formal management approach required by the scenario.
Incorrect. Requirements may legitimately change as business needs evolve. The objective is to control and assess changes rather than automatically reject them.
Requirements change management requires a defined and consistent process. A change control process provides governance for evaluating requested changes, assessing their impacts, determining appropriate approval, documenting decisions, and maintaining requirements integrity and traceability.
Formally manage requirement changes -> think Change Control Process. Do not confuse simply documenting a change with controlling and evaluating it.
Incorrect. Business requirements describe the business objectives and outcomes the initiative is expected to achieve. They do not by themselves define the technical capacity and performance characteristics required under heavy load.
Incorrect. Functional requirements describe what the solution must do. The problem in this scenario is not a missing function but the system inability to perform reliably under the required volume of simultaneous users.
Incorrect. Quality attributes are closely related to nonfunctional characteristics, but the scenario specifically concerns measurable requirements such as capacity, scalability, performance, and reliability that should be identified and tested as nonfunctional requirements.
Correct. Supporting millions of simultaneous users is a nonfunctional requirement involving capacity, scalability, performance, and reliability. Identifying these requirements and validating them through appropriate performance and load testing could have revealed the problem before production.
A solution must satisfy both functional and nonfunctional requirements. Functional requirements describe what the solution does, while nonfunctional requirements define characteristics such as performance, scalability, availability, reliability, security, and capacity. When a system must support a very large number of concurrent users, those expectations should be explicitly defined and tested before deployment.
What the system does -> Functional Requirement. How well / how much / under what performance conditions -> Nonfunctional Requirement. Large user volume, response time, scalability, availability, and reliability are strong clues for NFRs.
A business case explains the justification for an initiative, including expected benefits, costs, risks, and alternatives. It is not primarily used to document detailed product requirements and supporting models.
Correct. A requirements specification documents the requirements for a product or solution and can include supporting models, definitions, and other information needed to clearly communicate the requirements.
A project charter formally authorizes a project and establishes high-level information such as objectives, scope, stakeholders, and authority. It does not contain the detailed product requirements described in the scenario.
A standard operating manual documents procedures and instructions for performing operational activities. It is not the primary document for specifying customer product requirements.
A requirements specification organizes and communicates detailed requirements for a product or solution. Supporting artifacts such as functional models, data models, and a glossary help stakeholders understand the requirements consistently and reduce ambiguity.
Detailed customer/product requirements + models + definitions/glossary -> think Requirements Specification. A Business Case justifies the investment, while a Project Charter authorizes the project.
A change control board evaluates and decides on proposed changes, but it is not the system used to systematically control and maintain versions of project documentation.
A requirements traceability matrix tracks relationships among requirements and related project or solution elements. It supports traceability but is not the primary mechanism for controlling document versions and changes.
Correct. A configuration management system provides a structured and standardized way to identify, control, track, and maintain changes to project documents and other configuration items.
Configuration verification and audits check whether configuration items conform to requirements and records. They provide verification rather than the ongoing mechanism for managing document changes.
Configuration management provides systematic control over project artifacts and their changes. It helps maintain identification, version control, change history, and integrity of controlled documentation throughout the project lifecycle.
Standardized control of documents, versions, and changes -> think Configuration Management System. A CCB makes change decisions; configuration management controls and records the affected artifacts.
Quality management is the broader discipline covering the planning, assurance, and control of quality. The scenario asks for the specific function that audits requirements and quality control results.
Correct. Quality assurance focuses on evaluating and auditing quality processes, requirements, and quality control results to ensure that appropriate standards and operational definitions are being applied.
Quality assessment is not the specific quality function described in this scenario. The activity described is the auditing and process-focused work associated with quality assurance.
Quality control focuses primarily on inspecting, measuring, and verifying deliverables and results against quality requirements. The question specifically describes auditing requirements and quality control measurements, which is a quality assurance activity.
The key word in the scenario is auditing. Quality assurance is process-oriented and evaluates whether the appropriate quality standards, processes, and operational definitions are being applied. Quality control is more focused on measuring and inspecting actual results and deliverables.
Auditing quality processes, standards, and quality-control results -> Quality Assurance. Inspecting or measuring deliverables/results -> Quality Control.
Incorrect. A requirements traceability matrix is used primarily to establish and maintain relationships between requirements and related elements such as business objectives, solution components, test cases, and other requirements. It helps ensure coverage and traceability, but its primary purpose is not to detect ambiguous or unverifiable wording within requirements.
Incorrect. A resource checklist helps verify that necessary resources, capabilities, or resource-related considerations have been identified. It does not provide a structured review of requirement quality and therefore is not the appropriate technique for identifying ambiguity or lack of verifiability.
Incorrect. Fishbone analysis, also known as cause-and-effect or Ishikawa analysis, is primarily used to investigate and organize the potential root causes of a problem. It is useful for root-cause analysis, but it is not primarily a technique for reviewing requirements for ambiguity or verifiability.
Correct. A team peer review allows knowledgeable team members to examine requirements and identify quality problems such as ambiguity, inconsistency, incompleteness, unclear wording, and lack of verifiability. Therefore, it is the best technique among the available choices.
Requirements should be reviewed to ensure that they are clear, complete, consistent, and verifiable. Peer review provides an independent examination by other team members and helps identify defects in requirement quality before those requirements proceed further in the lifecycle.
Ambiguous, unclear, or unverifiable requirements -> Peer Review. Traceability Matrix -> relationships and coverage. Fishbone Analysis -> root-cause analysis.
Score: 0%
Recommended time:
Actual time:
Back to Exams & Quizzes Management