Question 1. Sam has asked you to trace a particular requirement for him. What does ‘to trace a requirement’ mean?
A. Tracing a requirement means to look at a requirement and the other related requirements. It links risk, cost, quality, and scope elements to stakeholder and solution requirements and to other artifacts created by the team and to solution components.
B. Tracing a requirement means to look at a requirement and the others to which it is related. It links business requirements to stakeholders and solution requirements to other artifacts created by the team and to solution components.
C. Tracing a requirement means to look at a requirement and the others to which it is related. It links business requirements to components in the project’s work breakdown structure
D. Tracing a requirement means to track a requirements from its first identification all the way to its completion to see what issues, risks, costs, quality, and defects have surrounded the requirement
The correct answer is B.
Explanation:
To “trace a requirement” means to understand how a specific requirement connects to other aspects of the project, such as business needs, stakeholder expectations, and various solution components or artifacts.
Here’s a breakdown of why B is correct and why the others are not as precise:
• Option B accurately describes the tracing process, where business requirements are linked to stakeholders and then further connected to solution requirements and other project artifacts. This establishes a clear path from the initial business requirements through to the detailed solution elements, helping to ensure that each requirement is addressed correctly throughout the project.
• Option A includes elements like “risk, cost, quality, and scope,” which are important but not the main focus of requirement tracing. Requirement tracing typically focuses on the direct connection between business needs and solution elements, rather than on these project management aspects.
• Option C simplifies the tracing process by only mentioning the link to the project’s work breakdown structure. While a work breakdown structure may include elements tied to requirements, it doesn’t fully encompass the end-to-end tracing needed.
• Option D focuses on tracking a requirement’s entire lifecycle, which involves monitoring but does not fully cover the relational aspect of tracing a requirement to stakeholders and solution artifacts.
Thus, Option B is the most accurate choice for what it means “to trace a requirement.”
Question 2. Which of the following is NOT an input into the Communicate Requirements task?
A. Requirements
B. BA Communication plan
C. BA Performance metrics
D. Requirements package
The correct answer is:
C. BA Performance metrics
Explanation:
In the Communicate Requirements task, business analysts focus on delivering requirements to stakeholders in a clear, understandable format. The task involves communicating requirements, often through presentations, documentation, and discussions, so stakeholders understand and can act on them.
Each option is evaluated as follows:
1. A. Requirements: Requirements are a key input, as they are the actual information that needs to be communicated to stakeholders. Business analysts must communicate the details of these requirements effectively.
2. B. BA Communication Plan: The Business Analysis Communication Plan outlines how and when requirements should be communicated, who the audience is, and what methods to use. It helps ensure the communication process aligns with stakeholder needs and expectations.
3. C. BA Performance Metrics: This is NOT an input for the Communicate Requirements task. Performance metrics are used to assess the business analyst’s effectiveness in their work, but they are not directly relevant to the task of communicating requirements.
4. D. Requirements Package: A requirements package is a compilation of requirements, often structured to be shared with stakeholders. It provides a cohesive set of information to facilitate understanding and decision-making, making it a vital input for this task.
Therefore, C. BA Performance metrics is the correct answer because it does not directly contribute to the process of communicating requirements to stakeholders.
Question 3. Jane is a BA working on business analysis using a plan-driven approach. The Marketing team stakeholder group has introduced new requirements, claiming that they will not be able to perform detailed customer analysis unless their requirements are added. However, these new requirements are not within the approved solution scope. Which of the following actions is Jane LEAST likely to take?
A. Amend the new requirements.
B. Change the BA approach to be more change-driven.
C. Amend the solution scope.
D. Facilitate communication between conflicting stakeholders.
To answer this question, let’s analyze each option and consider what a business analyst (BA) using a plan-driven approach is likely or unlikely to do. In a plan-driven approach, there’s a strong focus on pre-defined processes, thorough documentation, and limited flexibility for changes, especially after the solution scope has been approved.
Option Analysis
A. Amend the new requirements:
This option suggests adjusting or refining the new requirements from the Marketing team. Although these requirements are outside the approved scope, a BA might consider refining them to better understand their impact. However, simply amending the requirements does not directly address the fact that they are outside the approved solution scope, so this action is possible but not ideal.
B. Change the BA approach to be more change-driven:
Switching from a plan-driven to a change-driven approach would be quite drastic, especially since Jane’s current approach focuses on maintaining the original plan and scope. A change-driven approach allows for more adaptability, but this shift is generally rare in plan-driven projects, as it requires fundamental changes to how the project is managed. Therefore, this is the action Jane is least likely to take.
C. Amend the solution scope:
Expanding or modifying the solution scope is an option, but in a plan-driven approach, such changes are usually minimized to avoid disrupting the project’s stability. However, if the requirements from the Marketing team are deemed critical and have a substantial business impact, the BA might consider it, following a formal change management process. Thus, this option is unlikely but still more plausible than completely changing the BA approach.
D. Facilitate communication between conflicting stakeholders:
This is a standard action in both plan-driven and change-driven approaches. A BA often acts as a facilitator to ensure that all stakeholders are aligned, especially when new requirements arise that may impact the existing scope. Therefore, this action is the most likely.
Conclusion
The least likely action Jane would take is B. Change the BA approach to be more change-driven, as this would conflict with the structured, stable nature of the plan-driven approach.
Answer: B
Question 4. Fred works in the internal audit department at his company. He is in charge of working with a selected group of people that make the decisions regarding the disposition and treatment of changing requirements. What group does Fred work with?
A. Change control board
B. Internal Audit Group
C. Change driven methodology team
D. Change initiative council
The correct answer is:
A. Change control board
Explanation:
The Change Control Board (CCB) is a group responsible for reviewing, evaluating, approving, or rejecting changes to a project or system. They manage changes in requirements and make decisions on how to handle these changes. Since Fred is working with a group that decides on the treatment and disposition of changing requirements, it aligns with the role of a Change Control Board.
Let’s review why the other options are less suitable:
• B. Internal Audit Group: This group generally focuses on reviewing and ensuring compliance with company policies, controls, and regulations, rather than making decisions on changing requirements.
• C. Change Driven Methodology Team: This team might be involved in implementing a change-driven approach, but they do not specifically oversee the decision-making process for requirement changes.
• D. Change Initiative Council: While this might sound relevant, a “Change Initiative Council” is not a standard term associated with managing requirement changes; it’s more often associated with broader organizational change initiatives.
Therefore, the Change Control Board (CCB) is the most accurate answer.
Question 5. Requirements packages can include all of the following formats EXCEPT:
A. Informal documentation
B. Presentation
C. Models
D. Formal documentation
The correct answer is:
B. Presentation
Explanation:
When we talk about requirements packages, we’re discussing ways of organizing and documenting the requirements for a system or project. Requirements packages typically include the following types:
• Informal Documentation (A): This includes things like notes, sketches, or emails that help communicate requirements informally. It’s often used for initial brainstorming or to share ideas quickly.
• Models (C): Requirements models are graphical or structured representations of requirements, such as UML diagrams, flowcharts, or use case diagrams. They help visually organize and analyze requirements.
• Formal Documentation (D): This is a structured and detailed document that precisely describes requirements in a standardized way. It ensures clarity and accuracy for both stakeholders and developers.
Presentation (B) is the correct answer because, while presentations can be used to share or summarize requirements, they aren’t typically a primary or essential part of a requirements package. Presentations are less formal and generally serve as a means to communicate or review requirements, rather than as an organized structure for documenting them.
Question 6. _ is used to help familiarize the project team with the existing solution scope:
A. Brainstorming
B. Context scope diagram
C. Requirements workshop
D. Structured walkthrough
The correct answer is:
D. Structured walkthrough
Explanation
A structured walkthrough is a formal review technique that allows the project team to thoroughly go over and familiarize themselves with the existing solution scope. During a structured walkthrough, team members review the current state of the project or solution, examining details, workflows, and relevant documents. This process helps ensure that everyone on the team understands the scope, limitations, and current requirements of the solution.
• A. Brainstorming: Brainstorming is generally used for generating ideas or finding solutions to problems rather than reviewing existing solutions.
• B. Context scope diagram: This tool visually represents the scope but does not provide the depth of familiarity that a walkthrough session would offer.
• C. Requirements workshop: A requirements workshop is focused on gathering requirements, not reviewing the current scope in detail.
Therefore, a structured walkthrough is best suited for understanding and familiarizing the team with the existing solution scope.
Question 7. When communicating requirements, which of the following stakeholders usually prefers to have high-level summaries to help them understand the impact of the requirements?
A. Implementation SME.
B. Sponsor.
C. Regulator.
D. Domain SME.
The correct answer is:
B. Sponsor.
Explanation:
• Sponsor: The sponsor is typically a high-level decision-maker, such as an executive or senior leader, who is more interested in understanding the overall impact, value, and alignment of requirements with strategic goals. They often do not need the technical details but prefer high-level summaries that focus on how requirements will affect the organization, costs, timelines, and potential risks. This helps them make informed decisions on whether to support or prioritize the project.
• Implementation SME (Subject Matter Expert): These stakeholders are focused on the technical and practical details needed to implement requirements, such as specific features, constraints, and resource needs. They usually prefer detailed information rather than high-level summaries.
• Regulator: Regulators often require detailed information about requirements to ensure compliance with legal and industry standards. While they may benefit from a summary, they generally need in-depth details to evaluate regulatory impact.
• Domain SME (Subject Matter Expert): Domain SMEs are specialists in the specific area related to the project. They usually need detailed requirements to ensure that all nuances of their expertise are addressed properly, rather than just high-level summaries.
Thus, sponsors are the stakeholders most likely to prefer high-level summaries.
Question 8. Which of the following statements best describe traceability?
A. Traceability metrics are used by the Change Management Board to approve or deny request for change.
B. Traceability assists in managing changes to the requirements that will occur after the requirements are base lined
C. Traceability requirements supplement business requirements and functional requirements.
D. Traceability assists in managing accountability for requirements activities that are performed by stakeholders outside of the requirements team.
The correct answer is:
B. Traceability assists in managing changes to the requirements that will occur after the requirements are baselined.
Explanation:
Traceability is a concept in requirements management that allows teams to link requirements through the development process, helping to manage and assess changes after requirements are initially approved (or “baselined”). This involves tracing each requirement through design, implementation, testing, and deployment.
Why Each Option Is Right or Wrong:
• A. Traceability metrics are used by the Change Management Board to approve or deny requests for change.
• Incorrect: While traceability metrics can provide valuable information about requirements and their dependencies, they are not specifically used by the Change Management Board to approve or deny changes. Change requests are generally evaluated based on their impact, costs, and risks rather than strictly on traceability metrics.
• B. Traceability assists in managing changes to the requirements that will occur after the requirements are baselined.
• Correct: Once requirements are baselined, traceability helps in tracking the impact of any requested changes on downstream work products and other related requirements, making it easier to understand how changes might affect the project.
• C. Traceability requirements supplement business requirements and functional requirements.
• Incorrect: Traceability is not an additional type of requirement but rather a process to link requirements across development stages. It connects business and functional requirements to each other and to design elements, tests, and other project artifacts.
• D. Traceability assists in managing accountability for requirements activities that are performed by stakeholders outside of the requirements team.
• Incorrect: While traceability can indirectly support accountability by documenting dependencies, its primary purpose is to manage the connections and impacts of requirements rather than directly managing accountability for specific tasks.
In summary, traceability is primarily used to manage and understand the changes to requirements post-baselining, making Option B the best description.
Question 9. Which of the following must happen to enable requirements re-use?
A. The requirements must be in a document repository
B. The requirements have to be packaged and stored
C. The requirements need to be approved and baselined.
D. The requirements must be clearly named and defined
To enable requirements re-use, the correct answer is:
B. The requirements have to be packaged and stored
Explanation:
For requirements to be reusable, they must be packaged in a way that allows them to be stored, retrieved, and applied in future projects or phases. Packaging typically involves organizing requirements into a standardized, modular format that makes them easy to find and apply. Additionally, storing these packaged requirements in a centralized location, such as a requirements management system, supports consistency and accessibility across projects.
Let’s look at each option:
• A. The requirements must be in a document repository: While storing requirements in a repository can help with organization and access, it doesn’t guarantee reusability on its own. Requirements must still be packaged in a way that allows them to be easily adapted to new contexts.
• B. The requirements have to be packaged and stored: This option is correct because “packaging” suggests a structure that supports modularity and reuse. When requirements are stored in this structured format, they become more accessible and adaptable for future use.
• C. The requirements need to be approved and baselined: Approval and baselining are necessary for version control and project tracking, but they do not directly enable reuse. Reusability focuses more on structure, accessibility, and adaptability rather than on final approval status.
• D. The requirements must be clearly named and defined: Clear naming and definitions are important for understanding requirements, but they do not alone make requirements reusable. Reuse typically requires an organized and accessible packaging system rather than just clarity.
In summary, packaging and storing requirements (B) is essential to enable re-use, as it ensures they are accessible and formatted for easy adaptation in future projects.
Question 10. You are being tested by a senior BA in your firm and she wants to know which is not true of these statements.
A. Allocation is forward traceability of a requirement
B. Requirement allocation allows the business analyst to trace the subset of requirement that are allocated to each of the solution component
C. Cover relationship between requirement is when a requirement comes from another requirement
D. Communicating requirement is performed in conjunction with most of the task in the other knowledge areas.
To answer this, let’s analyze each option in terms of requirement traceability and allocation concepts in business analysis:
1. Option A: “Allocation is forward traceability of a requirement”
• Explanation: Allocation in business analysis refers to distributing or assigning requirements to specific solution components (e.g., software modules, hardware elements). Forward traceability, however, is about tracking a requirement from its origin through to its implementation to ensure that it has been met. So, allocation isn’t specifically the same as forward traceability. This statement is misleading and likely false.
2. Option B: “Requirement allocation allows the business analyst to trace the subset of requirements that are allocated to each of the solution components”
• Explanation: This is a true statement. Allocation helps a business analyst manage and track which parts of a requirement are designated to particular solution components. This traceability is crucial in ensuring that all components meet their assigned requirements.
3. Option C: “Cover relationship between requirements is when a requirement comes from another requirement”
• Explanation: This statement is incorrect. The “cover” relationship generally implies that one requirement fully encompasses another, not that it originates from another. A dependency or derivation relationship would better describe when one requirement is derived from another. This statement is likely false.
4. Option D: “Communicating requirements is performed in conjunction with most of the tasks in the other knowledge areas”
• Explanation: This statement is true. Communicating requirements is a continuous process and intersects with various knowledge areas in business analysis, such as elicitation, solution evaluation, and requirements lifecycle management.
Conclusion
The two statements that are not true are Option A and Option C. If the question asks for a single answer, Option A is the best choice since it directly misrepresents the concept of allocation as forward traceability.