Interview is an informal, yet very important step. Its goal is to help organize your approach to the project. Here you should define the scope of the project, its effect, its result and structure and also find the main players (like "accountant", "invoice", etc.) and actions (like "processing invoices") that are crucial for your model. To capture this information, you create so called "sketch" diagrams. The tool supports you in checking if all interview items are covered during the other steps of the method.

Based on the interview, you should discover or define all important subjects (later called "players" or "participants") and their core behaviour, so that you have a comprehensive view of the modelled problem. You should also discover or define all of the important pieces of each behaviour; these are called "scenarios". The main idea of doing this is to break the entire complex system into pieces of manageable size, so that all of them can be given the proper attention. If you think about the entire system as a theatre performance, you need to find the individual "scenes" of the play.

You can also work on a different structure, like having a goal (function), several objectives (scenarios), and ways of achieve them (states or activities).

So far, you have the model in a form of several objects bearing only structured text in your native language. No diagram (except for interview sketch diagrams) has yet been created. You can still easily change your mind and restructure your model at once, without having to care about whether your diagrams will look nice. So you now have a bunch of text-described scenarios and a few dozen players. Now we would like Craft.CASE to make sure we haven't made any major mistakes. Craft.CASE does not understand your written text, but you can approximate its meaning to Craft.CASE by defining "roles". The role describes a relationship between a participant and a scenario. This allows Craft.CASE to help you test the model at a high level, before drawing a single diagram.

To do as previously stated, Craft.CASE generates a set of cross-reference tables, which describe the lifecycle of each participant in each scenario and allows you to crosscheck. The C.C method tells you how to test the model in this way.

Only after you have tested your roles, are you ready to create diagrams. This is because Craft.CASE’s Business Diagram does not show individual processes, but instead a set of all possible processes that can take place for a given scenario. In comparison to old-fashioned  - and today rather obsolete - flowchart diagrams, Craft.CASE’s Business Diagram has a separate storyline for each participant. This fact fully represents reality – in reality, we have our daily "lifecycle" and our course of action is affected by the course of action taken by our "collaborators". Preceding testing of the roles in all scenarios assures that you follow reality precisely in this step.

A very useful and very important rule of this method is that each participant can change one state to another while executing an activity. This reflects life systems, where things and people are going through states of their lives, e.g activated, idle, sleeping, active, etc. An example of the Business Diagram is bellow:

It is necessary to ensure our model is valid. Craft.CASE provides an embedded simulator that allows you to step through the Business Diagram and see what happens at each step. Our experience tells us that business customers - including management - natively understand and like simulation, and are therefore valid partners in testing the model.