“ An actor is a person, organisation or external system
that plays a role in one or more interactions with your system.”
~ Scott Ambler, in “The Object Primer”
|This article is a precious part of the hybris Project Patterns series.|
Software is built to simplify, automate or improve the working habits of business workers or provide worth for consumers.
For applications with significant or important human interactions, Users are the ultimate beneficiaries of functionalities. Front-end Users would follow myriad of user experiences to explore features, look for information, educate or entertain themselves, request services, profit from promotional offers and so on. At the same time, Back-end Users would respect predefined business workflows and corporate policies in order to manage the information needed for other users or organisations.
Missing to identify all user types in the system leads to a serious gap of functionality and unstable requirements.
Unclear view over the various User types who have vested interest in the system. Limited knowledge about Users’ interaction with the future hybris solution. Lack of understanding about the information governance and usage within the solution.
Create an Inventory of all system Users. Discover roles and responsibilities. Determine access privileges. Outline User models.
Importance of Users as System Actors
All Software Methodologies pay special attention to the system users by prescribing ways of identifying actors and their communication with the system. In the lifespan of a project, Actor analysis is a key activity.
Let us take the traditional Rational Unified Process (RUP) software approach. Experience shows that the Actor definition affects various important deliverables and activities in each of the process phases – Inception, Elaboration, Conception and Transition:
Being one of the oldest iterative and incremental software development framework, the Unified Process, is characterised as a Use Case driven. Where, a Use Case typically defines the interaction steps between a User – who intends to achieve a goal – and the software system. A Use Case always requires a User or an Actor, in order to be complete … and useful.
The simplest UML diagram – the Use Case diagram, which is traditionally used in the inception phase of a project – also portrays Actors as significant entities in the analysis of a system. Without actors there is no goal. Without a goal, there would be no valuable features to define.
In the agile world, a popular work artifact for capturing requirements is the User Story. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability – usually a business user or a customer of the system. A User Story typically follows a simple template:
As a <type of user>, I want <some goal> so that <some reason or benefit>.
Persona analysis is another widely adopted technique, which allows knowing and understanding the system’s audience – it helps recognizing what drives the interests of certain user groups in the system.
Human actors may not always be required in all cases – for example, when describing non-functional or integration requirements. Nevertheless, when actors are required, it is advisable to start with their discovery early in the project, because their existence ensures the genuine benefits behind the business requirements.
For that reason, Actor discovery is an essential part of the overall Requirements Gathering process.
User Roles and Responsibilities
The disciplines of User-Centered Design (UCD) and Interaction Design (ID) teach us the benefits of identifying user roles and personas prior (!) to writing detailed requirements. The reason is simple: in most cases, a requirement makes sense when it delivers a benefit to a User. Therefore, knowing who the Users are is the first step in grasping requirements.
Embarking on a hybris project often reveals that functional specifications are produced without thinking of the end User – written largely in passive voice with no indication of an actor or a role responsibility.
A requirement like “System must support login functionality”, does not clarify who the User might be and is hard to qualify and validate. Such statements offer room for misinterpretations.
The more user-less requirements we create, the more evident it becomes that we fail to identify clear benefits for the different actors or distinguish Users’ interests in features.
The Requirements Analysis becomes a more mature source of information, once you start brainstorming – with the Business Client – questions like:
- Who will be using the system?
- What are Users’ goals and tasks?
- What are the responsibilities of the Users?
- What information might the Users need and in what form?
- What information can the Users manage?
- Are there restrictions about what the Users can do?
- Do Users interact with each other? How do we distinguish them?
- What interface might be needed regarding touching, speaking, gestures or orientation?
- Do we have Users with disabilities, like impaired vision and hearing incapacities?
Mike Cohn, an agile coach and writer, recaps the User Roles modelling with the following steps:
- Brainstorm an initial set of user roles
- Organize the initial set
- Consolidate roles
- Refine the roles
We would start with a brief introduction of common e-commerce roles and their participation in the overall usage of the system – Front-End users like Anonymous user, B2C user and B2B user, and Back-Office users such as Catalog Manager, Content Manager and Approver. This review gives the Client a feeling about the various interactions with the system, and specific responsibility of each User type in the context of the Client’s organisation.
Then, we would support our discussion with a matrix of user roles, as shown below. The table would evolve in time, together with our understanding of User responsibilities.
Writing requirements, with User Roles in mind, has another advantage – prioritisation. Defining a user for each requirement encourages the team to think about priorities and business values, which the feature delivers. This, in turn, helps with the planning of these features during the development process.
User Role Modelling
Discussions about the system Actors enable the Project Team also to think about the User Model.
The User Model is a system data model, which describes the essential elements (attributes) of the User as a system entity, such as names, passport ID, addresses, company, responsibilities and so on.
hybris supports various User types and has a powerful mechanism, which allows the organisation of Users in User Groups with predefined User Rights. Thus, the corporate User Roles can be modeled with User Groups, in order to reflect the responsibilities of users in the system.
Furthermore, User Groups can be associated with Access Rights to fine-tune the abilities of each user group when using the software. Access rights would define the accessibility of information on a very granular level.
Here is a way to express the relationship between Users, User Roles and Access Rights:
When analysing User roles and responsibilities for a Business, I have found important to explain the existing pre-defined user roles in the hybris Suite. Those roles are well suited for e-commerce / PIM applications and could be used as a foundation of designing more or derivative User Groups.
Hence, during the System Actors Inventory Workshop, I present the hybris concepts around Users, User Groups and Access Rights.
Next, I introduce a list of default hybris user roles and explain their scope of concern – abilities and access privileges to system areas.
Dedicated User Interfaces (UI)
Consumers would access the system via the various front-ends provided by the system. On the other hand, Back Office users would also require a certain User interface, which allows them to administer the various data available in the system.
Fortunately, hybris has the notion of cockpits – dedicated UIs targeted to the different types of Back Office business users. Each cockpit provides a set of workflows, screens and features, which allows the user to focus on the specifics of their job.
Therefore, when discovering the Business User types, consider drawing the attention to the default hybris UIs that the User types could use.
During the user roles Workshops, we discuss the rational behind hybris cockpits, their related workflows and types of users, which can access them.
This discussion serves as a knowledge reagent for the Business teams to comprehend how hybris addresses the information governance.
Certainly, a Client has their vision about data management and the user roles involved in it. It is common that the Client prefers to work on analyzing their own specific User definitions. However, those User roles may not fit nicely to the hybris out-of-the-box user roles.
In this case, we would work towards understanding the Client’s organisation of Users and design custom hybris User Groups. Afterwards, we would use those User types in our Requirements Gathering process, to standardise a common Glossary of User types and responsibilities.
Fine-Grained User Rights
The ultimate goal in completing the User model is identifying the Access Rights per system object for each User Role. This would give a fine precision in providing the correct accessibility for the different User types.
However this is a time-consuming activity, which requires not only knowing the system objects, but also the details of the business requirement for each role.
Therefore, it is advisable to perform the detailed “User Role – Access Right” analysis towards the end of the project, when roles are clear and responsibilities are already well defined.
You may opt for using a matrix, similar to the one below, in your analysis of access privileges for some significant objects, menu options and cockpits.
System Actors and Final Adoption of the System
The main reason we worry so much about Actors is the fact that we need to enable them to benefit or work with the new software.
Especially for Back-office Users, next to knowing what they can do is to train them to actually do it and utilize the system for confidence.
The end of the project is usually marked with a knowledge-transfer event where Business Users get trained in order to master the new solution.
Every training requires a clear indication, which business users need education and a list of topics to be taught.
Defining a Training plan is a topic of the Business User Enablement pattern.
However, here, it is worth mentioning that knowing the list of User Roles would give us uniformly the list of profiles we need to educate. Hence – it will answer the question “Who is our target Audience?”.
Similarly, the identified responsibilities of each role would provide the table of contents for all User Guides and training agendas.
Identifying the system Users early in the project provides a tremendous advantage in leading the all-embracing Requirements Gathering process, but also in defining your Roll-Out activities, Change Management- and Training Strategies.
|~ Found this article useful? Do let us know ...||