Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 43
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 comprehensiveness—that it integrates a number of often
disparate system engineering or enterprise architecture activities, including:
Requirements modeling
Specification trees
Traceability analysis
Interface specifications
Concept-of-operation analysis
Functional block diagrams
Logical or conceptual architecture