The friction and misunderstanding that is commonly experienced by many development projects is the translation between the business domain vocabulary of the business analyst, and with that of the technical vocabulary of the development team. This misunderstanding introduces unnecessary complexities, inhibits communication and leads to incorrect implementations.  Domain Driven Design (DDD) can help adopt a ubiquitous language for developing requirements and design.  Context Mapping is a DDD technique that helped our business analyst and solutions architect explore a given business domain model within a given bounded context.  This allowed us to develop language that translated into a better design and quality user stories. 

This hands-on, interactive session will cover our case-study and give participants tools to conduct their own Context Mapping meetings and create Context Diagrams.

Learning Objectives:

• What is Domain Driven Design and how can it help with requirements?
• How does the Business Analyst and Architecture Partnership work in Domain Driven Design?
• Where in the requirements process do you get the boost?
• What is Context Mapping and how to do it?
• When and how to discuss Business Process when Context Mapping