Types of Models (and why they're not requriements)

I think a lot of the time when the analysis portion of a project goes astray the problem lies in people not knowing what they're modelling and why.

Knowing why we're modelling is hard. This is often the underlying reason people ask the question "How detailed should we be?". Modelling is generally on one of three levels:

Are you doing this to build consensus and set scope? Then go for an "Descriptive" model.

Are you doing this to define what will get delivered? Then for for an "Analytical" model.

* Descriptive: Like a Monet. Enough to evoke the feel of the thing you're modelling, but not enough to actually build it.
* Analytical: Like an architects drawings. Enough to give an unambiguous definition of what it will be.
* Executable: Like the actual object. When you define a work flow in a work flow systems - you're not modelling you're actually building.

Notice that this is completely different to types of requirements. User Requirements may be captured using models that are Descriptive, Analytical or even Executable depending on the project. They may not even be captured with models.

There's a difference between capturing requirements and modelling a solution. Though these is a rough correlation between user requirements and the Descriptive view and functional requirements and the Analytical view.

(The three levels of modelling are taken from a Bruce Silver blog post about process modelling that's fairly widely referenced: http://www.brsilver.com/wordpress/subscribers-only-2/three-levels-of-process-modeling-with-bpmn/)