From business problem to screen: how we turn a requirement into a solution

When a manager tells us “I need better control over credit”, they’re not asking for a screen. They’re describing a business problem: customers who don’t pay, shipments going out without backing, a growing receivables book. Our job is to turn that problem into something the system can do, verify and measure.

The four layers

1. Business requirement (the “why”). The goal, in the company’s language. “Reduce overdue receivables without slowing down sales.”
2. Business rules (the “what is decided”). The policies the company sets. “We don’t ship to a customer who exceeds their credit limit, unless Credit authorizes it.”
3. Functional requirements (the “what the system does”). Concrete, verifiable behaviors. “When a credit order is confirmed, the system calculates the customer’s exposure and, if it exceeds the limit, puts the order on hold.”
4. Acceptance criteria (the “how we know it works”). Test cases written before any code.

Skipping a layer is the most common reason projects “work” but don’t solve anything.

How we do it

• We listen to the problem, not the solution. If a user asks for “a button to block customers”, we ask why. There’s almost always a more general rule behind it.
• We write the rule with the company. The business decides the rules. We make them explicit, with their exceptions and who approves them.
• We break it down into functional requirements with examples. Each functional requirement comes with concrete examples using real numbers.
• We define acceptance before coding. With test-driven development, every rule has its automated test from the start.
• We validate with the key user during the sprint. Not at the end of the project: in every two- to four-week delivery.
• We measure. The business requirement had a goal; after go-live we review the KPI.

Case 1: a wholesaler selling on credit without control

Business problem. Sales reps took credit orders without knowing how much the customer owed; overdue receivables kept growing and Credit found out too late.

Business rules.

• Each customer has a credit limit.
• Exposure is what the customer already owes plus the order being confirmed.
• If exposure exceeds the limit, the order is put on hold; only someone with permission can release it.
• Customer advance payments are applied when the order is invoiced.

Functional requirements.

• When a credit order is confirmed, calculate the exposure and compare it with the limit.
• If it exceeds the limit, mark the order as on hold and notify Credit.
• An order on hold cannot be shipped or invoiced.
• When invoicing, automatically apply the customer’s advance payment.

Acceptance criterion (example). Given a customer with a Bs 50,000 limit and Bs 42,000 of debt, when the sales rep confirms a Bs 12,000 order, then the order is put on hold, Credit receives the notification and the ship button is locked.

Case 2: an importer that didn’t know its real cost

Business problem. The selling price was calculated on the supplier’s invoice value, without freight, insurance, customs or local expenses. Some products were being sold at a loss without anyone noticing.

Business rules.

• The cost of an imported product includes all import expenses.
• Each expense is allocated across products using a defined basis: value, weight, volume or quantity.
• The final cost is known when the import file is closed.

Functional requirements.

• An import file groups the supplier invoices and all related expenses.
• Each expense chooses its allocation basis.
• On settlement, the system calculates each product’s final unit cost and updates the inventory cost.
• Based on the final cost, a selling price is suggested according to the target margin.

Acceptance criterion (example). Given a shipment with two products of equal value and different weight, when freight is allocated by weight, then the heavier product absorbs more freight and its unit cost reflects it.

Why it matters

A requirement that’s properly broken down into functional terms can be tested, maintained and measured. One that isn’t ends up as customizations nobody understands a year later.

Both cases in this article ended up as MKA flows; you can walk through the first one in the orders and shipments demo.