The development of interactive systems requires the consideration of multiple viewpoints raised by various stakeholders. User-centred design responds to this challenge by an iterative development with early and active involvement of users and other stakeholders. Agile approaches as they are currently popular in the software development community facilitate quick responses from customers and users. Artefacts, such as prototypes that can be understood by all stakeholders play an important role in these design approaches as they evoke discussion and facilitate the development of a shared understanding. In this position paper, we reflect on the use of stories as design artefacts. We first look at the different understandings of stories and their utilization in different disciplines, such as interaction design and business process modeling. We then suggest how to relate these different "types of" stories and integrate them with other design artefacts needed for software development such as behavioral models of subject-oriented specifications in S-BPM [8]. The paper continues our work in [5]. The organization of business trips is used as a running example throughout the position paper.
This section gives a short overview of the understandings and use of stories in interaction design, business-process modeling, agile development, and requirements engineering.
According to Quesenbery and Kevin Brooks [18], "Stories have always been part of user experience design as scenarios, storyboard, flow charts, personas, and every other technique that we use to communicate how (and why) a new design will work. As a part of user experience design, stories serve to ground the work in a real context by connecting design ideas to the people who will use the product". The authors report five advantages of user stories.
1. They help to gather and share information about users, tasks, and goals. 2. They put a human face on analytic data. 3. They can spark new design concepts and encourage collaboration and innovation. 4. They help to understand the world by giving us insight into people who are different. 5. They can even persuade others of the value of a contribution.
Stories help to describe a problem and to focus on the context of an application. They can also be used to explore design decisions by describing the consequences of new designs in an exemplary way. Stories are most effective in evoking the empathy of stakeholders, if they convey a complex and nuanced understanding of involved characters, their motives, activities, and conflicts. Scenarios as they are developed in the scenario-based approach by Rosson and Carroll [19] to describe current and envisaged situations are more complex narratives in this sense. The authors comment: "Narrative descriptions of envisioned usage episodes are then employed in a variety of ways to guide the development of the system that will enable these user experiences".
Here is an example of a rather 'flat' Cooper-like persona description as it is also used in some design contexts. It is related to the example of organizing business trips which is used for illustration throughout this paper.
Susan is an IT Manager at Important Limited. She is member of the local cultural association in Smalltown. Susan has to go for several business trips every month. Because she is very much interested in culture she tries to combine her business duties with visits to museums and concerts. Susan is therefore very much interested to book ticket for trains and the reservation of hotel according to events that fit to her business activities.
Stories are also used in business-process modeling, for example, as motivational stories. Fog et al. [9] characterize storytelling as management tool and state: "
The stories we share with others are the building blocks of any human relationship. Stories place our shared experiences in words and images. They help shape our perception of "who we are" and "what we stand for". Likewise, stories are told and flow through all companies".
In the context of business administration, Denning [3] suggests eight different story patterns: (1) Sparking action, (2) Communicating who you are, (3) Transmitting values, (4) Communicating your brand, (5) Fostering collaboration, (6) Taming the grapevine, (7) Sharing knowledge, and (8) Leading people into the future. The Sparking action pattern describes how a successful change was implemented in the past, but allows listeners to imagine how it might work in their situation. For transmitting values Denning gives the hint to use believable characters and situations. The brand is usually told by the product or service itself. To foster collaboration, the stories should recount a situations that listeners have experienced. They should be animated to share their own stories. Taming the grapevine refers to storytelling with gentle humor about some aspect of a rumor that reveals it to be untrue. Sharing knowledge focuses on problems and how they were corrected. The story should have an explanation of why the solution worked. Leading people into the future evokes the future that is planned to be created.
Thiel provides in a more recent book [21] techniques for knowledge management in enterprises. In [22] she discusses storytelling as tool for reaching customer and employee loyalty.
In business-process modeling stories can be supportive as well. Simões et al. [20] state that process stories increase the expressiveness of process models. They report: " In this particular study, the creation of individual process stories by staff unveiled numerous de facto practices that were not captured by traditional process elicitation and modeling".
Part of the agile software development are so called user stories. Compared to above discussed approaches, there exists a totally different understanding of a story. A user story consist of one sentence only which has the following structure.
-As a ¡role¿, I want ¡feature¿ so that ¡reason¿.
The story of Susan could look as follows:
-As an employee, I want to manage my business trip so that I can combine the trip with cultural events.
While the first kind of stories provides a lot of motivation and detailed context information, the second kind of stories is mainly focused on functional requirements. However, they can be specified on very different levels of abstractions as well. Lawrence [17] provides nine story-splitting patterns. They are called workflow steps, operations, business rule variation, variations in data, break out spike, interface variations, major effort, simple/complex, and defer performance. Conditions and resulting actions are described. We will recall in detail the workflow step pattern only. It is described by Lawrence [17] by the following example:
-As a content manager, I want to publish a news story so that it is available on the cooperate website.
" It turned out that just to get a few sentence news story on the corporate website required both editorial and legal approval and final review on a staging site. There's no way 6-10 stories like this would fit in an iteration. In a workflow like this, the biggest value often comes from the beginning and end. The middle steps add incremental value, but don't stand alone. So it can work well to build the simple end-to-end case first and then add the middle steps and special cases" [17]. The story was split into several stories like:
-As a content manager, I want to publish a news story so that it is directly available on the cooperate website. -As a content manager, I want to publish a news story so that it is published with editor review. -As a content manager, I want to publish a news story so that it is published with legal review.
From our point of view, it makes sense to start with a motivational story and extract parts of the story in the sense of agile software development. These stories can be further refined by story-splitting patterns.
Use cases [13] are very popular for requirements engineering. They describe a system as it appears to users. They "represent the things of value that the system performs for its actors" [1]. Such actors can be users or other systems.
Use cases can specify a set of interaction sequences between a system and its actors. Use cases descriptions often conform to a structured template containing title, goal, primary actor, level, precondition, main success scenario, alternatives, extensions, etc. A widely used structured template was provided by Cockburn [2].
A use case specification contains a set of scenarios: one main success scenario and several alternative scenarios. Jacobson et al. [15] refer to use-case scenarios as stories. However, they are not stories in the sense discussed above.
Nevertheless, these stories can be characterized by one sentence like those of the agile development.
In the context of agile development with sprints of about four weeks, use cases are considered to be sometimes too complex. Therefore, a new concept was introduced in conjunction with Use Case 2.0 [14] [15]. It is called use-case slice. A use-case slice consists of one or several stories (action scenarios).
According to Jacobson et al. [15], a use-case slice "is created by selecting one or more stories for implementation..., acts as a placeholder for all the work required to complete the implementation of the stories..., and evolves to include the equivalent slices through design, implementation and test". Fig. 1 provides an abstract visualization of a complete use case specification on the left hand side, and its stories (scenarios) and possible slices on the right hand side. On the left hand side of Fig. 1 one can see the main success scenario with its alternatives. The straight line represents the main success scenario. Additionally, alternative paths are sketched. On the right hand side possible stories are shown in detail. They represent one specific path through the use case each. One or several stories can be grouped to use-case slices. One slice is intended to be implemented in one development iteration (sprint). The rest of the stories might be grouped to slices later or are not intended to be supported by the software under development.
The splitting of a use case to different scenarios looks very similar to the splitting patterns of stories. Additionally to the used pattern above, the pattern Variations in Data would result in stories like in Fig. 1.
Let us have a look at an example. Software has to be developed that supports a company in organizing business trips. The story could be characterized as follows:
-As an employee, I want to get the permission of a business trip, so that train ticket and hotel are booked.
The corresponding use case can be called organize a trip. The primary actor is Employee and there are two secondary actors called Manager and Agent. A manager has to give the permission of a business trip and an agent supports the booking of hotel and train ticket. Fig. 2 presents a corresponding use-case diagram.
The main success scenario could be: ask for permission, wait for answer, ask for booking, wait for documents, travel. However, there might be alternatives that an employee books a hotel by himself according to his private preferences. Another alternative could be that the employee books the train ticket as well according to private preferences themselves.
With S-BPM [7] there exists a quite successful notation for business-process modeling. It follows the idea of a subject-oriented approach. Subjects communicate with other subjects via messages. The behavior of subjects is specified by a variant of state-transition diagrams.
Subjects can be considered as roles like actors in use-case diagrams. This is supported by Fleischmann [6]: "in UML actors in use case diagrams represent a kind of subject...". Therefore, behavior specifications characterize the behavior of several instances of subjects. However, not all of the instances of subjects behave in the same way. Hence, it makes sense to slice the behavior specification of subjects as well. Let us first have a look at parts of the S-BPM specification for our business trip example. Message exchange between subjects Employee, Manager, and Agent is specified in the interaction diagram of Fig. 3.
The behavioral model for subject Employee is presented in Fig. 4. States are similar to Moore states. Actions are performed inside such states. Specific symbols characterize the first and the last state. The same is true for sending and receiving states. In Forbrig [10] a textual DSL for S-BPM was presented. However, the graphical specification needs fewer space. Therefore, we use the graphical representation.
Let us assume that the specification in Fig. 4 is the representation of a whole use-case specification. It specifies four different stories. One can consider the story that a requested trip of an employee is not permitted to be the first one. The other three are real success stories.
The specification in Fig. 4 represents the following four stories in the sense of Jacobson et al. [15]: It might make sense to combine stories to two slices for the agile development process. In this way implementation is distributed to two implementation cycles. In our case it was decided that the first slice consists of rejected request (story (1)) and the automatic booking (story (2)) while the second one groups the two stories of organizing the trip by the employee himself (story (3) and ( 4)). Fig. 4 is the attempt to visualize this fact. The white area represents the first slice, while the shaded area represents the second slice. If states are partly shaded and partly white they belong to both slices. This reflects the fact that all stories start and end in the same way.
Sometimes, it makes sense to provide different views on a behavioral model. With task models [4] the behavior of actors can be specified as well. It is possible to specify stories by specific sub-tasks in this notation. In the textual task specification language DSL-CoTaL (Collaborative Task Modeling Language) [11] this looks like presented in Fig. 5. Additionally to providing a new view on the problem domain, it also demonstrates how task models can be used for agile specifications.
The understanding and use of stories is different across different domains. The application of motivational stories ranges from software development, business process modeling to general management aspects. Stories might play a more important role in the future. They seem to be a very good representation of different stakeholder's views. For agile software development, stories are used as structured sentences. They can be split by story-splitting patterns or refined by action sequences. Fig. 6 provides an overview of the discussed concepts. First, actors have to be identified for an application. Users and other stakeholders should be asked to write motivational stories involving one or several actors. After analyzing those stories agile stories should be identified. Each motivational story has several of them. Each final agile story is refined by a use-case story. Several of those use case stories are combined to a use-case slice. A behavioral model has to reflect the slice and the stories. Behavioral models can be represented by state machines or task models. With domain-specific languages one could also combine both approaches in one language. Khanh et al. [16] used the term human story for a combination of user-story and persona-story. They provide an example for which they analyze: "...without the real story we could not know what it (the solution) looks like and how to do it" [16]. Wang et al. [23] analyzed that agile methods still need methods from requirements engineering like use cases, user-stories and process models. Most important is the expression of stakeholders' perspectives as stories [12]. Domainspecific-languages might help to find a notation that can be used for specifying structured stories in such a way that stakeholders can write them themselves. Additionally, those stories could be the basis for further transformations that deliver behavioral models.
The role of stories and their different interpretations was discussed. It was shown how actors, motivational stories, agile stories, use-case stories, use-case slices and behavior models are related and can be combined. They represent different views of stakeholders. Additionally, it was demonstrated how stories and slices can be represented in behavioral specifications like state-machine models and task models.