In this actor discovery process, two opposite concerns often emerge. To some it seems that the identification of the actors is a limited, even trivial concern and they resist doing this work. The obvious response to this is that if the activity is trivial, then go ahead and do it in a few minutes and be done with it. In reality of course, it is usually much more interesting work, takes more than a few minutes, and fosters interesting conversations about the system almost immediately.
The other concern often raised is that the number of actors is unlimited, and thus the task of identifying all of them is enormous. This usually results from a misunderstanding of the nature of actors and how they represent roles, not individual people or systems. For instance, a system might interact with hundreds of different employees across several divisions to collect time sheet information. There might be a tendency to think that an actor is needed for each employee, for each division’s employees, or perhaps for each type of employee (manager,
technician, engineer). In actuality, probably only one actor is needed. An actor like staff member might capture the role that all of these employees play with
respect to the system. So in identifying actors, the key question is not so much Who uses the system? but What roles are there interacting with the system?
Actors and the system boundary
In systems engineering, we pay a great deal of attention to system boundaries, interfaces and interface specifications. MDSD includes this kind of analysis explicitly. By identifying all of the entities with which a system interacts (actors) and all of the information and physical items (I/O entities) exchanged with the system, an MDSD model captures what is needed to specify system interfaces. As the model proceeds to develop deeper levels of decomposition, more detailed subsystem interface specifications can be captured in the same way. In a sense, you can produce such system interface specifications for free from an MDSD model. This is useful to note, since much work is often devoted to producing interface specifications as a separate activity, and this might be redundant effort when using MDSD.
In fact, system quality can be positively affected by the integration of such efforts into the overall MDSD modeling activity, instead of assigning them as separate efforts by separate teams, as is often done. Part of the effectiveness of MDSD comes from its
Requirements modeling
Specification trees
Traceability analysis
Interface specifications
Functional block diagrams
Logical or conceptual architecture
Chapter 3. | 43 |
