Free CBAF-001 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The process view of an organization conceptualizes the business as a collection of end-to-end processes that create and deliver value. The primary driver and beneficiary of these processes is the customer. This perspective shifts the focus from internal departmental functions to the horizontal, cross-functional flow of work required to satisfy a customer's request or need. Therefore, a process-oriented view is fundamentally customer-centric, as the success of each process is measured by its ability to deliver a valuable outcome to the customer.

B. It focuses solely on the internal view of the organization.

This is incorrect. The process view explicitly considers external actors, such as customers who trigger processes and receive outputs, and suppliers who provide inputs.

C. It focuses on the functions of an organization.

This describes the traditional functional or "silo" view, which the process view directly contrasts by emphasizing cross-functional, end-to-end workflows instead of departmental activities.

D. It focuses on the organizational structure.

This describes the hierarchical view, typically represented by an organization chart. The process view is concerned with how work gets done, not the formal reporting structure.

---

1. Dumas

M.

La Rosa

M.

Mendling

J.

& Reijers

H. A. (2018). Fundamentals of Business Process Management (2nd ed.). Springer. In Chapter 1

Section 1.3

"The Process-Centered Organization

" it is stated: "In a process-centered organization... they have a customer-oriented mindset. They know who their customers are and how their work contributes to the value that these customers receive." (p. 15).

2. Hammer

M.

& Champy

J. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness. The foundational concept of reengineering is built on redesigning business processes to achieve dramatic improvements

with a core principle being to organize around outcomes (which benefit the customer)

not tasks. (Chapter 2

"Reengineering—The Path to Change").

3. Kohlbacher

M. (2010). The effects of process orientation: a literature review. Business Process Management Journal

16(1)

135-152. https://doi.org/10.1108/14637151011017985. The paper synthesizes literature showing that process orientation is characterized by a strong customer focus

stating

"Customer focus is a central element of process-orientation." (Section: "Elements of process-orientation

" p. 138).

The 'Source' attribute in a requirements catalogue is used to identify the origin of the requirement. This is crucial for traceability, allowing analysts and developers to understand where the requirement came from. The source is typically the specific business user, stakeholder, group, or even a source document (e.g., a business case or policy document) that initiated the request. Recording the source ensures that the original requester can be consulted for clarification or during the validation process.

A. Owner: The 'Owner' is the individual or group responsible for the requirement's validation and ensuring it is met, not the person who originally requested it.

B. Justification: The 'Justification' or 'Rationale' explains why the requirement is necessary by linking it to business objectives, not who requested it.

C. Author: The 'Author' is the person who documented the requirement, which is typically the business analyst, not the business user who originated the need.

---

1. Sommerville

I. (2016). Software Engineering (10th ed.). Pearson. In Chapter 4

Section 4.5.2

"Requirements traceability

" the text emphasizes the importance of tracing requirements back to their source

which includes the stakeholders who proposed them.

2. Robertson

S.

& Robertson

J. (2012). Mastering the Requirements Process: Getting Requirements Right (3rd ed.). Addison-Wesley Professional. The widely-used Volere Requirements Specification Template

detailed in Appendix A

explicitly includes "Source" (Attribute #7) to record the originator of the requirement.

3. Pohl

K. (2010). Requirements Engineering: Fundamentals

Principles

and Techniques. Springer. In Chapter 1

Section 1.2.2

"Requirements Attributes

" the 'Source' is defined as a fundamental attribute for documenting the origin of a requirement to ensure traceability. DOI: https://doi.org/10.1007/978-3-642-12578-2

4. University of Toronto

Department of Computer Science. (2020). CSC301: Introduction to Software Engineering

Lecture 3: Requirements. Course materials discuss the attributes of a good requirement

listing 'Source' as a key element for traceability to the stakeholder or document of origin. (See slide on "Documenting Requirements").

Michael Porter's Value Chain model categorizes a firm's activities into two types: primary and support. Support activities provide the infrastructure that allows the primary activities to occur. The four generic support activities are Procurement, Technology Development, Human Resource Management, and Firm Infrastructure. Option C is the only choice that lists activities belonging exclusively to this support category. These activities, such as purchasing inputs, managing personnel, and developing new technologies, underpin the entire value chain but are not directly involved in the physical creation, sale, or transfer of the product to the buyer.

A. This option incorrectly includes "service" and "marketing and sales," which are primary activities directly related to the customer.

B. This list consists entirely of primary activities (inbound logistics, operations, outbound logistics) that are directly involved in creating and delivering the product.

D. This option incorrectly includes "service," which is a primary activity focused on enhancing or maintaining the product's value after sale.

1. Porter

M. E. (1985). Competitive Advantage: Creating and Sustaining Superior Performance. Free Press. In Chapter 2

"The Value Chain and Competitive Advantage

" Porter defines the support activities as procurement

technology development

human resource management

and firm infrastructure (pp. 40-45).

2. MIT OpenCourseWare. (2006). 15.902 Strategic Management I

Fall 2006. Massachusetts Institute of Technology. Session 5 Lecture Notes

"Industry Analysis II: The Value Chain

" explicitly diagrams and lists Procurement

Technology Development

Human Resource Management

and Firm Infrastructure as the four support activities. (Available at: ocw.mit.edu).

A mind map is a visual diagram used to organize information around a central subject. It is an effective tool for documenting the outcomes of a workshop because it can capture and structure ideas, discussion points, decisions, and their relationships in a non-linear, graphical manner. This visual representation helps stakeholders understand the connections between different elements discussed and provides a clear, consolidated summary of the workshop's results, making it an excellent documentation technique for collaborative sessions.

B. Brainwriting: This is a technique for silent and parallel idea generation during a workshop, not a method for documenting the final, consolidated outcomes.

C. Round-robin: This is a facilitation technique used during a workshop to elicit contributions from all participants sequentially, not a tool for documenting the overall results.

D. Stepwise refinement: This is a top-down design strategy used in software engineering to break down a system into detailed components; it is not a workshop documentation method.

1. de Oliveira

O. H. B.

de Oliveira

T. C.

& do Prado Leite

J. C. S. (2009). Using Mind Maps to Elicit and Model Crosscutting Requirements. In Proceedings of the 2009 ACM Symposium on Applied Computing (pp. 599–600). Association for Computing Machinery. This paper explicitly discusses the use of mind maps as a tool to "support the elicitation and modeling of requirements

" demonstrating its role in capturing and structuring information from elicitation activities like workshops. (DOI: https://doi.org/10.1145/1529282.1529411)

2. Pohl

K. (2010). Requirements Engineering: Fundamentals

Principles

and Techniques. Springer Publishing. In Chapter 6

Section 6.3.2 "Creativity Techniques

" mind mapping is described as a technique for structuring thoughts and ideas

which is central to documenting workshop outputs. In contrast

techniques like brainwriting are categorized purely for idea generation.

3. University of Calgary

Schulich School of Engineering. (n.d.). SENG 471: Software Requirements Engineering

Lecture 6 - Elicitation. Courseware. Slide 21

"Brainstorming

" presents mind mapping as a method to organize ideas generated during brainstorming sessions

which are a core component of many workshops. It distinguishes this from idea generation techniques themselves.

The elements listed—description, impact assessment, probability, and countermeasures—are the core components of risk analysis and management. A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives. These components are systematically recorded in a risk register or risk log to track, analyze, and plan responses to potential threats and opportunities throughout a project's lifecycle.

A. Requirements define a need or objective to be fulfilled. While they are described, they are not events with an associated probability or countermeasures.

C. Stakeholders are individuals or groups with an interest in the project. Their influence and impact are analyzed, but they are not risks themselves.

D. Key Performance Indicators (KPIs) are quantifiable measures used to track progress toward a goal. They are metrics, not uncertain events requiring countermeasures.

1. Source: MIT OpenCourseWare

Course 1.040 Project Management

Fall 2006.

Reference: Lecture 15: Risk Management

Slide 11 ("Risk Register"). The slide outlines the typical columns in a risk register

which include "Risk Description

" "Probability

" "Impact

" and "Mitigation/Contingency Plan" (which are countermeasures).

Link: https://ocw.mit.edu/courses/1-040-project-management-fall-2006/resources/15riskmgmt/

2. Source: University of Washington

Professional & Continuing Education

Course: Project Management.

Reference: The course curriculum on "Project Risk Management" details the process of identifying risks and creating a risk register. It specifies that each risk entry should include a description

probability

impact

and a response plan (countermeasure).

Link: (Content is generally available through course materials

but the principles are outlined in public descriptions) https://www.pce.uw.edu/courses/project-management

3. Source: Chapman

C.

& Ward

S. (2004). Why is project risk management important? A B C D of an effective framework for the effective management of project risk. International Journal of Project Management

22(8)

653-663.

Reference: Section 3

"A framework for the effective management of project risk

" discusses the essential steps

including risk identification (description)

risk assessment (quantifying probability and impact)

and planning risk responses (countermeasures).

DOI: https://doi.org/10.1016/j.ijproman.2004.08.007

The diagram uses Crow's Foot notation to represent the relationship between entities. The symbols at the end of the relationship line indicate cardinality and modality. The notation on the Order side is a circle followed by a crow's foot (O>--), which represents "zero or many". Reading the relationship from the Customer entity to the Order entity, this means a single Customer can be associated with zero or many Orders. Therefore, the statement "A customer may place many orders" correctly interprets this one-to-many relationship. The notation on the Customer side (||) indicates that an Order must be associated with "one and only one" Customer.

A. An order may be placed by many customers.

This is incorrect. The "one and only one" symbol (||) on the Customer side of the relationship dictates that each order must be linked to exactly one customer.

C. A customer may never place an order.

This statement is technically true because of the "zero" optionality (O), but it is an incomplete description of the business rule. It only addresses the optionality, not the "many" cardinality, making option B a more comprehensive answer.

D. An order need not be placed by a customer.

This is incorrect. The mandatory "one and only one" symbol (||) on the Customer side explicitly states that an order must be placed by a customer to exist.

---

1. Coronel

C.

& Morris

S. (2019). Database Systems: Design

Implementation

and Management (13th ed.). Cengage Learning.

Section 4.3.3

"Connectivity and Cardinality": This section details the use of Crow's Foot notation. It explains that the crow's foot symbol represents the "many" side of a relationship

and the circle represents an optional relationship (zero). The combination (O>--) is explicitly defined as "zero or many". The double bar (||) is defined as "one and only one" (mandatory single).

2. Gillenson

M. L. (2011). Fundamentals of Database Management Systems (2nd ed.). John Wiley & Sons.

Chapter 3

"The Entity-Relationship Model"

Figure 3.13 "The Symbols Used in the Crow’s Foot Notation": This figure provides a clear legend for all Crow's Foot symbols. It shows that a circle represents "zero

" a single bar represents "one

" and the crow's foot represents "many." The combination of these symbols defines the minimum and maximum cardinality

confirming that O>-- means a minimum of zero and a maximum of many.

3. James Madison University

College of Integrated Science and Engineering. (n.d.). ERD Symbols and Meanings.

CS 350 Course Material: This university resource provides a table of ERD symbols. It defines the notation O>-- as representing "zero or many" and || as "one and only one

" which directly supports the interpretation of the relationship in the question. (Available via university courseware portals).

A rich picture is a free-form diagramming technique originating from Soft Systems Methodology (SSM). Its primary purpose is to capture the complexities of a problematic business situation in a holistic and unstructured way. It allows the business analyst to represent not only the processes and structures ('hard' facts) but also the human and social elements such as concerns, relationships, conflicts, and culture ('soft' facts). This makes it the most suitable tool among the choices for documenting the diverse range of issues that are typically uncovered during the initial investigation of a business situation, before any formal analysis or modeling is undertaken.

B. The 'to be' process model: This diagram illustrates a proposed future state of a business process. It is a solution-oriented model, not a tool for documenting existing problems.

C. The business activity model: This is a conceptual model that defines the essential activities required to fulfill a specific business perspective, not a tool for capturing existing issues.

D. The use case diagram: This UML diagram describes the functional requirements of a system by showing interactions between users (actors) and the system, not broad business problems.

1. Checkland

P.

& Poulter

J. (2006). Learning for Action: A Short Definitive Account of Soft Systems Methodology and its use for Practitioners

Teachers and Students. Wiley. In Chapter 2

the authors describe the rich picture as a key part of "finding out about the problem situation

" emphasizing its role in capturing the situation's complexity

including conflicts and issues

before it is formally defined.

2. The Open University. (2019). Diagramming for development/Diagrams for thinking. In TB871: Mastering systems thinking in practice. Section 5.1

"Rich Pictures

" states: "A rich picture is a way to explore the issues in a problematic situation... It should try to represent the 'soft' as well as the 'hard' aspects of the situation

that is

the human and cultural aspects as well as the structures and processes."

3. Avison

D.

& Wood-Harper

T. (1990). Multiview: An Exploration in Information Systems Development. McGraw-Hill. In the discussion of Soft Systems Methodology (Chapter 4)

the rich picture is presented as the primary tool for the initial "problem situation unstructured" stage

used specifically to gather and represent diverse viewpoints and issues from stakeholders.

The activity described is a classic example of gap analysis. A Business Activity Model (BAM) represents a conceptual, "to-be" or ideal state of the business activities required to achieve a specific objective or perspective. The "current business situation" represents the "as-is" state. By comparing the two, a business analyst identifies the differences, or "gaps," between the required activities and the activities that are actually being performed. This analysis is fundamental for identifying areas that need change, improvement, or development to align the current operations with the desired future state.

A. Conceptual modelling: This is the process of creating the Business Activity Model (BAM) itself, not the subsequent act of comparing it to the current situation.

B. Analysing perspective: This is a preliminary step in Soft Systems Methodology (SSM) where the analyst understands a stakeholder's worldview (Weltanschauung) to formulate a root definition, which then informs the BAM.

D. Defining CATWOE: This is a mnemonic technique (Customers, Actors, Transformation, etc.) used to structure thinking and create a robust "root definition" before building the conceptual model (BAM).

1. Paul

D.

Cadle

J.

& Yeates

D. (2014). Business Analysis (3rd ed.). BCS

The Chartered Institute for IT.

Section 10.2

"The purpose of gap analysis

" states: "Gap analysis is used to compare two sets of data... A common use of gap analysis is to compare a ‘current’ or ‘as is’ state with a ‘future’ or ‘to be’ state." The BAM serves as the 'to be' model for this comparison against the 'as is' current situation.

2. Checkland

P. (1999). Soft Systems Methodology: A 30-Year Retrospective. John Wiley & Sons.

Chapter 2

"The Established Form of SSM

" describes the seven-stage model. Stage 5 is the "Comparison of conceptual models with reality." The text explains this stage involves comparing the models (BAMs from Stage 4) with the real-world situation (from Stage 2) to find differences and spark debate about change. This comparison is the essence of gap analysis in the SSM context.

3. The Open University. (2019). T849 Systems thinking in practice: 4.2 The seven-stage model. OpenLearn.

In the description of Stage 5

it states: "The purpose of the comparison is to generate a debate with concerned people in the situation about possible changes which might be made to improve the situation... The comparison between the model and the 'real world' is the point in SSM at which the intuitive perception of the problem situation and the rational

explicit

systems model of a purposeful activity system are brought together." This act of bringing together the model (BAM) and the real world to find differences is gap analysis.

An avoided cost is an expense that would have been incurred if a particular course of action were not taken. In this scenario, the IT department has a mandatory, required expenditure of $2 million for a hardware upgrade if they continue with their current operating system. By choosing the alternative proposal—switching to a new operating system—the company will no longer need to spend that $2 million. Therefore, the $2 million is the "avoided cost" associated with the director's proposal. This avoided cost is treated as a financial benefit when evaluating the business case for the new project.

B. $4 million is the incremental cost of the new proposal ($6 million - $2 million), not the cost that was avoided.

C. $6 million is the total cost of the new project itself, representing a new expenditure, not an avoided one.

D. $8 million is the irrelevant sum of both figures and does not represent any standard financial metric in this context.

1. Garrison

R. H.

Noreen

E. W.

& Brewer

P. C. (2021). Managerial Accounting (17th ed.). McGraw-Hill. In Chapter 13

"Relevant Costs for Decision Making

" the concept of an "avoidable cost" is defined as a cost that can be eliminated by choosing one alternative over another. The $2 million upgrade is a cost that is eliminated by choosing the alternative

fitting this definition.

2. University of California

Office of the President. (2016). Cost Benefit Analysis Guidelines. Page 10

Section "Identify and Monetize Benefits." The guide states

"Benefits are the positive outcomes of a project... Benefits can include... cost avoidance (e.g.

avoiding the need to hire more staff by automating a process)." The $2 million hardware cost is a future expense that is avoided by implementing the new system.

3. Boardman

A. E.

Greenberg

D. H.

Vining

A. R.

& Weimer

D. L. (2018). Cost-Benefit Analysis: Concepts and Practice (5th ed.). Cambridge University Press. Chapter 2

"The Foundations of Cost-Benefit Analysis

" explains that the benefits of a project are the value of its outputs

which can include costs that are now avoided. The framework for CBA involves comparing a "with-project" world to a "without-project" world. In the "without-project" world

the $2 million cost is incurred.

The Internal Rate of Return (IRR) is a fundamental metric in financial analysis and capital budgeting. By definition, the IRR is the specific discount rate at which the Net Present Value (NPV) of a series of cash flows (both inflows and outflows) equals zero. When a business case states that the IRR has been calculated, it means this break-even discount rate has been identified. Therefore, the statement that the Net Present Value is zero is inherently true at the point of the IRR. This rate is then compared to a company's required rate of return or cost of capital to decide whether to accept or reject the project.

A. The Net Present Value is not known.

Incorrect. The NPV is explicitly known to be zero at the IRR, as this is the core definition of the IRR calculation.

B. The DCF Rate is not known.

Incorrect. The IRR is the specific Discounted Cash Flow (DCF) rate that makes the project's NPV equal to zero.

D. The DCF Rate is Zero.

Incorrect. The IRR is the calculated DCF rate, which is a percentage representing the project's return; it is rarely, if ever, zero.

1. Brealey

R. A.

Myers

S. C.

& Allen

F. (2020). Principles of Corporate Finance (13th ed.). McGraw-Hill Education. In Chapter 5

Section 5-2

"The Internal Rate of Return Rule

" the text states

"The internal rate of return (IRR) is defined as the rate of discount that makes NPV = 0."

2. Massachusetts Institute of Technology. (2009). 15.401 Finance Theory I

Fall 2008. MIT OpenCourseWare. In "Lecture 3: The NPV Rule and its Competitors

" the lecture notes define IRR as "the discount rate that sets NPV to zero."

3. Berk

J.

& DeMarzo

P. (2017). Corporate Finance (4th ed.). Pearson. In Chapter 7

Section 7.3

"The Internal Rate of Return Rule

" the IRR is defined as "the interest rate that sets the net present value of the cash flows equal to zero."

Acceptance criteria are the conditions that a software product must meet to be accepted by a user, customer, or other stakeholder. These criteria are derived directly from the business and user requirements. Therefore, the most logical and effective time to define them is during the requirements analysis phase, once the deliverables (i.e., the requirements themselves) have been agreed upon. Defining them at this stage ensures that the development team has a clear, unambiguous target and that the final product will be evaluated against the same expectations that were established at the outset. This practice prevents scope creep and aligns development and testing with the user's definition of success.

A. Defining criteria after the system design is too late; acceptance is based on meeting business requirements, not on conforming to a technical design.

C. The criteria must be defined before testing begins to serve as the basis for the tests; defining them after system testing is illogical.

D. This describes a pilot or beta testing feedback process, not the initial definition of formal acceptance criteria which must precede development.

1. Wiegers

K. E.

& Beatty

J. (2013). Software Requirements (3rd ed.). Microsoft Press. In Chapter 20

"Acceptance Criteria

" the authors state

"Acceptance criteria are best written when the requirements are being elicited and specified... Defining acceptance criteria during elicitation helps you gain a clearer understanding of what the user has in mind for a particular requirement." This directly links the definition of acceptance criteria to the requirements analysis phase.

2. Pohl

K. (2010). Requirements Engineering: Fundamentals

Principles

and Techniques. Springer. In Section 3.3.3

"Documenting Requirements

" the text emphasizes that for a requirement to be of high quality

it must be verifiable. It states

"For each requirement

its fit criteria (also called acceptance criteria) should be defined... This should be done when the requirement is specified." This confirms that criteria are defined concurrently with requirements specification.

3. University of Toronto. (n.d.). CSC301: Introduction to Software Engineering - Lecture on Validation and Verification. Department of Computer Science. Course materials explain that acceptance testing is a validation activity where tests are designed to check if the system meets the customer's requirements. The test cases for acceptance testing are derived from the requirements specification document

implying the criteria for acceptance are established during or after requirements analysis.

Force-field analysis, a model developed by social psychologist Kurt Lewin, is a fundamental technique for diagnosing and managing organizational change. The core principle of this analysis is to identify the various forces operating within a situation. These forces are categorized into two opposing groups: 'driving forces' that promote and push for the change, and 'restraining forces' that hinder or work against the change. The model posits that change occurs when the sum of the driving forces is greater than the sum of the restraining forces. The analysis is used to understand the equilibrium and plan interventions to enable change.

B. Forces in the competitive environment are typically analyzed using frameworks like Porter's Five Forces, which is distinct from the change-centric focus of force-field analysis.

C. The financial strength of the company is a specific factor that might be considered in a SWOT analysis or financial audit, not the central concept of force-field analysis.

D. The power of external suppliers is one specific component of a competitive analysis (Porter's Five Forces), not the holistic view of pro- and anti-change forces.

1. Cummings

T. G.

& Worley

C. G. (2015). Organization development and change (10th ed.). Cengage Learning. In Chapter 2

"The Nature of Planned Change

" the text explains Lewin's model: "Force-field analysis portrays change as a dynamic balance of forces working in opposite directions. Driving forces...push organizations toward a new state of affairs...Restraining forces...push the organization to maintain the status quo." (pp. 30-31).

2. MIT OpenCourseWare. (2006). 15.311 Organizational Processes

Lecture Notes: Lecture 16 - Managing Change. Massachusetts Institute of Technology. The lecture notes describe Lewin's Force Field Model of Change as a balance between "Driving Forces (Pressures for change)" and "Restraining Forces (Pressures against change)." This directly supports the concept of analyzing forces for and against change.

3. Burnes

B. (2004). Kurt Lewin and the Planned Approach to Change: A Re-appraisal. Journal of Management Studies

41(6)

977-1002. This paper reviews Lewin's work

stating

"Force field analysis provides a framework for looking at the factors (forces) that influence a situation. It looks at forces that are either driving movement toward a goal (helping forces) or blocking movement toward a goal (hindering forces)." (p. 985). https://doi.org/10.1111/j.1467-6486.2004.00463.x

In UML class diagrams, multiplicities are notations that specify the cardinality of an association between classes. They define the minimum and maximum number of instances (objects) of one class that can be associated with a single instance of another class. This specification is a direct translation of a business rule that governs the relationship. For example, the rule "A customer can have one or more orders" is modeled using a multiplicity of 1.. at the 'Order' end of the association with the 'Customer' class, thereby enforcing this constraint within the system's design.

A. The number of attributes is listed within the attributes compartment of the class rectangle, not defined by multiplicity on an association.

B. The number of operations is listed within the operations compartment of the class rectangle, not defined by multiplicity on an association.

C. This is imprecise. Multiplicity defines the number of objects participating in a specific association, not the total number of objects "in each class."

1. Object Management Group (OMG). (2017). Unified Modeling Language (UML)

Version 2.5.1.

Section 11.5.3.1

Associations (Semantics): "The multiplicity of an association end is a constraint on the number of instances of the Class that can be associated with a single instance of the other Class across the Association." This confirms that multiplicity is a constraint

which is a form of a business rule.

Section 7.5.4.3

Multiplicity: This section formally defines MultiplicityElement

specifying its role in defining lower and upper bounds (cardinality) for relationships.

2. Massachusetts Institute of Technology (MIT) OpenCourseWare. (2016). 6.005 Software Construction

Fall 2016.

Reading 11: UML Class Diagrams: The course material states

"An association may also have multiplicity constraints on the number of objects in a role. The multiplicity is a range [min..max] of the number of objects." This illustrates that multiplicity acts as a rule or constraint on the relationship.

3. Bock

C. (2003). UML 2.0: A Triple-Crown Standard. In Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research (CASCON '03). IBM Corp.

Riverton

NJ

USA

15. DOI: https://doi.org/10.5555/963343.963361

This paper

discussing the UML standard

implicitly supports that multiplicities on associations represent structural rules. It describes how associations and their properties (like multiplicity) define the static structure and constraints between classifiers

which are derived from business requirements.

An internal consultant's primary advantage is their pre-existing, in-depth knowledge of the host organization. This familiarity encompasses the company's culture, political landscape, formal and informal communication channels, processes, and systems. This understanding allows them to navigate the organization effectively, build rapport with stakeholders more quickly, and reduce the initial learning curve that an external consultant would face. This "insider" knowledge can lead to a more efficient analysis process and more contextually appropriate recommendations, as they are already aware of the organization's specific constraints and opportunities.

A. A broad business perspective, gained from working with multiple organizations and industries, is a characteristic advantage of an external consultant, not an internal one.

C. This payment model (pay-for-service) is typical for external contractors or consultants, not for internal employees who are generally salaried and represent a fixed cost.

D. A dispassionate, objective view is a key benefit of hiring an external consultant, who is not influenced by internal politics or long-standing biases.

1. Paul

D.

Yeates

D.

& Cadle

J. (2014). Business Analysis (3rd ed.). BCS

The Chartered Institute for IT. In Chapter 2

"The Role of the Business Analyst

" the text contrasts internal and external analysts. It explicitly states that advantages of an internal analyst include "knowledge of the business organisation

its culture and its political sensitivities" (p. 25)

directly supporting the correct answer. Conversely

it lists "a fresh

objective pair of eyes" and "a breadth of experience" as advantages of external analysts (p. 26)

refuting options A and D.

2. Purdue University. (n.d.). Internal vs. External Consultants. Purdue Online Writing Lab (OWL). In the section "Internal Consultants

" the resource notes

"Internal consultants are already familiar with the company culture

history

and norms

" which aligns directly with the reasoning for the correct answer. Retrieved from Purdue OWL website.

3. Kubr

M. (Ed.). (2002). Management Consulting: A Guide to the Profession (4th ed.). International Labour Office. Chapter 3

Section 3.3

"Internal Consultants

" discusses their strengths

noting

"The internal consultant knows the organization... He or she knows the people

the jargon

the communication channels

the formal and informal power structure..." (p. 58). This reinforces that familiarity is the key advantage.

The investigation technique described is known as creating 'Special purpose records'. This method is used when the information required for an analysis does not exist in any current documentation or system. The business analyst designs a specific form, log, or diary sheet and asks business users to record details about their tasks, events, or issues over a defined period. This creates a new, targeted dataset specifically for the investigation, capturing the actual activities performed by the user.

A. Shadowing: This is incorrect because shadowing involves the analyst directly observing a user performing their tasks in real-time, rather than the user self-reporting their activities.

B. Prototyping: This is a technique for developing a model or mock-up of a proposed solution to elicit and validate requirements, not for investigating current tasks.

D. Activity sampling: This technique involves an analyst making observations at random intervals to determine statistically how time is distributed across different activities, not continuous self-logging by the user.

1. Paul

D.

& Cadle

J. (2020). Business Analysis (4th ed.). BCS

The Chartered Institute for IT. In Chapter 5

"Investigating the Business Situation

" the technique is described: "it may be appropriate to ask the business staff to keep a record of specific information for a period of time. This is often done using a specially designed form or diary sheet." (p. 101).

2. Kendall

K. E.

& Kendall

J. E. (2019). Systems Analysis and Design (10th ed.). Pearson. Chapter 4

"Information Gathering: Interactive Methods

" discusses the creation of tailored forms for data collection

which aligns with the principle of special purpose records for understanding business processes.

3. Hoffer

J. A.

Ramesh

V.

& Topi

H. (2016). Modern Systems Analysis and Design (8th ed.). Pearson. Chapter 4

"Identifying and Selecting Systems Development Projects

" discusses various information-gathering techniques. The direct observation techniques (like shadowing and activity sampling) are contrasted with methods that involve analyzing business documents

which would include user-created logs or special purpose records. (pp. 158-161).

The Boston Consulting Group (BCG) Matrix, also known as the Boston Box, is a strategic tool used for portfolio analysis. It classifies a company's business units into four categories based on their market growth rate and relative market share. The term "Dog" is used to describe a business unit that has a low relative market share in a market with a low growth rate. These units typically generate low profits or may incur losses, and they have limited potential for future growth. The standard strategic advice for "Dogs" is often to divest or liquidate them.

A. Cow: This refers to "Cash Cows," which have a high market share in a low-growth market, not a low share.

B. Cat: This term is not a standard category within the Boston Box (BCG Matrix) framework.

D. Goat: This term is not a standard category within the Boston Box (BCG Matrix) framework.

1. Kiechel

W. (2010). The Lords of Strategy: The Secret Intellectual History of the New Corporate World. Harvard Business Press. In Chapter 7

the book details the development of the BCG Matrix

explicitly defining "Dogs" as the quadrant for low-share

low-growth businesses.

2. University of Cambridge

Institute for Manufacturing (IfM). (n.d.). BCG growth-share matrix. In IfM Engage. Retrieved from https://www.ifm.eng.cam.ac.uk/research/dstools/bcg-growth-share-matrix/. The "Dogs" section explicitly states: "Dogs have a low market share in a mature

slow-growing industry."

3. Hedley

B. (1977). Strategy and the "Business Portfolio". Long Range Planning

10(1)

9-15. https://doi.org/10.1016/0024-6301(77)90003-6. On page 12

Figure 3 illustrates the matrix

labeling the low growth

low share quadrant as "Dogs."

In a UML use case diagram, an 'actor' represents a user or any external system that interacts with the system being modeled. In this scenario, the 'employee' is the user interacting with the system, making them the actor. A 'use case' describes a specific functionality or goal that an actor can accomplish using the system. The action 'enter time details' is the specific goal the employee wants to achieve. The 'computerised project reporting system' itself is represented by the system boundary, which is a box drawn around the use cases. Therefore, the employee is the actor and entering time details is the use case.

A. An employee is an actor, not the system boundary. Time details are data being entered, not an external entity (actor) interacting with the system.

B. The project reporting system is the system under analysis, not an actor. The employee is the actor performing an action, not the action (use case) itself.

C. The project reporting system defines the system boundary, it is not a use case. A use case is a function within the system.

1. Object Management Group (OMG). (2017). OMG Unified Modeling Language (OMG UML)

Version 2.5.1. OMG Document Number formal/2017-12-05.

Section 18.1.3

"Notation" (p. 639): Defines an Actor as "a user or any other system that interacts with the subject." It defines a UseCase as "a specification of behavior." This directly supports identifying the 'employee' as the actor and 'enter time details' as the use case.

Section 18.1.3 (p. 641): Shows the system boundary as a rectangle enclosing the use cases

separating the system from the external actors.

2. Dennis

A.

Wixom

B. H.

& Tegarden

D. (2015). Systems Analysis and Design: An Object-Oriented Approach with UML (5th ed.). Wiley.

Chapter 5

"Use-Case Modeling

" p. 136: "An actor is not a specific user but a role that a user can play... An actor is external to the system." This confirms the 'employee' is an actor.

Chapter 5

"Use-Case Modeling

" p. 138: "A use case is a formal way of representing how a business system interacts with its environment... It depicts a set of activities that the system performs to produce some output result." This confirms 'enter time details' is a use case.

3. Fowler

M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed.). Addison-Wesley.

Chapter 9

"Use Case Diagrams

" p. 101: "Actors are roles that people (or things) play... A use case is a summary of scenarios for a single task or goal." This clearly distinguishes the 'employee' (actor) from their goal

'enter time details' (use case).

The standard tool for stakeholder analysis is the Power/Interest Grid, also known as Mendelow's Matrix. This grid is a two-dimensional matrix used to classify stakeholders and determine the appropriate management strategy for them. The vertical axis typically represents the stakeholder's level of 'Power' or influence over the project, while the horizontal axis represents their level of 'Interest' in the project's success or outcome. By plotting stakeholders on this grid, a business analyst or project manager can prioritize engagement efforts, deciding whether to manage them closely, keep them satisfied, keep them informed, or simply monitor them.

A. Objectives and interests: Objectives are project goals, not a stakeholder attribute used for an axis on this specific grid, although interests are.

B. Power and influence: These terms are often used interchangeably; placing both on different axes would be redundant and not form the standard grid.

C. Perspectives and impacts: While important data points in stakeholder analysis, 'perspectives' and 'impacts' are not the standard axes for this classification tool.

1. International Institute of Business Analysis (IIBA). (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide)

Version 3. Section 3.2.4.2

"Stakeholder List

Map

or Personas

" describes various models for stakeholder mapping

with the Power/Interest grid being a primary example. It explicitly states the dimensions are power and interest.

2. Project Management Institute (PMI). (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide)

Sixth Edition. Section 13.1.2.3

"Data Analysis

" details stakeholder analysis techniques

including the power/interest grid

power/influence grid

or impact/influence grid

all of which use a combination of these core concepts. The most common is Power and Interest.

3. Johnson

G.

Whittington

R.

Scholes

K.

Angwin

D.

& Regnér

P. (2017). Exploring Strategy: Text and Cases (11th ed.). Pearson. Chapter 2

"Stakeholders and Governance

" pp. 45-48

provides a detailed explanation and illustration of the Power/Interest Matrix as a fundamental tool for stakeholder mapping.

The Business Activity Model (BAM), also known as a conceptual model in Soft Systems Methodology (SSM), is constructed directly from a system's root definition. The root definition is a concise statement of purpose structured using the CATWOE elements. The BAM specifically elaborates on the 'Transformation' (T) element of CATWOE. It defines the minimum set of necessary "doing activities" (represented by verbs) that must be undertaken to convert the system's inputs into its outputs, thereby achieving the transformation described in the root definition.

B. Actors: Actors are the individuals or groups who carry out the activities, whereas the BAM models the activities themselves, not who performs them.

C. Environment: The environment represents the external constraints and context within which the system operates, not the internal operational activities of the system.

D. Owner: The owner is the entity with the authority to start or stop the system, but they are not an activity within the system's transformation process.

1. Checkland

P. (2000). Soft Systems Methodology: A Thirty Year Retrospective. Systems Research and Behavioral Science

17(S1)

S11-S58. In Section 4

"The Established Form of SSM

" Checkland explains that the conceptual model (BAM) is a structured set of verbs representing the activities needed to bring about the transformation (T) described in the root definition. (DOI: https://doi.org/10.1002/1099-1743(200011)17:1+3.0.CO;2-O17:1+3.0.CO;2-O))

2. Williams

B. (2005). Soft Systems Methodology. The Kellogg Foundation

Battle Creek

Michigan. On page 11

under the section "Conceptual Model

" it is stated: "The conceptual model is a model of the activities that must be carried out to achieve the transformation described in the root definition." This document is widely used in university-level systems thinking courses.

3. Valero-Silva

N. (n.d.). An Introduction to Soft Systems Methodology. University of Twente

Faculty of Technology and Management. In Section 3.2

"Conceptual Modelling

" this courseware document states

"The conceptual model is built on the basis of the verb or verbs of the root definition

" directly linking the model's activities to the Transformation element.

A Business Activity Model (BAM), also known as a conceptual model, is a fundamental component of methodologies like the Soft Systems Methodology (SSM). It is not a generic model of all organizational processes. Instead, a BAM is constructed to represent the minimum, necessary set of activities required to fulfill the purpose of one specific business perspective or worldview. Each relevant perspective, often defined using a CATWOE analysis and a root definition, will have its own corresponding BAM. This allows analysts to explore and compare different viewpoints on what the system of interest should do before defining requirements or changes.

A. This describes a process model or flowchart. A BAM shows logical dependencies between activities, not necessarily their strict chronological sequence.

B. A BAM illustrates what activities are needed, not who performs them. Role assignment is typically handled by other models like RACI charts.

C. This statement is too broad. A BAM is a specific type of conceptual model, distinct from a detailed business process model which shows the workflow.

1. Checkland

P.

& Poulter

J. (2006). Learning for Action: A Short Definitive Account of Soft Systems Methodology and its use for Practitioners

Teachers and Students. John Wiley & Sons. In Chapter 3

"The Established Form of SSM

" it is explained that a conceptual model (BAM) is built from a root definition

which itself expresses a particular perspective (worldview) on the purposeful activity system.

2. Checkland

P. (1999). Systems Thinking

Systems Practice. John Wiley & Sons. In Part 2

Chapter 6

"The Soft Systems Methodology

" the process of building conceptual models from root definitions is detailed

emphasizing that each model is tied to a specific Weltanschauung (worldview or perspective).

3. The Open University. (2019). T847: Systems thinking in practice. Course materials. Block 3

Section 5.2

"Conceptual modelling

" states: "The purpose of the conceptual model is to represent the system named in the root definition... It is a model of the activities that must go on in order for the system to be the one described in the root definition." This directly links the model to a single

defined perspective.