Conceptual modeling in systems analysis: the Five-Minute University class

Back in the day, the comic persona Father Guido Sarducci developed a series of skits he called "The Five-Minute University", which were hilarious more often than not, but often had some meat to them.

Writing an email this morning, which I may or may not end up sending, I wrote an outline of the conceptual modeling process in systems analysis, that on retrospect looked a lot like one of Fr. Sarducci's classes, albeit without the world class humor. I thought it would be worth sharing, if only to get comments that tell me what I'm missing here.

Without further ado, here's my 5-minute university class in conceptual modeling:

1. Assume we are starting with a narrative document the customer has written describing what the system is supposed to do. Such narratives are rife with tacit assumptions and misleading terminology. Our job is to weed these out and come up with something the customer agrees is right, and that will also make sense to the engineering team.
2. Look for nouns to identify object candidates. Some will likely be external actors.
3. Look for verbs that reveal relations between objects and system behaviors (of the internal objects or external actors).
4. Identify system outputs, and work backward from the outputs to the inputs to determine what processing is required and who (i.e. which object) is responsible for what processing. As you carry out this step,
   • You may realize you need additional objects for internal processing. Don't get too far down in the "weeds" here. 
   • Give all objects and behaviors names that the user will understand in functional terms, e.g., SecurityManager for an object responsible for authentication (aka "Log In") and authorization (aka "Check Permissions").
     • Avoid technical jargon like "Bean" and "Database" for now; these will appear in the design, when the target audience is the programmers.
     • Avoid the tendency to include objects and behaviors that are for internal bookkeeping and housekeeping, with no relevance to the end user, and possible unintended but ominous misinterpretations. A good example is "commit", which the user will associate either with a crime or a determination of mental incompetence.
5. Apply Occam's Razor to eliminate unnecessary objects, relationships, and behaviors.
6. Clarify the boundary between the system and external actors.
7. Review the model with the customer to find out if this represents what the system needs to do. If so, you have a good starting-point conceptual model of the system. If not:
   • If your model is close to the mark, iteratively refine the model until it is satisfactory to the customer. If this works, you are done.
   • If your model seems way off to the customer, or if your efforts in 6.1 seem to diverge rather than converge, go back to the original narrative and rewrite with the customer to get a clearer picture of what the customer wants the system to do.

If you read this far, you deserve a peanut, so here's one of Fr. Sarducci's skits: