E-service Requirements from a Consumer-Process
Perspective
Linda Peursum (3698645) – Group A
Introduction
The method described in the article by Henkel and Perjons (2011) is an evaluation mechanism for current eservices. Henkel and Perjons evaluate these e-service from the consumers’ perspective in order to identify
relevant problems and propose solutions.
To achieve this goal, one should perform three main activities (Henkel & Perjons, 2011) that support this
method, namely:



Consumer process identification
Consumer process analysis
Solution summary
These activities are performed by a process/e-service analyst in collaboration with the consumer of the eservice. Figure 1 shows the model by Henkel and Perjons (2011). The arrows below the blocks indicate the
instruments that are used for every step. The desired output of this method is a crosstable that contains the
problems with their corresponding solutions.
Designed
e-service
1) Consumer
process
identification
Guiding questions
based on a fouraspects process
framework
Description of the
consumer
process in which
the e-service is
used
2) Consumer
process analysis
Guiding questions based
on a four-aspects
process framework and
four solution areas
Identified problems
and possible
solutions
3) Solution
summary
Summary of
problems and
solutions
Table structure based
on a four-aspects
process famework and
four solution areas
Figure 1: Overview of the approach (Henkel & Perjons, 2011)
The first activity is to identify consumer processes (Henkel & Perjons, 2011). This is done via a four-aspect
process framework, which consists of the following four components: functional, behavioural, informational,
and organisational. First of all, all activities between the consumer and the e-service, as well as the activities
after this interaction, are listed (functional). Next, all the activities are ordered by execution and time of
occurrence (behavioural). Then, the information structure that is needed to perform the activities is described.
This includes both the information exchange from the e-service under study, as well as the information
exchange within the e-service context (Henkel & Perjons, 2011). Lastly, it is discussed which role is responsible
for the execution of which activity. This includes both the consumer and the company that provide the eservice. The main deliverable outcome for this activity is the consumer process description. The timely
deliverables are: list of activities, model of interlinked activities, information description, and a role list.
The second activity identifies the problems that are concerned with the e-service (Henkel & Perjons, 2011).
These problems are based upon the above mentioned functional, behavioural, informational, and
organisational components. For example, there could be a problem with the fact that the e-service needs
information that is not directly available at the consumers’ side. These problems are mapped onto a solution
framework, consisting of: consumer process improvement, provider rules, provider e-service, and consumer IT
systems (Henkel & Perjons, 2011). As can be seen in Figure 2, these four solution areas are characterised by the
relevant party and the processes or IT infrastructure at their side. Every problem can exist in multiple solution
areas. Therefore, problems are mapped onto solution areas. Since the problems are accounted for every
component, there are four problem documents with their corresponding solution documents. The main
deliverable from this activity is a combined list of all solutions mapped onto the problems per component.
E-service
consumer
E-service
provider
Business
Consumers’
business processes
Provider’s business
rules
IT
Consumers’ IT
systems
Provider’s e-service
Figure 2: The four solution areas (Henkel & Perjons, 2011)
The last activity is concerned with giving an overview of the problems mapped onto the solution areas. This
results in a cross table with all problems concerning functional, behavioural, informational, and organisational
components, mapped against the four solution areas (Henkel & Perjons, 2011).
The method was developed by Martin Henkel and Erik Perjons in 2011. They are both members of the
department of computer and systems sciences at Stockholm University. Martin Henkel has had a business
background in the beginning of his career, but has been an academic with a PhD certificate since 2002. Martin
Henkel is specialised in service oriented computing and UML. He has published 57 articles, between 2004 and
2013, which are cited about 154 times1. Erik Perjons is also a researcher at Stockholm University. He has
published 64 papers, from 2000 until now, which are in total cited 490 times. His specialisation is in enterprise
modelling, service science, business process management, and model driven development2.
Example in practice
This example is based upon an e-service tool of a Jumbo Supermarket. The e-service is an information exchange
tool which is used by the staff of the company. Before this tool went live, information was requested in the
store itself by looking at printed rosters, filling in paper forms, and verbal contact.
Consumer process identification
First of all the consumer process concerned with this e-service is identified. At the consumers’ side, the
employee has to log-in at the e-service via internet. The main activities that the employee can perform are: 1.
Read department news; 2. Request leave of absence; 3. Look at rosters; 4. Find substitute; and 5. Change
personal data. There is no true order of activities, but a simple use case to find substitutes might be:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Login
Click on ‘Roster’  ‘Per week’
Click on ‘Roster’  ‘Search roster’
Fill in department (for example ‘counter’) and week number
Fill in department (for example ‘service desk’, both the service desk and counter are departments for
employees who are cashiers) and week number
Click on ‘Find substitute’
Enter department, date and time
Click on substitutes and send mail.
Log out
Since there is no direct communication with the Jumbo itself, there is only data exchange with the server which
is synchronous. Within the service interaction, information can be entered manually in every form. However,
date and time will give predefined options. Also, the email that will be sent to any possible substitutes is a
predefined format which you cannot edit. In the service context, information have to be provided by the team
leaders per department. From the organisational perspective, a provider and consumer is needed. In this case
1
2
http://scholar.google.com/citations?user=1d0w88EAAAAJ&hl=nl
http://scholar.google.com/citations?user=ndxHMYsAAAAJ&hl=nl
the provider is the team leader of a department, which provides data and information. The consumer is the
employee of the Jumbo who visits the website.
Consumer process analysis
First, the functional aspect will be discussed. In the Jumbo staff tool, week numbers have to be adjusted
manually to see the current roster. This is a manual task which can be automated very easily by showing the
current week number and will cause more convenience at the consumers’ side. The solution for this problem is
located within the provider’s e-service. Also, in order to get the approval of the team leader for a substitute,
the consumer still has to call to Jumbo. This is an extra task which could be automated in the program by
providing in-page messages which can be confirmed and approved. The solution for this problem is located at
the area of the consumers’ business processes, provider’s business rules and the provider’s e-service. Next, the
handling of finding a substitute by sending an email is unnecessarily complex and could be simplified by
showing, for example, phone numbers which allow for more direct and effective communication. Lastly, the
provider edits the web content. However, no notification is given that there are new messages or roster
changes available. To overcome this problem, notifications should be sent to the consumers’ email addresses
with a link to the webpage. This solution can be found in the area of provider’s e-service.
Second, within the behavioural component it is notifiable that if the consumer wants to see the roster of all
cashiers multiple departments must be selected in sequence. This is a problem for which the solution lies
within the provider’s e-service area. If there is a possibility to select multiple departments at once, this will
affect the business processes of the consumer. In order to change this, the provider’s business rules must be
adjusted to allow other means of communication. In effect, this influences the provider’s e-service and the
business processes of the consumer.
Third, the informational component also indicates some problems with the staff tool. The problem that
departments (also a behavioural problem) should be selected in sequence is an unnecessary re-packaging of
information which can be avoided. Also, employees get emails with their roster for a certain week. Because this
roster is already provided in the email, logging in onto the website is sporadic and not necessary anymore. This
is unnecessary re-packaging of information (in this case the roster) because it allows you to not use the eservice and by that, miss all other information and useful functionality. Employees should be triggered to use
the e-service by providing a link to the webpage (automatic login) where the roster can be found. This is a
solution which is located at the provider’s business rules, provider’s e-service and the consumer’s business
processes.
Lastly, there are no problems found within the organisational process aspect. There are no unnecessary uses or
limitations of roles which can be avoided.
Solution summary
Based on the information provided in the second step, the consumer process analysis, a solution summary can
be made in the form of a cross table (Henkel & Perjons, 2011). This table is provided in Table 1. A template for
this deliverable can be found in the Appendix. The cross indicates that the solution area is influenced by
changes in other solution areas.
Process-Deliverable Diagram
In order to generate a more clear idea and understanding about a method, a formalised method engineering
discipline is applied. This method engineering discipline is described by Weerd and Brinkkemper (2008) in their
article about Meta-Modeling for Situational Analysis and Design Methods. Weerd and Brinkkemper (2008)
introduce the so-called ‘Process-Deliverable Diagram’, in which both the process side and the product side is
modelled. They combined the UML activity diagram with the UML class diagram in order to model these sides
respectively.
Problem
Aspect
Functional
Manual week
number
selection
Manual
substitute
approval
E-mail
substitute
No notification
messages
Behavioural
Manual
selection of
multiple
departments
Informational
Same as
behavioural
component
In-email
information
Organisational
Consumer
Process
Improvement
x
x
Provider Rules
Allow
mediation of
team leader
Allow phone
number display
x
x
Allow selection
of multiple
departments
Allow direct
login via
provided link in
email
Allow direct
login via email
Provider EService
Consumer IT
systems
Automatic
current week
number display
In-page
messages
Display phone
numbers
Send e-mail
with
notifications
Select multiple
departments
x
x
Adjust e-mail
settings to
include link and
not roster
No problems
found
Table 1. Overview of the problems and solutions
The Process-Deliverable Diagram applied to the method described by Henkel and Perjons (2011) is depicted in
Figure 3. On the left side of the diagram, the UML activity diagram is shown. These are all process fragments
that precede each other sequentially (Weerd & Brinkkemper, 2008). The three main activities are open
activities because their sub activities are known and expressed in each of the three activity blocks. The second
main activity shows a, more unusual, for-loop by using a condition ‘all process aspects analysed’. If not all four
process aspects are analysed, then the previous two activities need to be performed again for the remaining
process aspect(s). There are no roles illustrated in all three blocks since all activities are performed by the same
roles (Weerd and Brinkkemper, 2008), being the e-service analyst and a consumer. However, it can be assumed
that all deliverables are formally created by only the e-service analysts. The roles are only illustrated in the
activity table (See Table 2).
The right side of the diagram shows the product fragments, or so-called ‘deliverables’ (Weerd & Brinkkemper,
2008). The dotted arrow from the left to the right side depict these deliverables/concepts. There are no closed
concepts (of which the sub concepts are not relevant or not known in this context) since all sub concepts are
known and relevant in this model (Weerd & Brinkkemper, 2008). The concepts are elaborated in the concept
table (Table 3).
In the next sections, the reader can find a Process-Deliverable Diagram, an activity table and a concept table.
These diagrams and tables will give a better understanding of the original method described by Henkel and
Perjons (2011).
Figure 3: The Process-Deliverable Diagram applied to the article of Henkel and Perjons (2011)
Activity table
Table 2 illustrates an overview of all activities used in the Process Deliverable Diagram in Figure 1, its sub
activities and their description. In addition, the roles performing the (sub) activities are provided. The capital
words represent the deliverables and concepts that are illustrated in the Process Deliverable Diagram.
Activity
Sub activity
Consumer Process
Identification
Describe activities
Description
The e-service analyst describing the activities in a
FUNCTIONAL ASPECT DESCRIPTION that is part of the
CONSUMER PROCESS
Describe order of
The e-service analyst describes the order of the
activities
activities in a BEHAVIORAL ASPECT DESCRIPTION,
which is part of the CONSUMER PROCESS
DESCRIPTION
Describe needed
The e-service analyst describes the needed
information
information used by the activities in an
INFORMATIONAL ASPECT DESCRIPTION, which is
part of the CONSUMER PROCESS DESCRIPTION
Describe
The e-service analyst describes the responsibilities
responsibilities
for executing activities in an ORGANIZATIONAL
ASPECT DESCRIPTION, which is part of the
CONSUMER PROCESS DESCRIPTION
Consumer Process
Identify problems
The e-service analyst analyses all four ASPECTs for a
Analysis
PROBLEM and corresponding SOLUTION. If not all
ASPECTs are yet discussed, then the e-service analyst
analyses a PROBLEM (if there is one) for the
remaining ASPECT. The identified PROBLEM is saved
into a PROBLEM LIST.
Identify solutions
The e-service analyst identifies one or multiple
SOLUTION(s) for, if available, every PROBLEM
identified in the previous activity. A SOLUTION can
be a BUSINESS CHANGE, an IT CHANGE or both.
Every SOLUTION is saved into a SOLUTION LIST and a
SOLUTION relates to one or more SOLUTION AREAs.
Solution Summary
Summarize problems The e-service analyst maps the PROBLEM LIST and
with corresponding
their ASPECTs onto the corresponding SOLUTION
solutions
LIST and their SOLUTION AREAs. This results in a
CROSSTABLE.
Table 2: Activity table of the model described by Henkel and Perjons (2011)
Role
e-service analyst,
consumer
e-service analyst,
consumer
e-service analyst,
consumer
e-service analyst,
consumer
e-service analyst,
consumer
e-service analyst,
consumer
e-service analyst,
consumer
Concept table
Table 3 contains all deliverables and concepts illustrated and used on the right side of the Process Deliverable
Diagram. For every concepts, a description and/or definition is provided, mostly originating from the article by
Henkel and Perjons (2009). In addition, all sub concepts (aggregative concepts) or specific concepts (from
general concepts) are described with their relation to their ‘parent’ concept.
Concept
FUNCTIONAL ASPECT DESCRIPTION
Description
A document containing what process elements are being performed, and
what flows of informational entities are relevant to these process
elements; described in the context of the user. (Curtis, Kellner, & Over,
1992; Henkel & Perjons, 2011)
BEHAVIORAL ASPECT DESCRIPTION
A document containing when process elements are performed (e.g.,
sequencing), as well as aspects of how they are performed through
feedback loops, iteration, complex decision-making conditions, entry and
exit criteria, and so forth; described in the context of the user. (Curtis et
al., 1992; Henkel & Perjons, 2011)
INFORMATIONAL ASPECT DESCRIPTION
A document containing where and by whom (which agents) in the
organization process elements are performed, the physical
communication mechanisms used for transfer of entities, and the physical
media and locations used for storing entities, described in the context of
the user. (Curtis et al., 1992; Henkel & Perjons, 2011)
ORGANIZATIONAL ASPECT DESCRIPTION
A document containing ‘the informational entities produced or
manipulated by a process; these entities include data, artefacts, products
(intermediate and end), and objects; this perspective includes both
the structure of informational entities and the relationships among them’,
described in the context of the user. (Curtis et al., 1992; Henkel & Perjons,
2011)
ASPECT DESCRIPTION
A document containing a description of a specific viewpoint of a
CONSUMER PROCESS (Henkel & Perjons, 2011). An aspect can be a
FUNCTIONAL, BEHAVIORAL, INFORMATIONAL or BEHAVIORAL. There are
no other aspect occurrences.
CONSUMER PROCESS
A collection of the FUNCTIONAL-, BEHAVIORAL-, INFORMATIONAL-, AND
ORGANIZATIONAL ASPECT DESCRIPTION (containing process information)
from the viewpoint of the consumer or user of the e-service. (Henkel &
Perjons, 2011).
PROBLEM
A limitation that the e-services impose on the consumer processes. A
PROBLEM exists when there is a gap between a desired state of affairs
and the actual. (Henkel & Perjons, 2011)
PROBLEM LIST
A PROBLEM LIST contains all PROBLEMs identified. (Henkel & Perjons,
2011).
SOLUTION
A SOLUTION is based upon the analysis of the problem from four
SOLUTION AREAs and better fits the desired or optimal state (Henkel &
Perjons, 2011). A SOLUTION consists of a combination of changes or
improvements on the service provider’s and/or the service consumer’s
sides.
BUSINESS CHANGE
An alteration of a predefined business function. (Henkel & Perjons, 2011)
IT CHANGE
An alteration of an existing IT service or component. (Henkel & Perjons,
2011)
SOLUTION LIST
A SOLUTION LISTS contains all identified SOLUTIONS for the identified
PROBLEMs. (Henkel & Perjons, 2011)
SOLUTION AREA
The defined range within which the solution can be found. The SOLUTION
AREA consists of the predefined quadrants of the CONSUMERS’BUSINESS
PROCESSES, PROVIDER’S BUSINESS RULES, CONSUMERS’ IT SYSTEMS,
and/or PROVIDER’S IT SYSTEMS. (Henkel & Perjons, 2011)
CONSUMERS’ BUSINESS PROCESSES
The internal business process in which the e-service is used by the
consumer of the service. (Henkel & Perjons, 2011)
PROVIDER’S BUSINESS RULES
The business rules that govern the design and use of the e-service at the
provider’s side of the interaction. (Henkel & Perjons, 2011)
CONSUMERS’ IT SYSTEMS
The internal business process in which the e-service is used. (Henkel &
Perjons, 2011)
PROVIDER’S E-SERVICE
The e-service designed and offered by the provider of the service (and
used by the consumer). (Henkel & Perjons, 2011)
CROSSTABLE
A technique for comparing two classification variables. (Blumberg,
Cooper, & Schindler, 2008). A template for this deliverable can be found in
the Appendix.
Table 3: Concept table of the model described by Henkel and Perjons (2011)
Related literature
The paper is about e-service requirements from a consumer-process perspective (Henkel & Perjons, 2011). This
title already gives notion to its main domain: requirements engineering. Requirements engineering is defined
by Nuseibeh & Easterbrook (2000, p. 37) as “the process of discovering that purpose, by identifying
stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication,
and subsequent implementation”. The method described by Henkel and Perjons (2011) also conforms to this
definition, with the exception being that Henkel and Perjons look at already existing e-services. But it is not
only positioned within requirements engineering, but also in process modelling. This is due to the fact that
consumer processes are defined and therefore modelled. The origins of the four-aspect process framework
also lie within the domain of process modelling. Although the paper links this framework to Jablonski and
Bussler (1996) and Rausch-Schott (1999), they did not introduce this framework. The framework was first
introduced by Curtis, Kellner and Over (1992) as mentioned in the article by Rausch-Schott (1999). They
underpin the four aspects by explaining that “these perspectives underlie separate yet interrelated
representations for analysing and presenting process information” (Curtis et al., 1992, p. 77).
Furthermore, the model has been used in other articles. For example, Tie and Zhang (2011) uses the evaluation
model of Henkel and Perjons. They use different models to propose solutions to the barber model problem (a
communication and synchronization problem between multiple systems (Tie and Zhang, 2011)), which are also
related to producer and consumer problems. Furthermore, the authors use the initial article in two different
papers. First of all, Perjons (2011) uses it to describe model-driven process design from different models. The
notion of e-service is described by Perjons by referring to the paper of Henkel and Perjons (2011). Also, a book
by Henkel, Perjons and Thelemyr (2013) describes how e-services can be designed on the concept of user
innovation. This is an extension of the topic of the paper about e-service requirements, but not an extension of
the evaluation method (Henkel & Perjons, 2011). These articles are published later than the original article but
cannot be considered to be fully based upon the method that was originally described, since they do not use
any steps from the method in their model-driven design process.
Related to the approach presented in the article by Henkel and Perjons (2011) is the approach made by
Arsanjani et al. (2008). They describe a method for developing service-oriented solutions. Service-oriented
solutions are related to the e-service model as they both strive for a design that has the least of impact to the
context in which they are used. This is also discussed by Piccinelli, Emmerich, Zirpins and Schutt (2002) in their
article about web service interfaces for inter-organisational business processes. There are several other authors
that also discuss this topic (Erl, 2008; Josuttis, 2007; Papazoglou & Yang, 2002).
Other related articles are also mainly published by Martin Henkel and Erik Perjons. For example, Henkel,
Johannesson, and Perjons (2011) published an article about an approach for e-service design using enterprise
models. However, they do not use the e-service evaluation method, but propose a new method based on
values and goals. This is a way to design e-services, and not to evaluate them. There are no current articles that
describe the application of the e-service evaluation method. The only case study available is provided in the
original article.
It can be concluded that the e-service evaluation method is based upon the four-aspect model by Curtis et al.,
(1992). However, applications of the e-service evaluation method are not yet published. Nevertheless, there is
some literature available related to the notion of e-services, e-service design, and practices related to e-service
design.
References
Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., & Holley, K. (2008). SOMA: A method for
developing service-oriented solutions. IBM Systems Journal, 47(3), 377–396.
Blumberg, B., Cooper, D.R., & Schindler, P.S. (2008). Business research methods. Berkshire: McGrawHill Higher Education.
Curtis, B., Kellner, M. I., & Over, J. (1992). Process Modeling. Commun. ACM, 35(9), 75–90.
doi:10.1145/130994.130998
Erl, T. (2008). Soa: principles of service design. Upper Saddle River: Prentice Hall.
Henkel, M., Johannesson, P., & Perjons, E. (2011). An Approach for E-Service Design using Enterprise Models.
International Journal of Information System Modeling and Design, 2(1), 1–23.
doi:10.4018/jismd.2011010101
Henkel, M., & Perjons, E. (2011). E-service Requirements from a Consumer-process Perspective. Proceedings of
the 17th International Working Conference on Requirements Engineering: Foundation for Software
Quality, Berlin, Germany, 121-135
Henkel, M., Perjons, E., & Thelemyr, A. (2013). Applying the Lead User Method for Designing e-Services Practical Techniques and Experiences. In J. Falcão e Cunha, M. Snene, & H. Nóvoa (Eds.), Exploring
Services Science SE (pp. 43–57). Berlin: Spinger Berlin Heidelberg. doi:10.1007/978-3-642-36356-6_4
Jablonski, S., & Bussler, C. (1996). Workflow Management Systems: Modelling Concepts, Architecture and
Implementation. International Thomson Publishing Services.
Josuttis, N. (2007). Soa in Practice. Sebastopol: O’Reilly.
Nuseibeh, B., & Easterbrook, S. (2000). Requirements Engineering: A Roadmap. In Proceedings of the
Conference on The Future of Software Engineering, New York, USA, 35-46. doi:10.1145/336512.336523
Papazoglou, M., & Yang, J. (2002). Design Methodology for Web Services and Business Processes. In A.
Buchmann, L. Fiege, F. Casati, M.-C. Hsu, & M.-C. Shan (Eds.), Technologies for E-Services: Vol. 2444 (pp.
54–64). Berlin: Springer Berlin Heidelberg. doi:10.1007/3-540-46121-3_8
Perjons, E. (2011). Model-Driven Process Design : Aligning Value Networks, Enterprise Goals, Services and IT
Systems. Retrieved from Stockholm University, Department of Computer and Systems Sciences.
Piccinelli, G., Emmerich, W., Zirpins, C., & Schutt, K. (2002). Web service interfaces for inter-organisational
business processes an infrastructure for automated reconciliation. Proceedings of the Sixth International
Enterprise Distributed Object Computing Conference, Lausanne, Switzerland, 285–292.
doi:10.1109/EDOC.2002.1137717
Rausch-Schott, S. (1999). TriGSflow-workflow management based on active objects-oriented database systems
and extended transaction mechanisms. Linz: Universitätsverlag R. Trauner.
Tie, J., & Zhang, B. (2011). Research of barber model in process concurrency control. Proceedings of 2011
International Conference on Mechatronic Science, Electric Engineering and Computer (MEC), Jilin, China,
2270–2273. doi:10.1109/MEC.2011.6025945
Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods.
In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and
Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing.
Appendix: Deliverable template
<< This template contains all problems and solution mapped onto the solution areas that are identified in the
Consumer process analysis. This template corresponds to the deliverable that should be generated in the
Solution summary >>
Aspect
Problem
Consumer
Provider
Process
Rules
Improvement
Provider EService
Consumer IT
systems
Functional
<< If available,
insert
functional
problems in
seperate subrows here >>
<< If available,
insert provider
e-service
change/
solution here, if
available.
Repeat for
following rows
>>
<< If available,
insert consumer
IT systems
change/solution
here. Repeat
for following
rows >>
Behavioural
<< If available,
insert
behavioural
problems in
seperate subrows here >>
<< If available,
insert consumer
process
improvement/
solution here, if
available.
Repeat for
following rows
>>
<< insert ‘x’ if a
change in one
solution area
enables a
change in this
solution area.
Repeat, if
necessary, for
other rows and
columns >>
Informational
<< If available,
insert
informational
problems in
seperate subrows here >>
<< If available,
insert
organisational
problems in
seperate subrows here >>
Organisational
Table 4: End-deliverable template
<< If available,
insert provider
rules change/
solution here, if
available.
Repeat for
following rows
>>