This chapter covers the following topics:

INTRODUCTION

Change projects are usually instigated by managers but their impacts fall, in the main, upon the staff who carry out the operational work. The group of people in this category are usually known as the ‘users’ and this chapter examines the techniques that are used on agile projects to understand their needs and priorities. These techniques, which include persona analysis, use case modelling and user journeys, help to ensure that there is sufficient understanding of the user community before engaging in detailed analysis of the requirements. Whereas Chapter 6 focused on the business system models at the summary ‘cloud’ and summary ‘kite’ levels, this chapter is concerned with modelling the IT system and processes from summary level to user level.

BENEFITS OF A MODELLING APPROACH TO REQUIREMENTS

Chapter 6 explored the rationale for building models during business change projects. While that chapter focused on how we might model business systems, this chapter discusses modelling to understand the people who will need to use a new IT system. Techniques that model the user community offer a diagrammatical means of understanding the characteristics of the system users. This helps us to understand where there is the potential for problems or there are particular constraints that need to be taken into account when designing the solution.

Different models provide different perspectives on the problem being addressed. The simplified FMM shown in Figure 11.1 identifies three levels where models are relevant during agile business analysis. The levels show a direction of travel that includes three modelling perspectives: the business system, the solution and the system components.

 

Figure 11.1 IT systems and processes in ‘the simplified FMM’

Some of the key benefits from building models on agile projects are as follows:

Workshops can benefit hugely from the use of models. For example, a use case diagram provides a means of capturing collective understanding, providing a visual representation that provokes discussion and generates ideas. As a result, the process of discussing a particular aspect of the system, and developing the corresponding models, within a workshop environment, aids stakeholder engagement. While models offer benefits during the system development process, the collaboration activity required to develop a model is as beneficial. Where stakeholders have collaborated in the development of models, they are more likely to be committed to them.

The agile value of Just Enough, Just in Time also needs to be borne in mind as perfecting a model can result in diminishing returns from the effort deployed in doing this. If too much time is spent perfecting the model, then the value of the model is reduced. Similarly, the use of models needs to be considered, as this will help to determine whether or not they need to be kept up to date. If a model has been used for a particular purpose, there is little point in continually revising it once that purpose has been achieved. Scott Ambler has represented the ‘point of maximal value’ from models in the graph shown in Figure 11.2.

 

Figure 11.2 The value of modelling

(reproduced with permission from www.agilemodeling.com)

The time axis represents effort rather than elapsed time. Therefore, a team may spend between 4 and 10 days of effort building models during the initial requirements envisioning work, but the effort may be spread over several elapsed weeks.

The Agile Manifesto is clear that documentation takes second place to the working software. It is important that agile business analysts bear this maxim in mind and ensure that models are only created when useful and updated when necessary.

MODELLING USERS AND FUNCTIONALITY

System use case diagrams show the scope of a proposed system and the actors (or job roles) who wish to interact with the system to achieve their business goals. Modelling the user interactions and the system functionality in further detail will often uncover that a system use case is very large or complex, so cannot be achieved in full in early releases. Modelling this level of detail can, therefore, be vital when adopting agile. Figure 11.3 shows a way to use modelling to move from the business context to the system delivery and iteration contexts, where working software will be delivered. While this example shows an IT project below the dotted line, the same approach can be used for business improvement or business change projects that don’t have any IT components.

 

Figure 11.3 Using models to provide context from business to iteration

Usage and functionality are different. While it is great to know that an actor or role wants to undertake a particular function, there is also value in understanding who that actor is, and why that functionality is important to them. These two types of requirement are defined as:

Functional requirements encompass usage and functionality but are not the only types of requirement. They must be balanced with non-functional requirements (NFRs) that define the quality characteristics of the solution and the constraints that limit functional feasibility. Requirement categories, including non-functional requirements, are covered in Chapter 13.

Available techniques

The development of online systems has meant that the user community is often large and encompasses many different perspectives and personalities. This makes the analysis of the users difficult and time consuming. User experience (UX) analysis is a technique that encompasses many aspects relating to the practical usage of a product, system or service including the functionality provided and qualities such as usability, look and feel, and accessibility. UX also considers the emotions and behaviours of users during the system usage. This requires the business analyst to understand the user community, the context within which the system is used, their interactions and their typical usage paths.

In this book we are going to consider two aspects relating to modelling the system and its users:

There are many techniques that may be used to model users and functionality. These are described in overview in Table 11.1 below and are explored in further detail later in this chapter.

 

Table 11.1 Techniques to analyse users and usage

User analysis matrix		A matrix showing the use cases required by each user role.
User roles		A list identifying and describing the user roles that will interact with the system.
Personas		A stereotyped user role that describes a particular set of characteristics. Personas are useful in gaining understanding about a category of user within a specific role, including their preferences and motivations. Personas are often used to understand user interface requirements. They also have a broader application to the entire solution as they are useful when analysing usage of business and IT systems. Understanding the users who fall into this category can help define usability and accessibility requirements.
Misuse characters		A particular category of persona focusing on users who might misuse the system either in error or on purpose. Understanding the users who fall in this category can help to define security requirements.
Context diagram		An overview diagram that shows the system boundary and the actors (user role or system) with which there will be an interface. Details of the system within the boundary are not shown. In effect, this diagram represents the system as a ‘black box’.
Use case diagram		A diagram that represents both the external actors and the services they require the system to offer. Each service is shown as a use case, which is initiated by an actor external to the system. This diagram provides an overview of the functional requirements for the system.
User journeys		A model of the journey through the system when navigated by the user. Understanding the user journey can help to identify missing elements and identify usability requirements.

ANALYSING USERS AND ROLES

It is often helpful to undertake some sort of user analysis when developing a system. While the job titles will identify the range of actors, more sophisticated user analysis can extend understanding by defining sets of user characteristics, the events that cause them to use the system and the reasons for preferences and priorities. This information is highly relevant when collaborating with users in the development of a new system.

The size and complexity of both the change project and the user community will dictate how much emphasis should be placed on user analysis. For example, the introduction of a new expense claims system within the headquarters of a small organisation may require just a limited amount of effort to be spent on user analysis, whereas the introduction of a new human resources system across a multi-national organisation will require significant effort to be spent on user analysis if the delivered system is to be successful. Some change projects therefore are largely influenced by the users of the system and the job and tasks they perform. This is often referred to as the user role and is discussed further later in this chapter.

User analysis matrix

There are various aspects that may be analysed with regard to the user community, including the following:

One way of analysing usage is to consider the tasks and the issues listed above. Once understood, this information can be analysed using a graph such as a matrix. A user analysis matrix is the simplest and most popular way to represent usage. A usage matrix provides a means of representing the various users and aspects of their work. For example, a matrix may represent a list of tasks, with the job titles of those involved in the work. This helps in the identification of user roles, as discussed later in this chapter. An alternative possibility is to use a matrix to cover aspects such as the frequency and optionality of use: how often the users are expected to use the system or the process; whether it is mandatory that they use the system or whether it is optional. Figure 11.4 shows an example of a usage matrix to see how often particular users may use or interact with the training provider booking system (described in Chapter 6).

 

Figure 11.4 User analysis matrix

This example matrix does not distinguish between a manual or automated booking system. It may even be the case that the extent of automation is yet to be decided or that this analysis is to be used to determine whether an automated system is cost beneficial or not.

Other graphs could also be used to represent this data, such as bar charts, histograms or scatter graphs.

User roles

User roles are discussed in Chapter 7 and are particularly relevant when looking at system usage. Various techniques apply the user role concept: user stories begin from the perspective of a user role, and a user role is synonymous with an actor on a use case diagram. Therefore, understanding user roles is vital when eliciting and analysing the user requirements.

Essentially, a user role is a view of a system from a collective user perspective. User roles can be defined as a grouping or aggregation of users who require access to a particular set of system features. As discussed in Chapter 7, a user role may be viewed as a defined ‘hat’ that a user wears, which encompasses a set of tasks with defined access rights. A user role will have a designated set of responsibilities, which will relate to functional and non-functional requirements.

Understanding user roles is extremely important and identifying them usually begins with considering different job titles or groups of users. The jobs and users are then consolidated into ‘views’ required of the system by considering the different tasks to be performed or accessed. A matrix setting out the job titles and the potential tasks is a good starting point for a user role discussion.

Within an agile team, user roles are typically identified in collaboration with the customer and development team within a workshop setting. Techniques such as the job title/task matrix can be used during the workshop to initiate the user role discussion. An overview process for planning and organising a role development workshop is provided in Figure 11.5.

 

Figure 11.5 Approach for user role development workshop

There are several techniques that may be used within the workshop to elicit information and ideas. Brainstorming is often used but has some disadvantages, as those less comfortable with the ‘shout out’ approach may contribute little, if anything, to the discussion. Brainwriting is an alternative technique that can be used to overcome this issue during a user role development workshop. Brainwriting requires workshop attendees to write down ideas which are shared with the rest of the group. This approach helps to generate further ideas during the timebox allowed for the brainwriting exercise. Guidelines for using this technique are shown in Table 11.2.

 

Table 11.2 Guidelines for brainwriting

Area		Guideline
Timeboxing		The time allocated to each brainwriting activity should be timeboxed. Using this techniques lots of ideas can be generated quickly; 10–15 minutes is usually enough time.
Sharing ideas		During the timebox, ideas must be shared as they are identified. This may be done in two ways, either by participants writing on individual sheets of paper or by creating a central list on a flip chart or whiteboard. When using sheets of paper, each participant should take a sheet, write an idea on it, put the sheet into the centre of the table, take another sheet and so on. This results in everyone reusing each other’s sheets of paper and having the opportunity to build on each other’s ideas. A central list requires each participant to add their ideas as they arise and also results in people sharing and developing thoughts. Discussions regarding the ideas should be deferred until after the timebox has ended.
Discussing ideas		Once ideas have been generated and the timebox has ended, time should be allocated to discuss the results. This is the opportunity to talk about the ideas and to organise them.

The brainwriting technique, if used according to the guidelines above, can bring the following benefits:

Once the initial roles have been identified, another timebox should be set to organise the roles. A central record should be compiled of the roles identified in the earlier timebox and there should be a discussion about how they might be organised and described. Aspects to consider when organising user roles include the following:

Look for overlaps		It is useful to analyse the roles identified and suggest or group roles that are similar or overlap with each other. They should be recorded (possibly on sticky notes) and placed near or overlapping each other. The more similar they are, the more they should overlap. This kind of analysis is referred to as affinity analysis and it’s a data analysis and mining technique used to discover relationships among activities or tasks performed by individuals or groups.
Consolidate roles		Overlapping roles should be consolidated through discussion and clarification. Where user stories for one role are likely to be the same as those for another role, then the roles can be consolidated or one can be removed. This often results in a new role name being identified.
Add a role description		Once an organised set of user roles has been created, a short description that captures information about the role and the tasks it performs should be produced. This may include information that distinguishes one role from another.

A role card, such as that shown in Figure 11.6, is useful to record the user role descriptions so that they can be used later during the software development work.

ANALYSING PERSONAS AND MISUSE CHARACTERS

Personas are a way to form a view of users based on their perceived patterns of use of the system. They include the values held by users and the behaviours they display. They are captured in short descriptions that define characteristic behaviours, goals, skills, attitudes and environments. Fictional personal details are used to present the persona as a realistic character. A persona may be allocated a name in order to increase the sense that it is describing a real individual. This can help the project team to empathise with the users represented by the persona and gain a deeper appreciation of their needs and priorities.

User roles provide useful input when developing personas; they also enable the identification of individuals who may fulfil a user role and act in a way that is detrimental to the system and the business. These roles are called misuse characters and are important to understand if there are potential implications for performance or security.

 

Figure 11.6 Role card description

Personas

Some of the user roles will be highly important within the context of the system, possibly because they work on critical tasks or because there are large numbers of people in the role. It can be extremely helpful to generate one or two personas to help characterise and understand the different aspects of the user roles. Personas were developed by Alan Cooper in his book, The inmates are running the asylum (1999) as a practical interaction design tool. They are created through researching the types of user that might assume a user role. A great deal of information and statistics, available on the internet and within organisations, provide insights when developing personas and help to ensure that they are representative of the user roles we are analysing.

Personas are widely used in marketing and user interface design, and are used extensively in retail. Within a retail environment, products are promoted to certain categories of customer and personas are used to help explore the behaviours and expectations of these customers. For example, a company selling package holidays may have personas as shown in Figure 11.7 below.

Personas are very useful in helping us to understand the features required by customers and prioritising the work required to deliver the business goals. For example, there is a project goal to provide new features on the holiday company website that will help to achieve a business goal of increasing sales. Research has shown that 60 per cent of the customer base is composed of retired couples, so the persona for ‘Steve’ is useful to direct and prioritise work. Personas can also help the company to develop multiple features that will appeal to particular user groups and to identify impacts from environmental changes. In this situation, there may be demographic changes and ‘Steve’ may become more, or less, strategically important to the business.

The persona shown in Figure 11.8 below is for ‘Bill’, who attends courses provided by the training provider company that has been discussed throughout this book.

 

Figure 11.7 Personas for customers of a holiday company

 

Figure 11.8 Persona for a customer of a training provider

It is often the case that more than one persona will be required to describe a user role, as there may be a range of characteristics to be represented. Some teams add pictures to their personas to provide an enhanced visualisation of the target audience for the system.

Misuse characters

Misuse characters are becoming increasingly important in today’s cyber world, where everything and everyone seems to be connected. One of the issues that the interconnected world brings is the possibility for people to misuse systems for unlawful gain or mischief. Misuse characters provide a way of considering people who are not archetypal users and who might seek to sabotage the system or use it in a way that it was not intended for. They are sometimes referred to as the ‘abuser’ role.

Like personas, misuse characters are not real people. However, unlike most personas, they are exaggerated characters. Analysing misuse characters can help to elicit non-functional requirements, such as security requirements, or can help with the information assurance of systems. Examples of misuse characters with criminal intent might be people who:

Like personas, misuse characters should be captured on role cards. An example misuse character for the training provider company is provided in Figure 11.9. It can also be helpful to indicate the level of risk associated with a misuse character.

 

Figure 11.9 Misuse character card

ANALYSING THE SYSTEM CONTEXT AND SCOPE

Roles, personas and misuse characters are essential to understanding the system. However, it is how they interact with the system, and why, that really helps to clarify the context in which the system is being used or is required. Without understanding the context, it is easy to lose sight of what the change project is trying to achieve and how this relates to the broader business goals and objectives. Change projects that don’t invest effort in understanding scope and context can run into problems later when making priority decisions, only to find the context of the project was not agreed or understood. Investing time in analysing the system context doesn’t mean that the scope and context will remain fixed for the duration of the project. Rather, it provides a context by which the goals set for the project can be tested and are achievable. Using context diagrams is a way to achieve this understanding.

Context diagram

The context diagram provides a backdrop from which further modelling can evolve. Understanding the actors needing to interact with the system under development is necessary and helps in the elicitation of the features to be provided by the system; a context diagram illustrates this. It provides clarity when considering the actors and their interactions because the analysis is not clouded by the detail of functionality. The clarity of the contextual view enables further exploration of the required functionality. An example of a context diagram for the course booking system is shown in Figure 11.10.

In line with most agile techniques, the context diagram should be developed during a workshop with relevant stakeholders involved. Ideally this should not take more than an hour. If after an hour there is no agreement, then it is possible that participants are attempting to develop a model that is too prescriptive rather than considering it as a starting point from which to develop deeper understanding. The business analyst can play a valuable role in facilitating this work and managing the expectations of those involved.

When developing context diagrams, it can be useful to indicate the key interactions required by some user roles; an example is shown in Figure 11.11 below. However, it is important not to represent too much information on the context diagram as this could provide a muddled view, resulting in confusion and delay.

Context diagrams are typically used as a basis for developing use case diagrams. The use case diagram provides an elaboration of the context diagram by expanding upon the interactions and features required of the system.

Use case diagrams

Use cases, originally developed by Ivar Jacobson, have been used since the 1960s, but did not become widely known until the 1980s. Use case diagrams show the actors wishing to access the system, the use cases they require in order to achieve their goals, and the boundary of the system. A use case is a description of a particular feature that is created at varying levels, depending upon aspects such as complexity and priority. Use case descriptions can be a rich source of detail, containing information about the alternative paths required to deliver the goal of the use case.

 

Figure 11.10 Context diagram for course booking system

 

Figure 11.11 Showing ‘use’ on a context diagram

Agile teams often avoid use cases because there is a misconception that they need to be described in extensive detail before the development work can commence. This is not the case. Use cases are intended to evolve iteratively and there are several levels of documented use cases. For example, a use case can begin as a defined goal, which then becomes more and more detailed as and when the detail needs to be understood. It is also possible to document a use case using a user story; at an outline level of description, a use case and a user story have much in common. Use cases illustrate the multiple flows required to achieve the overall goal and each flow may be recorded using either a use case description or as a user story.

In 2011, Ivar Jacobson, Ian Spence and Kurt Bittner, wrote Use-case 2.0: the guide to succeeding with use cases. In this publication, they demonstrated how use cases work with agile development projects and they introduced the concept of use case slices. This concept is concerned with the identification, prioritisation, development and delivery of parts of use cases (the ‘slices’).

Use case models can be invaluable in understanding and capturing scope and context; they can help to avoid the fragmented view that can result from relying solely on user stories. The development of ‘use case slices’ and the application of different levels of use case elaboration can be extremely useful when eliciting and analysing the required features and goals of a system. Bittner and Spence (2003) in their book, Use case modelling, define six levels of detail for a use case. These levels are represented in Figure 11.12 below.

 

Figure 11.12 Use case levels

It is important to reiterate that use cases do not have to be elaborated through all these levels. Some use cases may offer just enough detail at the briefly described level, for example, if creating use cases to provide scope and context for the solution being developed and then using user stories to support the work of the development team. In other situations, it may be better to describe the use case in full. For example, where there are many alternative pathways to be handled by the use case, it is necessary to understand these in depth to inform decisions regarding which will be automated and which will be handled manually.

Use case templates vary from organisation to organisation. UML publications offer standard templates but the format is adaptable and may be changed to meet the needs of a project. The customary use case levels are ‘discovered’, ‘briefly described’ and ‘fully described’, and these are discussed below.

Discovered

A use case that has been identified on a use case model can be considered as ‘discovered,’ as shown in Figure 11.13.

 

Figure 11.13 Discovered use case

Briefly described

This should be created soon after the use case is ‘discovered’ and provides an initial, outline description (see Figure 11.14).

 

Figure 11.14 Briefly described use case

The use case can then evolve through the ‘bulleted outline’, ‘essential outline’ and ‘detailed description’ incarnations, gradually increasing in detail.

Fully described

A fully described use case contains extensive detail as shown in the example below (Figure 11.15). This includes the trigger for the use case, the main and alternative flows through the use case and characteristics such as concurrency of use, performance and security.

 

Figure 11.15 Fully described use case

The basic flow embedded within the use case shows the detailed interaction between the customer and the system and the sequence in which this interaction needs to occur.

The basic flow shows the primary and successful path through the use case. Often referred to as the ‘happy path’ or ‘main success scenario’, the basic flow should describe the series of interactions that should take place, and in what sequence, between the actor and the system in order to achieve the goal for the actor. The use case in Figure 11.16 represents the interaction between the registered customer and the course booking system that is required to achieve the goal of booking and paying for a course place.

If the basic flow details the successful path, then the alternate flows capture error handling or secondary paths required to achieve the goal of the use case or to exit from the interaction. To identify the alternate flows, it is a good idea to apply ‘what if analysis’ to the steps of the basic flow. For example, what would happen if the registered customer selects a course to book and there are no available dates; how should the system respond? The steps associated with this situation would be captured in the alternate flow 2a in the use case description.

For many, the textual description can be hard to digest and so modelling the pathways may be preferable. This can be done using a UML activity diagram as shown in Figure 11.16.

 

Figure 11.16 Activity diagram for use case

Fully described use cases help to capture valuable details concerning business rules, sequencing and the detailed requirements needed to build the system. The format provides an excellent basis for discussion and collaboration and they are an important tool in the business analyst toolkit. Additionally, ‘what if’ analysis can elicit information on flow and user expectations, and help in the development of prototypes and achievement of good UX design.

VISUALISING USER JOURNEYS

A useful way to analyse users is to look at their user journey. A user journey is a set of steps that a user might take to access a system. The journey could represent the way the users currently work (‘as is’), or how they could work in the future (‘to be’). Either way, the steps and sequence that a particular end user takes can be valuable in understanding the scope of the work, user behaviour and system functionality.

A user journey should start with a user role or a persona and should include:

The purpose of the ‘as is’ user journey, as shown in Figure 11.17 below, is to understand the current process, which helps to identify any disconnects or ‘pain points’ that a future solution will need to address. In contrast, the purpose of the ‘to be’ user journey is to show how the journey might look in the future and what benefits that might bring to the user or the organisation.

 

Figure 11.17 ‘As is’ user journey

The format of a user journey can vary depending on the intended audience. Many user journeys are represented visually, as shown in Figure 11.17, but this can depend upon the ability and confidence of the analyst in building a free-format, hand-drawn representation. If preferable, a series of boxes and lines drawn using a drawing package may also be used. The important point is to represent what the user wishes to do and achieve during this journey.

CONCLUSION

Collaborating with the user community is an essential part of an agile project. However, discussions are greatly enhanced by applying frameworks and techniques, such as those set out in this chapter, to elicit and analyse information that may otherwise be overlooked. For this reason, the models explored in this chapter are extremely useful additions to the agile business analyst’s toolkit.

REFERENCES

Bittner, K. and Spence, I. (2003) Use case modelling. Boston, MA: Addison Wesley.

Cooper, A. (1999) The inmates are running the asylum. US: Sams Publishing.

Jacobson, I., Spence, I. and Bittner, K. (2011) Use-case 2.2: the guide to succeeding with use cases. Ivar Jacobson International. Available from: www.ivarjacobson.com/publications/white-papers/use-case-ebook [20 December 2016].

FURTHER READING

Cooper, A. (2008) The origin of personas. Alan Cooper website. Available from: www.cooper.com/journal/2003/08/the_origin_of_personas [20 December 2016].

Mears, C. (2013) User journeys – the beginners guide. The UX Review. Available from: theuxreview.co.uk/user-journeys-beginners-guide/ [20 December 2016].