If you are in the business of developing software-based products or systems the following may sound familiar: After you have explored business goals, interviewed stakeholders, examined user workplaces, analyzed documents and operations, evaluated competing products, brainstormed, explored ideas as well as technical constraints, one question remains: How do I begin? How do I turn all the knowledge I have into a product that excites users and satisfies stakeholders? How can I ensure user benefits are created as early as possible? Intergrating future users into the product development process would be of great help, but what if that is not possible? How can I use the knowledge to elicit requirements that I can implement using an agile approach?
Here are my suggestions:
- Build user models with Personas . Personas are based on characteristics and behavioural patterns of a great number of users. Compared to actors as used in use case analysis, personas are not an abstract construct. A persona is a vivid and realistic description based on market research data, but don’t worry if you don’t have a research team at your disposal. Ask your support, distribution and marketing teams to provde you with information on user know-how and construct provisional or ad-hoc personas in a team. The result still is very helpful in most cases.
What is all this for? Personas act as a filter for the multiplicity of insights gathered through Business Analysis and Requirements Engineering processes. They help to define what is of importance for future users. And among your team they generate empathy for the users.
- Now we imagine a better future for our personas, and with it a better future for the users – with the help of stories. Does that sound strange to you? Well, storytelling is one of the oldest cultural techniques of humanity! Storytelling is a powerful means of passing on ideas. Put yourself in your personas’ shoes, with all their goals and expectations and tell a little story of how they use the new system in their daily life, and you will see: It is much more easier to discuss stories than it is to discuss concepts. By the way, these stories are called scenarios, or persona scenarios.
Usually the term scenario refers to a single use case sequence. So are we talking about use cases here? No. In this case a scenario describes what a persona does to reach a (technical) goal with the help of a system or product. A use case is a specific behaviour of a system that helps to reach a business goal. A small, but important difference.
A use case is a sequence of actions of a system performed in interaction with an actor. The next step is to turn persona scenarios into use cases by prescinding their operations.
- Prescind personas and turn them into roles, i.e. actors, and turn persona scenarios into use cases that display the expected behaviour of the system. Then, detail every single use case; show how a successul completion of a use case looks like with individual steps such as Actor does … System does … Actor does … This is called a Basic Flow. There may be situations in which certain conditions require the user to leave the straight path and to go on a detour, called Alternative Flows. Persona scenarios are an ideal means of determining possible routes through a use case. These flows are called use case stories. Don’t forget to give every use case story a name.
Use case story does sound like an agile concept, doesn’t it? Well yes, but do not confuse them with Scrum or XP user stories. User stories are described by short sentences, e.g. As a <Role> I want to <Goal/Need>, in order to <Benefit>. They summarize customer requirements in agile projects, they are a tool of communication, they serve as planning units in agile projects. Which is exactly what use case stories do. They make it possible to realize a system in little slices while providing user benefits with each slice. This concept was specified for the first time in 2011 and is called Use-Case-2.0 . This is how it works:
- Determine the use case stories that possess the highest priority and creates the greatest benefits for the users represented by the personas. Persona scenarios will provide a guiding line in this. Depending on how extensive the use case stories are you can transform one or more use case stories into a slice, a use case slice. These slices also include test cases and serve as planning units for sprints in agile projects.
What I have described here was just a first step into agile development of software-based products. The next step is to use a powerful tool that makes applying these four steps easy as a pie. As a tool manufacturer we have just the right tool, objectiF RPM.
 Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel: About Face: The Essentials of Interaction Design, John Wiley & Sons; 4th edition, September 2014
 Ivar Jacobson, Ian Spence, Kurt Bittner: Use-Case 2.0 – The Guide to Succeeding with Use Cases, E-Book 2011, http://www.ivarjacobson.com/Use_Case2.0_ebook/