Of course, with my method, you get to be a dictator for a couple of days, and that’s always fun! Once you’re done with it, you can put it into some electronic form, or use a real use-case modeling tool if you happen to like that sort of thing (which I don’t).

I’ve also seen my method resolve long-standing disputes between various departments, simply because by the end of it they’re all so pumped up and invested in the model that there’s no room for difference of opinion any more!

Your basic assumption is that the solution model and the domain model will mostly be very much alike – you can’t expect non-programmers to build up a model of notions they don’t know about. That’s only the case for a particular type of problems – mostly LOB apps, IME. Even there you usually have at least a small part in each app which has no relation to the domain model, and is strictly implementation specific. This part never emerges naturally if you just try to replicate the domain model.

My approach is a bit different – but also has limited applicability for non-LOB apps. Get all relevant stakeholders into the same room, and get each of them to describe the operations he wants to perform, in terms of the problem domain. Start building use cases as simple lists of steps, and start the people correlate all use cases, in order to discover discrepancies, gaps and other problems. Iteratively improve the use cases until you get a coherent description of the business process using domain language. This might take a while, and usually cannot be finished in just one long meeting. You may continue the process, once started, via shared documents on google docs, via email, via enterprise-internal collaboration systems, whatever. After this is done, you have what you need to develop the system without much additional input from the end users – you have the essential requirements in a coherent form. What you’ll build may not be the perfect system from the very first version, but since you definitely would have captured the essential aspects of the business process, even if changes will be required, they will be easily implementable – unless some of the involved people had held back on what they actually wanted the system to do, but that’s your job when gathering the requirements, to make sure this doesn’t happen. And your solution design and implementation can go ahead without the need of further involvement of non-programmers, which makes things go faster and leads to a better solution, IME.

This doesn’t contradict an iterative, agile approach to development, accompanied by frequent deliveries. It’s just a technique to gather requirements efficiently, so that you have all essential information early on. With agile methods or not, IME the most frequent cause of problems or right-out failure of software projects is bad requirements gathering, which cause significant rework later on, so that budget and deadline are significantly overrun. Getting the essential requirements right early on minimizes this risk, and is IMO the most important aspect of an entire project. You may build a sub-optimal application which does the right thing, and still have a happy customer, whereas even if you build a perfect application, your customer will be unhappy if it doesn’t do what it’s supposed to.