The Business Analysts I have known are very sharp people. I always assumed they had their own favorite questions to ask and moreover had favorite elicitation techniques they used to ferret out the remaining information they needed. Even if they did not, the BABOK has many techniques for elicitation and even includes a few typical questions. But the perfect list? For all situations?
Instead of the perfect list, how about a relevant list? How could that be created? Well we have said for many years that the value diagrams / models (whether BPMN, UML, SysML, IDEF, whatever) provide is mainly communication. But in practice, the use of modeling often morphs into diagrams being created as merely documentation. Then those diagrams are given to others. Voila - communication! No, not really. Modeling is an analysis technique that produces documentation as a side effect. What if you had a "tour guide" that could help you see what to ask? You do. Let your diagrams be your guide.
To demonstrate this, let's start with the simple UML use case diagram shown in Figure 1. This is an initial use case diagram for the automation of a security system. Here we have a Security Chief actor who uses the system to Manage Personnel, Approve Budget, Approve Security Credentials, and Monitor Perimeter. Let's start the tour with the Security Chief.
Figure 1 - Use Case Diagram
What questions could you ask about the Security Chief?
- How many Security Chiefs are there? (One per plant? One per location? Just one?)
- If there are multiple Security Chiefs, do they have distinct security credentials?
- What are the levels of the security credentials? Do some override others?
- Does the system need to record logins to the security system?
- Does the system need to record other security events? What would those be?
- Does the system need to reset login / password / security credentials?
Note that we did not fixate on the Security Chief. This "following the thread" line of questioning is but one way to discover new questions.
Let's get back and focus on the Security Chief actor. This actor is not just a generic stick figure. This is a real role a real person plays in the real world. So, consider the real people who may be in this role.
- How old are they?
- What level of education do they have?
- How technological savvy are they?
- Are they comfortable with technology?
- Are they colorblind?
- Do they have any physical handicaps? (If so there are regulatory requirements you may have to conform to, e.g. the Americans with Disabilities Act).
- What is their primary language?
The technique of developing a few basic "user personas" provides insights that may reveal critical constraints that will be important not only to requirements elicitation and analysis, but also to the design and implementation of the system. You may want to describe multiple personas to ensure any requirements that may have been overlooked when considering Security Chief as just a generic actor. Some simple examples:
- A Security Chief that was an ex-law enforcement officer. He is not a full-time Security Chief. He has never used a smart phone. He does not even use a cell phone.
- A Security Chief that is an older male retiree. He is a new employee with a high school education.
- A Security Chief that is a female veteran returning from active military service. She has left the service but is still a reservist. She walks with a limp.
A simple set of personas such as these can lead you to constraints / questions such as:
- Usability - The system has to be usable by people that are not technologically sophisticated.
- Operability - The system has to be operable by people with the equivalent of a high school level of education.
- Monitor Perimeter use case. Is there an expected timeline within which security staff must complete a full circuit of the security perimeter? Does the system and/or the physical plant account for physical disabilities?
The purpose of this is to put your thinking in a different context, a different point of view, in order to help to create a more robust requirement set. One caveat - to avoid falling into "analysis paralysis", don't try to cover every possible eventuality. Why? Because, very likely, YAGNI - You Ain't Gonna Need It. Use your judgment and create a representative set of personas.
Let's move on in our tour and "walk the diagram". From the actor let's move to the connector between the actor and the use cases. This connector indicates that the actor initiates the particular use case. This leads us to ask the questions such as:
- How often / how frequently is this use case initiated?
- What happens if the actor initiates the use case a second time before the first execution is completed?
- What happens if a second actor (another Security Guard) initializes the use case a second time before the first execution is completed?
- Are there any restrictions on initiating, stopping, interrupting the use case?
- Are there any expected preconditions (or business rules) regarding this use case?
Similarly, moving on to the use cases in the diagram:
- Is there anything else the Security Chief does that needs to be part of this system?
- Is there anything else the Security Chief does that impacts something that's not part of this system?
- Is there anything other security related functions the system may need to do (e.g. Log Security Incidents)?
- What specifically does "Monitor" Perimeter mean? How much of this is "operations" (i.e. done manually) vs. automation?
- Is there anyone else that initiates these same use cases?
- Is there anyone else that performs part of / some of these use cases?
These last two questions drive us right back to the Security Chief actor. These questions may cause the creation of additional actors. See Figure 2. Here we have added two new actors: Manger and Guard. The Security Chief manages other security personnel. There are other non-security managers in this company that also manage personnel and approve budgets. The Security Chief is not the only person that walks the perimeter. So do her Guards. We see that the Security Chief plays multiple roles: the Security Chief is a Manager and is a Guard (noted by the generalization associations with the clear arrowhead).
Figure 2 - Use Case Diagram Updated To Show Compound Roles
Having such compound roles is quite common. Consider your own position. You may have a given job title assigned by Human Resources group. But is that the ONLY thing you do on the job? If you are an entrepreneur you likely have multiple roles: Salesperson, Marketing, Accountant, Executive, Business Development, and so forth.
We have only scratched the surface with this one diagram from this simple example. The other diagrams that you may use (e.g. Activity diagrams, Class Diagrams, Sequence Diagrams, etc.) with provide you with additional and different questions, as each diagram type has its own focus.
Will you end with the "perfect" set of questions? No. But you will get a set of questions that are specifically relevant to the system you are working on. Combined with your favorite questions and elicitation techniques, you should be able to easily create a robust list of questions to be answered.
Let your diagrams tell you what to ask. Just don't get caught talking back to them.
Don't forget to leave your comments below
Robert A. Maksimchuk is a Principal Consultant at Project Pragmatics. Visit http://www.ProjectPragmatics.com for Use Case-Driven Development - Agile - Scrum - UML© - Process Improvement - Object-Oriented Analysis and Design Coach/Mentor - Systems Engineering - Enterprise Architecture. You can follow Bob via his Blog at http://rmaksimchuk.wordpress.com, Twitter @BobMaksimchuk or LinkedIn http://www.linkedin.com/in/rmaksimchuk