Business Rule Discovery Playbook

Stakeholders usually describe the happy path. That is reasonable: they are explaining what the business needs to accomplish, not attempting to enumerate every condition the software might encounter.

Engineering work begins when those boundaries are tested.

The goal is not to interrogate a requirement until everyone regrets scheduling the meeting. It is to make the consequential rules clear enough that the system can be designed safely.

The happy path is usually the requirement you were given. The rest is the requirement you still need to discover.

Start with the business outcome

Before expanding a requirement, establish the outcome it is meant to protect.

“An employee can register for an event” describes an action. The outcome might be accurate attendance planning, controlled eligibility, or a simpler employee experience. Those are different reasons to build the same-looking screen, and they lead to different decisions when exceptions appear.

Ask:

Who is trying to accomplish something?
What must be true when the workflow is complete?
What business problem appears if it does not work?
Which part of the outcome is essential, and which part is convenience?

The outcome becomes the reference point for later questions. Without it, boundary discussions become a tour of hypothetical edge cases with no way to decide which ones matter.

Find the happy path

Write the simplest successful sequence in business language.

For example:

An eligible employee selects an event.
The employee registers an allowed family member.
The system confirms the registration.

Do not start with services, tables, event streams, or identity claims. Technical nouns make an incomplete rule sound more settled than it is.

Once the happy path is visible, expand it deliberately.

Expand the Rule

For every important requirement, ask a compact set of questions:

Happy path: What normally happens?
Opposite: What should happen when the condition is not true?
Boundary: Where does eligibility or behavior change?
Ownership: Who can make or change the decision?
Time: What changes over time?
Cleanup: What expires, is retained, or must be removed?
Source of truth: Which system or person is authoritative?
Failure: What happens when required information or a dependency is unavailable?
Automation: What should the system do without human intervention?
Prohibition: What must never happen?

This is not a form to complete for every sentence in a backlog. Use it on rules that affect eligibility, money, permissions, state transitions, or operational recovery—the places where an assumption can become production behavior.

Clarify ownership and source of truth

Consider the requirement:

“Use SSO for employee information.”

It sounds like a technical direction, but it leaves several business and data-ownership questions unanswered:

Which employee attributes are available in the authentication context?
Which system is authoritative for persisted employee data?
Should any SSO attributes be stored by the application?
What belongs to the application rather than the identity provider or HR system of record?
What happens when two sources disagree?

SSO can establish identity and supply session context without becoming the owner of the employee record. Data being available does not mean the application should copy it.

Authentication context and application-owned data are not automatically the same thing.

For important fields, name an authority. “Whichever response arrived most recently” is not a source-of-truth strategy, although systems occasionally discover they have implemented it.

Ownership also applies to decisions. If an employee can be restricted from registering, who may apply that restriction? Who can change it? Can the system remove it automatically, or does that require an authorized person?

Clarify time and lifecycle

Time turns simple booleans into lifecycle rules.

Take this requirement:

“An employee can be blacklisted.”

The implementation could easily become an is_blacklisted flag. The business rule is not nearly as tidy.

Is the restriction global or limited to one event?
Who chooses its expiration?
Is the duration fixed or decided case by case?
Should eligibility return automatically?
What happens to existing registrations?
Is the history retained after the restriction ends?

When a rule includes time, do not assume either the duration or ownership of that duration. A phrase such as “blocked for 30 days” may describe a fixed policy, a default an administrator can change, or simply the first example someone remembered.

Prefer lifecycle language over a permanent flag:

Eligible ──restriction applied──> Restricted
   ▲                                  │
   └──── expiration reached ──────────┘

Now the design has an explicit transition, an owner, and an automatic recovery condition.

Clarify boundaries and opposites

A rule is easiest to misunderstand at the point where its result changes.

If a stakeholder says, “Users under 19 are not eligible,” clarify the boundary:

Does eligibility begin on the nineteenth birthday?
Which timezone determines the date?
Is age evaluated when applying, when approving, or when the activity occurs?

Do not ask every possible time question automatically. Ask the ones that could change the result for a real user.

The same habit applies to reverse and adjacent behavior. A stakeholder says:

“1 + 1 = 2.”

The engineer asks:

“Does 3 − 1 = 2 also need to work?”

The arithmetic is intentionally trivial. The point is to avoid mistaking the example for the rule. If the requirement describes adding something, ask about removing it. If it grants access, ask how access is revoked. If it creates a record, ask whether that record changes or ends.

A business rule is not complete until its boundaries are clear.

Reuse authoritative data

Now consider:

“Employees can register family members.”

The happy path suggests a form. Discovery asks whether the organization already knows the answer.

Which relationships qualify as dependents for this workflow?
Does an authoritative dependent record already exist?
Should an employee select existing people or enter them again?
What data must migrate from the legacy process?
Who may correct outdated information?

If trusted dependent data exists, forcing employees to recreate it adds work and creates a second, potentially conflicting copy. Migration and ownership may be harder than adding fields to a form, but the easy implementation is not automatically the better product.

Do not ask users to recreate information when an appropriate authoritative source already exists.

Clarify failure and recovery

Requirements often explain what success means and remain silent about temporary inability.

For a workflow that depends on employee eligibility data, ask:

Should the operation stop if the authoritative system is unavailable?
Can recently verified data be used safely?
Is the action retryable, or could retrying create duplicates?
What information does an operator need to recover the work?
Does recovery happen automatically, or does someone own it?

The answer should follow business risk. A profile page and a financial approval do not need the same behavior merely because both call an upstream service.

Failure questions are also lifecycle questions. What happens to work that began successfully but stopped halfway through? A design that accepts new requests after recovery while abandoning existing work has restored a service endpoint, not necessarily the business process.

Separate the rule from the implementation

Stakeholders own business knowledge. Engineers own the responsibility for turning it into a safe technical direction.

Do not ask, “Should we store this in our database or call the HR API every time?” before establishing freshness, authority, availability, and retention needs. The stakeholder should clarify what the business requires; the engineer should recommend how the system meets it.

A useful separation looks like this:

Business clarification

“When the restriction expires, should the employee become eligible automatically?”

Engineering recommendation

“We will store an expiration timestamp and evaluate eligibility from the rule, so restoration does not depend on a manual cleanup task.”

The first answer requires domain authority. The second requires technical judgment.

Do not ask stakeholders to design the technology. Ask them to clarify the business.

This does not mean engineering disappears until requirements are finished. Design exploration often reveals missing rules. The work moves back and forth. The ownership boundary still matters.

Know when to stop

Discovery is not a project to make every future question impossible.

Stop when:

The business outcome and primary actors are clear.
Important eligibility and permission boundaries are testable.
Decision owners and authoritative data sources are named.
Time-based rules have defined transitions.
Material failure behavior is understood.
Remaining uncertainty can be handled safely during solution design.

Some details are cheaper to learn from a prototype. Some depend on architecture constraints that are not yet known. Some edge cases are too unlikely or low-impact to justify delaying the core workflow.

The standard is not perfect requirements. It is enough clarity to make the next engineering decision responsibly.

Stop discovery when the core behavior is clear enough to design safely.

Meeting reference

Use this short version when a requirement carries meaningful business rules:

Area	Ask
Outcome	What must the user or business be able to accomplish?
Boundary	Exactly where does the result change? What is the opposite case?
Ownership	Who decides, changes, approves, or overrides the rule?
Time	When does it begin, change, expire, or get reevaluated?
Source of truth	Which person or system is authoritative?
Failure	What happens when required data or a dependency is unavailable?
Automation	What should happen without someone remembering to do it?
Cleanup	What is retained, reversed, migrated, or removed?

Finish by stating the rule back in observable terms. If the group can agree on what should happen at the boundary—not just in the example—you have probably discovered enough to begin designing.