- Developers prefer writing code, than understanding the domain
- Business users/stakeholders want to see *results*
- Creating and delivering flexible prototypes takes too long

We have a product that attempts to tear down these obstacles, and:

- Allows developers to rapidly create prototypes using code
- Allows business users/domain experts to interact with the prototypes
- Allows all parties to understand and share the domain

The product is called “TrueView”, and I believe it tackles a very important part of the software design process.
You can learn more about it at http://www.evolving-software.co.uk.

Cheers,
Vijay

We have arrived at a lightweight process quite similar to what you describe, in that we use our domain understanding to do a high level design based on the customer’s description, from which we can make time & cost estimates and write up a draft specification. In effect we say to the customer “You asked for X, and we will give you Y (similar to X) in N weeks at cost C”.

From this we gain two significant advantages:
1. We have a good idea of how we will approach the project before we commit to costs & times. You cannot do this if you start from a requirements spec.
2. The specification was written by us and subject to our interpretation – we offer to implement the system that we have described in vague terms, as opposed to the one that the customer described in vague terms. This results in much better control of project scope, changes, and contractual disagreements.

Taking all of this into account I would practice your process as something more like:

1. Understand the domain
2. Understand the customer’s problem and needs
3. Draft of the high level design (major functionality, user interface sequences for the functionality, software components required to support the functionality, infrastructure components)
4. Identify risky areas (functionality, approaches or technology your team hasn’t handled before) and make prototypes to reduce the risk.
5. Estimate times & costs. Don’t forget documentation, testing, customer acceptance demonstrations, etc.
6. Write a specification based on the high level design. This is probably best called a “functional” or “behavioral” specification.
7. Get the signed contract (don’t underestimate the importance of this step!)
8. Low level design, code, test, document.
9. Iterate as needed

Regards,
Twylite

Everything is so contextual and just because you failed elicitation or didn’t even try any planning doesn’t mean they don’t work for everyone. Even worse don’t pretend your little process works for everyone and everything, that was your fatal flaw and assumption to begin with.

Engineering is meant to involve critical rational thought. Not just blind dogma which you seem to espouse.

Everything is so contextual and just because you failed elicitation or didn’t even try any planning doesn’t mean they don’t work for everyone. Even worse don’t pretend your little process works for everyone and everything, that was your fatal flaw and assumption to begin with.

Engineering is meant to involve critical rational thought. Not just blind dogma which you seem to espouse.