Business rules

Logic and processes that govern product behavior

Assessment

Logic, validations, and conditions that define system behavior — with clear trigger and interruption points.

Example

“If the customer is a legal entity and the order exceeds BRL 50,000, apply a 10% discount.”

Interface elements

Visual and interactive components that users interact with

Assessment

User touchpoints that represent business concepts: fields, buttons, tables, and forms.

Example

Order approval screen with filters, an item table, and a confirmation button.

Boundaries

Integrations with external systems and context boundaries

Assessment

Exchange of information with external systems: APIs, third-party services, files, and external databases.

Example

Query an external credit service to validate the customer’s credit limit.

Roles and permissions

Depth of the roles and permissions structure: how many differentiation axes must be combined to determine who can do what.

Assessment

Every functional story scores in this dimension. The score increases when the story describes explicit access restrictions using more than one combined criterion.

Example

“Only senior compliance reviewers can approve high-risk transactions” → two axes: seniority and department.

Solution variations

Different paths within a business rule that converge on the same outcome. Looking only at the result, it is not possible to tell which path was taken.

Assessment

Not included in this dimension: Screen filters belong to Interface elements; profile-based access restrictions belong to Roles and permissions.

Example

Payment via PIX, credit card, or bank slip: different flows, but all end with “payment processed.”

Domain entities

Distinct business objects involved in the story: entities with their own attributes, states, and relationships.

Assessment

Only concepts that the business recognizes by name and that have a life of their own within the domain.

Not included in this dimension: Entity attributes, such as status or email fields, and technical terms, such as queue, cache, or endpoint.

Example

Adding to cart: Product, Customer, Cart, and CartItem — four entities.

New domain entities

Changes introduced to the data model: entities that appear for the first time or existing entities that receive new attributes or relationships.

Assessment

Not included in this dimension: CRUD operations on an existing entity without a model change do not score.

Example

Implementing order management for the first time: Order is new; Customer and Product gain a new relationship with Order.

Background processes

Processes that run outside the user’s main flow: asynchronous, scheduled, or event-driven.

Assessment

The score is determined by the trigger mechanism, não pelo tamanho do processamento.

Not included in this dimension: Synchronous operations in which the user waits for the result within the same interaction.

Example

“Send an email after sign-up” → event-driven.
“Daily report generated at midnight” → scheduled.

Notifications

Types of business events that trigger messages to people.

Assessment

The delivery channel (email, SMS, push) does not multiply the count: the event is what counts.

Not included in this dimension: Callbacks and webhooks between systems. Mentioning “notify” without specifying the event or channel does not score either.

Example

“SMS + email when an order is approved” → 1 event (approval), two channels. Score = 1.

Audit trails

Business entities that require an audit trail: a record of who did what and when, for compliance or accountability.

Assessment

It must provide business traceability by answering “who did what and when” to support an audit.

Not included in this dimension: Technical logs created to facilitate software debugging.

Example

“Record changes to contracts: what was changed, when, and by whom” → 1 audited entity (Contract).