Now that we've specified the external requirements, we begin mapping our system-to-be by sketching out its internal structure, gradually involving more IT personnel. Involvement of the stakeholders depends on the nature of the system. If the system is to be highly interactive, then much of the hard work has already been done during specifying and defining the use cases. If the system-to-be is more complex than interactive, such as a knowledge base, then you might have to do much more work at this stage, for example, detailing the rules that affect each part of the solution.

We're also dependent on the skills of our IT personnel. Throughout the project, experienced people familiar with both object methodology and conceptual thinking will ask many of the important questions early in the specification stage, whereas new converts will appreciate more input from other stakeholders, including help with first-cut key diagrams.

Because structure issues are key with most enterprise systems, we provide boxes on some advanced constructs, as well as extensive footnotes on details and semi-technical issues. We point out why some peripheral, or seemingly peripheral, questions often emerge during modeling.

Some methodologies encourage a two-step process on defining classes: first, model the business classes (the first cut), and then develop a complete class model. In a lightweight approach, we can view these as two levels of detail, which then gives an indication of the involvement of relevant business expertise.