dslbook.org
...
There is a much better approach, though. Since today’s language workbenches support extremely rapid prototyping, you can actually build the DSLs interactively with the requirements owner. Since you are not capturing the specific requirements, but rather try to define how specific requirements are described, you essentially perform a domain analysis: you try to understand the degrees of freedom in the domain to be able
to represent the domain with the DSL19. Here is the process I have use successfully many times:
This is similar to what has been done with "analysis models" (back in the day . . . ). However, instead of drawing UML analysis diagrams, you capture the domain into a language definition, which makes it executable, in the sense that you can always turn around and have the requirements owner try to express specific requirements with the DSL you’re building, verifying the suitability of the DSL.
1. Have the requirements owner explain some particular aspect of the domain.
2. Try to understand that aspect and change your DSL so it can express that aspect.
3. Make the requirements owner try to express a couple of specific, but representative, requirements with the DSL
.
4. Most likely you will run into problems, some things cannot be expressed with the DSL. If so, go back to 1 and reiterate. A complete iteration should take no more than 60 minutes.
5. After half a day, stop working with the requirements owner and clean up/refactor the DSL.
6. Start another of the language design sessions with the requirements owner and iterate – over time, you should get closer to the DSL for the domain.
