Business Analysis Frameworks

Correct Answer: First defer the Could Have requirements to save resources.

In the MoSCoW prioritization method, requirements are categorized as Must Have, Should Have, Could Have, and Won't Have. When facing budget cuts, the project manager should first consider deferring or removing the lower-priority requirements. 'Could Have' requirements are desirable but not necessary for the project's immediate success and can be deferred or removed with minimal impact. 'Must Have' requirements are critical and cannot be compromised. 'Should Have' requirements are important but less critical than 'Must Have' and are considered after 'Could Have' if further cuts are needed. 'Won't Have' requirements are already excluded from the current scope, so they cannot provide additional resource savings.

Correct Answer: Source of the requirement

In a Requirements Traceability Matrix (RTM), the 'Source of the requirement' is essential for tracking the provenance of each requirement throughout the project life cycle. This element allows stakeholders to understand where the requirements originated, which can be critical for validating requirements, managing scope, and facilitating communication among stakeholders. For example, sources can be stakeholders, existing systems, legal requirements, or market needs. The 'Name of the requirement owner' is important for responsibility but is not critical for tracking the requirement through the project life cycle. 'Estimated time to implement the requirement' is valuable for planning purposes but does not inherently provide traceability of the requirement itself. 'Tools used for requirements development' might be useful information, but it does not contribute directly to the traceability of individual requirements.

Correct Answer: To describe how users interact with the system to meet their goals.

Use cases in Use Case Modeling primarily serve to describe how users interact with a system to meet their goals. They focus on capturing the functional requirements by illustrating the interactions between users (actors) and the system. This ensures that the system is designed to fulfill the users' needs and provides a clear understanding of user expectations. The other options pertain to system components interaction, data flow within the system, and documentation of technical specifications, which are covered by other modeling techniques like component diagrams, data flow diagrams, and technical design documents, respectively. These do not focus on the user-system interaction from the user's perspective, which is the main purpose of use cases.