Most people join a new project the same way: they get access to the application, a pile of requirement documents and a sprint board, and they start testing screens. A few weeks later they can navigate every page and still can't explain why the business needs half of them. That gap is where missed requirements and escaped defects come from.
The fix is not more documents. It's asking the right questions in the right order. The BDC framework uses the same nine questions for every industry, so once you've learned one domain this way, the next one goes faster.
1. Domain — where are we?
Start with the industry itself: its segments, the main players and the regulators. A hospital, a diagnostics lab and a home-care agency are all "healthcare provider", but they run very differently. Knowing which one you're in changes everything that follows.
2. Business — how does it make money?
Every system exists to protect or grow revenue, cut cost or stay compliant. Find out which numbers leadership watches every week — margin and sell-through in retail, denial rate and days in A/R for a provider. A defect that moves one of those numbers is always a high-priority defect.
3. Process — how does the work flow?
Map the end-to-end process: the steps, the roles and the business rules at each step. In retail that's plan, buy, move, sell and serve. Write the rules down in plain language — "a return within 30 days is refunded to the original payment method" — because each rule is a test.
4. System — which applications run it?
List the core systems and, more importantly, what each one is responsible for and where it stops. The point of sale records a sale; the order management system decides where an online order ships from; the warehouse system picks and packs it. Most integration bugs live at those boundaries.
5. Data — what information matters?
Identify the master data (products, customers, patients, prices) and the transactional data (orders, claims, payments), the key fields, and how a record changes over its life. Test data that doesn't reflect real master data produces tests that pass in QA and fail in production.
6. Integration — how do systems talk?
Find every interface: files, APIs, message standards and events, with the direction and timing of each. Ask what happens when a message is late, duplicated or rejected. EDI with vendors, HL7 inside a hospital and payment gateway APIs all fail in their own particular ways.
7. Transaction — follow one, end to end
Take a single real transaction — one order, one patient visit, one claim — and trace it through every process, system and interface until the money lands. This one exercise ties the previous six layers together, and it's the fastest way to find the steps nobody owns.
8. Testing — how do we prove it works?
Now the test strategy writes itself: the high-risk scenarios, the test data you'll need and what to validate at each layer. Business rules become functional tests, interfaces become integration and reconciliation tests, and the numbers leadership watches tell you where to spend the most effort.
9. Real-world scenario — what happens on a live project?
Finally, study a production-style incident: what went wrong, how it was traced and which test would have caught it. Two promotions stacking on one item during a festive sale, or a lab result filed against the wrong patient, teach more about a domain than any glossary.
Using the nine questions
You don't need to answer them all before your first day. Ask the first three in week one, map the systems and data in week two, and trace a real transaction as soon as you can get access to one. Keep a one-page note for each layer and update it as you learn — it becomes the onboarding document your team never had.
Every Business Domain Connect track follows these nine layers in order, with Session 01 of every domain free to watch.