The first step of gathering requirements is to identify who can give you the requirements. Business processes include communication between different people inside the organization. Communication also includes people outside the organization. When gathering requirements, it can be easy to overlook the people who don’t use the software directly. Those people may still be stakeholders. Read on to see how to approach stakeholder analysis.
One of the things that differentiates Seilevel at requirements gathering is their application of different requirements models to solve specific elicitation problems. Joy recently posted an article about onion diagrams, a tool for visualizing the stakeholders of a system. At the accidental business analyst, Ryan provides a concrete example of using an onion diagram to visualize an insurance system.
Thanks Ryan and Joy for the great articles!
The Onion Diagram
The onion diagram is named because of the way it presents a view of a system (or product). It presents the layers of interaction with the system using concentric circles. The innermost circle is the system, and around that circle are the users of that system. Additional layers are added to describe the organization and its ecosystem.
This is a very simple diagram. In our example, BugBGone is developing software to manage their business. This diagram provides a visualization of the users of the system. It is sufficient for identifying the use cases of the system. However, we risk creating incomplete requirements, or overlooking business rules.
This larger view represents the organization as a whole (the next layer in the onion). The service technician is an important stakeholder of the system, even if he does not interact with it. This view provides a compelling way to visualize that there are people in the organization that get benefit from the system, even if they are not users.
The innermost circle represents the system, the next circle captures all of the users of the system. The outer circle captures all of the other employees within the organization who rely upon the system.
The Wider Environment
This larger diagram shows that there are stakeholders outside of the organization. In BugBGone’s case, there are several stakeholders outside of the organization:
- A regulatory agency provides MSDS (material safety data sheets) on the pesticides, and has compliance rules surrounding documentation and handling of substances.
- Suppliers need to receive orders for pesticides, invoice BugBGone, and receive payments for shipments.
- Customers need to schedule treatments, and receive and pay invoices.
- An accountant takes care of payroll, taxes, and other accounting needs for BugBGone (they’ve outsourced).
The diagram above shows the stakeholders. It is clean and easy to review. What makes this a powerful tool for a business analyst (or product manager) is that you can overlay the interactions between the stakeholders onto this diagram.
In this view, it is easy to visualize that there is reliance on the regulatory agency, and interactions between different stakeholders in the system. For example, it is easy to see how a service technician communicates with the administrator to get his schedules. The manager and the owner both interact with the accountant.
This view provides a great way to assure completeness of the requirements.
Analysis of a business, or software system is hard. It can appear to be easy, but the challenge is in discovering what you don’t realize you need to do. Different models provide different views of the company or system – making it easier to discover what needs to be done.
Communication is easy. Effective communication is hard. Models like the onion diagram allow for very targeted communication of often complex ideas.