Software project? Identify your actors and their goals.
The indispensable first step to getting the things you want out of life: decide what you want.
The software industry is littered with failed projects, that did not deliver what people really needed. If you do not want your project to fail and you do want to deliver what your people really need, you should identify your people—better said: actors—and their goals in an early stage of your project.
In the last nine months I have contributed to three different software projects, where we identified and organised the primary actors and their goals in an early stage of the project. For me, at first sight, it was not obvious how to identify and organise primary actors and their goals. Now, three successful projects further, I want to share my best practise regarding identifying and organising primary actors and their goals in this blogpost.
Stipulative definition: actor
I will use the following—informal—definition of actor: something with behaviour, can be a person, organisation, computer system etcetera.
Time to start taking your actors and their goals seriously
If you have decided that you will definitely start your project, and you have decided what the system boundary is, it is time for you to think about the actors of your application and their goals. You should start with identifying the primary actors, and then identify their goals.
Identify the primary actors
Primary actors are those that have goals fulfilled through using services of the system.
To identify primary actors, you should know the context of the environment where the application will be used. It is not a bad idea to brainstorm about who your primary actors are.
There are some obvious primary actors and there some not so obvious primary actors. Larman (2005) provides the following questions that help to identify primary actors that may be missed:
Who starts and stops the system?
Who does user and security management?
Who does system administration?
Is "time" an actor because the system does something in response to a time event?
Is there a monitoring process that restarts the system if it fails?
How are software updates handled? Push or pull update?
In addition to human primary actors, are there any external software or robotic systems that call upon of the system?
Who evaluates system activity or performance?
Who evaluates logs? Are they remotely retrieved?
Who gets notified when there are errors or failures?
Let us summarise the requirements for a primary actor; it is required that each primary actor:
- will be a direct users of the final application;
- have one or more goals that will be fulfilled with the application.
Once you have identified your primary actors, you start identifying their goals.
Identify the goals of your primary actors
Goals of primary actors must be goals that will be fulfilled through using services of the system. Goals should not be too small—too precise—and not too big—too vague. There are two good guidelines to prevent too small and/or too big goals:
- Goals should be completed between five minutes and one hour;
- Ask yourself "How satisfied will your employer be?", if the answers is negative, the goals is too small.
An Elementary Business Process (EBP) is a good goal. Larman (2005) defines EBP as:
A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state (...)
Now you have identified your primary actors and their goals, you should organise them.
Organise your actors and their goals
There are several approaches to organise them. You can draw them in an use case diagram. My preferred approach is to write an actor-goal list. An actor-goal list is a—simple—table with two columns:
In the end
Identifying and organising actors and goals in a software project can not be done perfectly. Furthermore, people have different views about the best practise regarding organising actors and goals. In the end, the most important thing—in my opinion—is that you are aware of the decisions you have made regarding your software project and the final application. Keep in mind that your goal is to deliver something that people really need.
Larman, C. (2005). Applying UML and patterns: an introduction to object-oriented analysis and design and the unified proces (3th ed.) (pp. 61, 63, 82-85). Upper Saddle River (New Jersey): Pearson Education, Inc.