A common piece of advice given to teams starting out to document requirements is “Find the actors and use cases”. Sounds like reasonably good advice, but how do we find the actors? Well, actors are stakeholders, a subclass of the stakeholder class if you will. Not every stakeholder will have direct interaction with the product but a stakeholder by definition has an interest of some kind in the outcome of the project. Actors are stakeholders so one way to find the actors is to identify and examine the stakeholders.

In fact, the importance of identifying stakeholders goes well beyond just finding actors. Stakeholders not only have an interest in the outcome of the project, and thereby provide “project requirements”, but they can also impact the product by providing business rules. Whether business rules are just requirements or something fundamentally different and whether they should be documented together or separately is a topic for another blog. Either way, it is critically important to identify and document the business rules, and therefore we must identify and examine the stakeholders, even the non-actor stakeholders.

Here’s an example: In the health care industry it is often important for systems to support the adherence to Medicare reimbursement rules. In most cases Medicare will not interact directly with the product. If we only identify actors who interact directly with the product, we may initially miss some important requirements (or rules).

So how do we find and identify the stakeholders? One common and useful technique is the ‘Onion Diagram’. This diagram is produced by first drawing a circle in the center of the page to represent the product. As an aside, the line around the product may be indistinct at the start of the requirements process and one of the goals of requirements analysis is to solidify the product boundary. A second circle is drawn around the product circle to identify “the system”. The product operates within the system and most of the directly interacting stakeholders (actors) will be found within the system circle. An additional circle is drawn to represent “the containing system”. Most, but not all, of the non-actor stakeholders will be found within this circle. Anything outside of the containing system is “the wider environment”. Identifying the stakeholders in the wider environment, such as government agencies, is often critical to the success of a project.

I personally find it easier to think of the containing system circle as “the organization” representing the legal entity which owns the system and is probably funding the development of the product. Not all systems are owned by legal entities but for products being developed by commercial enterprises the organization is probably a good boundary line to draw. The goal of course is not to draw a precise representation of systems but to identify stakeholders. The value of this diagram is that it provides a framework for thinking about where the stakeholders reside and what their interests are in the outcome of the project.

Like most tools of this nature, it is not necessary to follow a set of exact rules to gain the benefits. The diagram could be drawn with zero or many systems circles to represent the fact that the product is the system, or that there are systems within systems. There is also nothing wrong with starting with the outermost circle and working your way in to the product circle. What we are really drawing is a sort of extended context diagram. For those of us (like me) who are more comfortable with squares than circles the diagram can be drawn as a nested set of boxes. Other products within the system, and systems within the organization, can be drawn more easily this way, as in a more traditional system context diagram.

The important thing is to identify the stakeholders at each ‘layer’ of the onion. Document their interest in the project and their interaction, if any, with the product. The subset of stakeholders with direct interaction with the product should contain all of the actors. Some of the stakeholder groups may be at a higher level of abstraction than what is needed for use cases so look for subclasses within the groups.

See the references below for more information and some helpful templates.

References:

Scenario Plus: www.scenarioplus.org.uk
Volere: www.volere.co.uk