CCBA Business Rules Analysis 1 — Questions and Answers
Question 1: What is a 'business rule' in the context of business analysis?
- A technical constraint imposed by the software development framework
- A specific directive that defines or constrains some aspect of the business, governing behavior, action, or decision (Correct answer)
- A project management guideline for the BA team
- A regulatory requirement imposed by a government authority
Correct answer: A specific directive that defines or constrains some aspect of the business, governing behavior, action, or decision
A business rule is a specific, actionable statement that defines or constrains business conduct — it governs how decisions are made, actions are taken, or conditions are evaluated within the business.
Business rules are statements that define or constrain business behavior, decision-making, or data conditions. They represent organizational policy, regulatory requirements, or operational constraints that the solution must enforce. Examples include: 'A customer must be at least 18 years old to open an account' (constraint), 'Orders over $1,000 require manager approval' (decision), 'Loyalty points expire after 12 months of inactivity' (temporal rule).
Question 2: What distinguishes a 'business rule' from a 'business process'?
- Business rules are documented; business processes are not
- A business rule states a constraint or directive; a business process describes the sequence of activities to accomplish a goal (Correct answer)
- Business processes apply to customers; business rules apply to employees only
- Business rules are enforced by IT systems; business processes are manual
Correct answer: A business rule states a constraint or directive; a business process describes the sequence of activities to accomplish a goal
A business rule is a declarative statement of constraint or policy ('must', 'shall', 'cannot'), while a business process describes the procedural steps and flow of activities to accomplish a business objective.
Business rules and business processes are related but distinct concepts. A business process describes how work flows — the sequence of activities, decisions, and actors involved in accomplishing a business objective. A business rule constrains how that process behaves — it specifies conditions, restrictions, or computations that must be applied at specific points in the process. Rules govern processes, not the other way around.
Question 3: Which of the following is an example of a 'definitional rule' (also called a term rule)?
- All loans must be approved by a credit officer before disbursement
- 'Preferred customer' is defined as a customer who has placed more than 10 orders in the past 12 months (Correct answer)
- Orders cannot be modified after they have been shipped
- Invoices overdue by 30 days must trigger an automated reminder
Correct answer: 'Preferred customer' is defined as a customer who has placed more than 10 orders in the past 12 months
A definitional rule establishes the meaning of a business concept or term — in this case, defining what qualifies a customer as 'preferred' through specific measurable criteria.
Definitional rules (or 'term rules') define the meaning of business concepts in precise, operational terms. They establish a shared vocabulary by specifying exactly what qualifies something as a particular category or classification. In contrast, behavioral rules (constraints and action enablers) specify what must, should, or should not happen under certain conditions. Definitional rules are foundational because other rules often reference the defined terms.
Question 4: Why is it important for business rules to be stated declaratively rather than procedurally?
- Declarative rules are easier for developers to code
- Declarative rules separate the 'what' from the 'how', enabling implementation flexibility and making rules easier to maintain (Correct answer)
- Procedural rules cannot be documented in requirements
- Declarative rules automatically generate test cases
Correct answer: Declarative rules separate the 'what' from the 'how', enabling implementation flexibility and making rules easier to maintain
Declarative business rules state what must be true or what is permitted without specifying how to implement it, separating business logic from implementation and making rules easier to change independently.
Stating business rules declaratively ('A loan applicant must have a credit score above 650') separates the rule from its implementation. This means: the rule can be implemented in different ways by different systems, changes to the rule don't require changing process logic, non-technical stakeholders can understand and validate rules without needing to understand code, and rules can be managed in a business rules management system independently of applications.
Question 5: What is a 'decision table' used for in business rules analysis?
- Scheduling business analysis activities in a tabular format
- Documenting complex conditional logic by mapping combinations of conditions to corresponding actions (Correct answer)
- Mapping requirements to the business analysts responsible for them
- Recording decisions made during stakeholder meetings
Correct answer: Documenting complex conditional logic by mapping combinations of conditions to corresponding actions
A decision table maps all meaningful combinations of relevant conditions to their corresponding business actions or outcomes, providing a comprehensive, structured view of complex conditional logic.
Decision tables document complex business rules involving multiple conditions and multiple actions. Each column represents a combination of condition values, and each row represents either a condition or a resulting action. Decision tables are particularly valuable when multiple conditions interact to determine outcomes — they ensure that all combinations are documented and help identify any missing or contradictory rules.
Question 6: Which source is MOST likely to reveal undocumented business rules in a legacy system migration?
- The organization's published policy documents
- Subject matter experts who have operated the current system for years (Correct answer)
- Industry benchmarking reports
- The project charter and scope statement
Correct answer: Subject matter experts who have operated the current system for years
Long-tenured subject matter experts carry tacit knowledge of how the current system actually works — including the undocumented rules embedded in code, workarounds, and operational practice over time.
In legacy system migrations, formal documentation is often incomplete, outdated, or missing entirely. The richest source of undocumented business rules is typically long-tenured subject matter experts who have worked with the system for years. They carry tacit knowledge of: rules that were coded but never documented, exceptions that have been handled manually, interpretations of policy that were applied in practice, and workarounds for known system limitations.
What is a 'business rule' in the context of business analysis?