Identifying Actors and Determining Their Roles

We must create an actor for every different role that will be assumed by various categories of user relative to the system. To identify such roles, we typically turn first to the narrative requirements specification, if one exists: that is, a statement of the functional requirements, such as the Student Registration System specification. The only category of user explicitly mentioned by that specification is a student user. So, we would definitely consider Student to be one of the actor types for the SRS.

If we think beyond the specification, however, it isn't difficult to come up with other potential categories of user who might also benefit from using the SRS:

• Faculty may wish to get a headcount of how many students are registered for one of the upcoming classes that they are going to be teaching, or may use the system to post final grades, which in turn are reflected by a student's transcript.

• Department chairs may wish to see how popular various courses are or, conversely, whether or not a course ought to be cancelled due to lack of interest on the part of the student body.

• Personnel in the Registrar's Office may wish to use the SRS to verify that a particular student is projected to have met the requirements to graduate in a given semester.

• Alumni may wish to use the SRS to request copies of their transcripts.

• Prospective students—i.e., those who are thinking about applying for admission but who haven't yet done so—may wish to browse the courses that are going to be offered in an upcoming semester to help them determine whether or not the university has a curriculum that meets their interests.

and so on. Similarly, since we said that other computer systems can be actors, we might have to build interfaces between the SRS and other existing automated systems at the university, such as

• The Billing System, so that students can be billed accurately based on their current course load

• The Classroom Scheduling System, to ensure that classes to be taught are assigned to rooms of adequate capacity based on the student headcount

• The Admissions System, so that the SRS can be notified when a new student has been admitted and is eligible to register for courses

Of course, we have to make a decision early on as to what the scope of the system we're going to build should be, to avoid "requirements inflation" or "scope creep." To try and accommodate all of the actors hypothesized earlier would result in a massive undertaking that may simply be too costly for the sponsors of the system. For example, does it make sense to provide for potential students to use the SRS to preview what the university offers in the way of courses, or is there a different system—say, an online course catalog of some sort—that is better suited to this purpose? Through in-depth interviews with all of the intended user groups, the scope of the system can be appropriately bounded, and some of the actors that we conceived of may be eliminated as a result.

In our particular case, we'll assume that the sponsors of the SRS have decided that we needn't accommodate the needs of alumni or prospective students in building the system; that is, that we needn't recognize alumni or prospective students as actors. A key point here is that the sponsors decide such things, not the programmers! One responsibility of a software engineer is indeed to identify requirements, and certainly part of that responsibility may include suggesting functional enhancements that the software engineer feels will be of benefit to the user. But, the sponsors of the system rightfully have the final say in what actually gets built.

Note?/td>

Many software engineers get into trouble because they assume that they "know better" than their clients as to what the users really need.You may indeed have a brilliant idea to suggest, but think of it simply as that—a suggestion—and consider your task as one of either convincing the sponsors/ users of its merit, or of graciously accepting their decision to decline your suggestion.

Note that the same user may interact with the system on different occasions in different roles. That is, a professor who chairs a department may assume the role of a Department Chair actor when he or she is trying to determine whether or not a course should be cancelled. Alternatively, the same professor may assume the role of a Faculty user when he or she wishes to query the SRS for the student headcount for a particular course that he or she is teaching.

Diagramming a System and Its Actors

Once we've settled on the actors for our system, we may wish to optionally diagram them. UML notation calls for representing all actors—whether a human user or a computer system—as stick figures, and then connecting these via straight lines to a rectangle representing the system as you see in Figure 9-1.

This figure appears rather simplistic, and yet, this is a legitimate diagram that might be produced for a project such as the SRS development effort.

We prefer to use a slightly modified version of the UML notation, as follows:

• We've extended the use of a rectangle to represent not only the core system but also all actors that are external systems, rather than representing the latter as human stick figures.

• We find that using arrowheads to reflect a directional flow of information—i.e., whether an actor provides or consumes information—is a bit more communicative. For example, in our amended version of the notation as follows, we represent a student as both providing and consuming information, whereas a registrar only consumes information.

Note?/td>

Note that the registrar does indeed provide information, but not to the SRS directly. He or she provides information to the Admissions System as to which students are registered at the university; this information then gets fed into the SRS by the Admissions System. So, the Admissions System is shown as providing information as an actor to the SRS; but, from the standpoint of the SRS, the registrar is but a consumer.

With these slight changes in notation, as reflected in Figure 9-2, the UML diagram becomes a much more communicative instrument.

Of course, if you do decide to deviate from a widely understood notational standard such as UML, you'll need to follow these steps:

1. Reach consensus among your fellow software developers, to ensure that the team as a whole is speaking the same language.

2. Document and communicate such deviations (along with the notation as a whole) to your customers/users, so that they, too, understand your particular "dialect."

3. Make sure that such documentation is incorporated into the full documentation set for the project, so that future reviewers of the documentation will immediately understand your notational "embellishments."

If you make these enhancements intuitive enough, however, they may just speak for themselves!

Of course, as we pointed out in Chapter 8, you'll also need to consider whether the CASE tool you're using, if any, will support such alterations.

Time and again throughout Part Two of this book, we'll remind you that it's perfectly acceptable to adapt or extend any process, notation, or tool that you care to adopt to best suit your company's or project's purposes; none of these methodology components is "sacred."