Module 19 — Requirements Gathering for Mule/Salesforce Integrations
About this book
Absolutely. I would add these as Module 19 — Requirements Engineering for Integrations and Module 20 — AI-Assisted Integration Engineering.
The first one is especially important because a field-mapping spreadsheet alone is not enough. It tells you where data goes, but not necessarily what it means, when it should move, which system wins conflicts, what null means, or what should happen when the workflow partially fails.
MuleSoft itself recommends defining the API contract and understanding purpose, data flows, and security requirements before implementation.
19.1Start with the mapping spreadsheet — but make it richerYes, I would absolutely expect some sort of mapping document.19.2The biggest question is not “what maps to what?”It's:19.3Ask Product about scenarios, not implementationAvoid asking a Product Manager:19.4The form of questions I recommendAsk requirements as:19.5Source-of-truth matrixFor important fields, create another small table:19.6Ask “who wins?”Suppose:19.7Null semantics deserve their own meetingAsk explicitly:19.8Ask about lifecycle, not only CreateMost requirements initially describe:19.9“Delete” is especially dangerousSource says:19.10Ask about identity very earlyThis is one of the first things I'd ask:19.11Ask about duplicatesBusiness question:19.12Ask about relationshipsFor:19.13Ask about orderingExample:19.14Ask about timingNot:19.15Ask about volumeAsk business/operations:19.16Ask what “success” meansConsider Account + Contacts.19.17Ask what happens when Salesforce is unavailableDon't ask Product:19.18Ask about permanent failuresExample:19.19Ask about replay“After somebody corrects bad source data, how should the failed customer be resubmitted?”19.20Ask about auditabilityQuestions:19.21Ask about manually edited Salesforce fieldsCritical question:19.22Ask about derived fieldsSome Salesforce fields may not map directly.19.23Add a “business rule ID”This is where I would improve the mapping spreadsheet.19.24My preferred requirements packageI would maintain five lightweight artifacts, not a giant 80-page specification:19.25Context diagramSomething as simple as:19.26Then write scenariosI prefer Given / When / Then because business people can review them.19.27Ask Product to approve examplesOne of the best tricks:19.28Requirements workshop agendaFor a 45–60 minute session I'd structure it roughly as:19.29The questions I would actually ask the Product ManagerKeep these handy:•cheat sheetModule 19 Cheat SheetThe sentence I'd use in an interview: