The first is an article by Tony Marsten. He talks about what is needed to provide a quote. The first 2 points should be etched in all of our minds when we speak with someone who wants a custom system (and isnt that what modx is for).
http://www.tonymarston.net/aboutme/experiences.html
That article made me want to see how architecture firms work- since we are one =)
Good blog from AIA -
http://blog.aia.org/smallfirms/
And a quote from eHow on choosing an architect
- In most states, the law requires that the contract contain the payment schedule, the work schedule, the scope of the projects and the necessary materials.
#9 is really good.
9. The Requirements are best presented in the form of a Checklist
Before the customer accepts the completed system he will want to ensure that it actually meets his requirements. The best way to do this is by running through a checklist and ticking off the items one by one. Each of the items on the checklist should therefore be a simple statement that can be verified quite easily.
Each statement should contain a single goal or constraint. A "goal" is something that is to be achieved, or allowed, or is a valid situation. A "constraint" is something that is to be avoided, or disallowed, or is an invalid situation. This produces a list of Essential Business Rules (EBR) which may be long, but their simplicity should make it:-
- Easier for the customer to verify that the list is complete and accurate.
- Easier for the consultant to check that each item has been incorporated in the design.
There is a school of thought that argues that the SOR should initially be presented in the form of a structured list of Essential Business Rules rather than an unstructured document containing complex requirements. This has the advantage of not requiring the checklist to be produced in a separate exercise, and also ensuring that the checklist does not contain items that were not identified in the requirements. Software packages are being developed which will help produce this list by storing the rules in a database so that they can be sorted, analysed, verified, cross-referenced and reported.
The best way to get a good SOR is to write it with the customer, not let him present it to you, this is where your demo/rapid prototyping come into play, from there of course evolve this into the final product, with the customer involved at all stages. Agreed, not all customers will do this/have the time to do this, but I believe it should be encouraged, the end product is often much superior.
Use MODx, or the cat gets it!
