| There are more modeling techniques for Column Two than for any other, but these techniques are actually related to each other. Clearly a given project will have to choose from among them. Table 4.3 compares them. The activity models clearly should be derived from the Row One scope document, which, among other things, will determine which functional areas are to be addressed in the first place. It is important at least to deliver from a requirements analysis project a model of the underlying functions of the business. A function hierarchy is the easiest form of this, but if the communications among the functions are important, an essential data flow diagram may also be used. If a Row Two diagram is to be made explicit, a process flow diagram, physical data flow diagram, or a UML activity diagram can be used. It is only in Row Two that you identify the actors who are (currently, at least) performing each function. In Row Three you could organize the flow diagram in terms of swim lanes , but these can refer only to general roles in the company. Indeed, identifying what those roles should be is a Column Four activity, so the final form of this should be defined in conjunction with that work. A Comparison of the Techniques Table 4.3 shows each of the techniques described in this chapter, along with the particular characteristics that make each unique. A check mark means that the technique completely embraces the characteristics described in the row heading. A blank box means that it has none of the characteristics described in the row heading. Table 4.3. A Comparison of Activity Modeling Techniques | | Function Hierarchy | Physical DFD | Essential DFD | Use Case/Object Model | IDEF0 | Business Process Model | UML Activity Diagram | | Physical/Essential | Essential | Physical | Essential | Unspecified | Essential | Physical | Unspecified | | Architecture Row | Two and Three | Two | Three | Two | Three | Two | Two, Three | | Data Stores | | Views | Entity Types | Typical Objects | | Views | Typical Objects | | Data Flows | |  | | Unlabeled interactions | | | Unlabeled interactions | | External Entities / Actors | | External Entities | External Entities | Actors | | Events | | | Swim Lanes | | | | | | | | | Material Flows | | Sarson and Gane only | Sarson and Gane only | | | | Material flows are not prohibited | | Control | | | | | | | | | Mechanisms | | | | | | | | | Rules for Decomposition | | | | | | | | As mentioned above, none of the techniques is ideal for all circumstances. One day, perhaps, there will be a CASE tool that will accommodate combining the techniques. In the meantime, we can only do the best we can with what we have. Regardless of the tool, it is important to understand that the purpose of activity modeling in the requirements analysis process is to first capture the business owners ' views of their functions and processes in terms that can be readily understood and confirmed. A further objective is to analyze the current physical state of the business to determine the underlying activities (functions) required to carry out the business of the enterprise. Only then are we in a position to recommend new physical tools and techniques for improving the business's operations. | 
