It's the awards season and we're looking forward to seeing what happens at the BAFTAs on Sunday. But in this post we're not talking about Mr. Firth or Miss. Portman, we're talking about use case actors as Alex continues with his interesting series on use cases...
Before building a new system it is essential to clearly define its boundary. This means understanding what sits within the systems, that we must develop, and what sits outside, that we must interface with.
Given any requirement specification, it is usually easier to identify what sits outside the system boundary and use that to determine how the system responds when it is stimulated from its environment, or how the system is going to be used.
When an event occurs, that causes an interaction between the system and its environment; entities within that environment are involved. Some of the entities initiate the event; others interact with the system as a result of the event. In use case modelling, these entities are known as actors.
An actor is an entity that interacts with the system for the purpose of achieving a goal or completing an event. Actors are not necessarily human users of the system; they can be other systems or even external forces that act upon the system (although the latter is unlikely to be a consideration when modelling software).
When looking for actors, review the following sources of information for potential actors of the system:
• Existing context diagrams and other models that describe the boundary of the system with its environment. Look for external entities that have interaction with the system
• Written specifications and other project documentation, such as records about meetings with users, these help identify users who may be potential actors
• Training guides and user manuals. These manuals are normally directed at roles representing users and therefore potential actors.
Each actor needs a descriptive name that indicates the role it plays and a brief description that is one or two sentences long.
The description should include:
• What the actor represents
• Information about the actor’s capability, functionality or skills
• Why the actor is needed
• What interest the actor has in the system
Many use case modellers forgo the description of actors and merely give them names which, in the case of systems, is often just the name of the system itself. Remember, when you document your use cases you will detail specific interactions with the actors and have little chance of getting it right if you don’t fully understand the actor to begin with.
Actors are a means of identifying and documenting the users of the system so that the users’ needs can be modelled, validated and implemented. The goal is to ensure that the system ultimately meet their needs.
No comments :
Post a Comment