FACILITATING AND BENEFITING FROM END-USER
INVOLVEMENT DURING REQUIREMENTS ANALYSIS
Jose Luis de la Vara and Juan Sánchez
Department of Information Systems and Computation, Technical University of Valencia, Spain
Keywords: End-user involvement, requirements analysis, business process, BPMN, Map.
Abstract: Problems related to requirements analysis of information systems are frequent. System analysts usually lack
understanding of the business and focus on the purpose of the system, and can easily miscommunicate with
end-users. To prevent these problems, this paper describes an approach that tries to facilitate and benefit
from end-user involvement during requirements analysis. The business environment is modelled in the form
of business process diagrams by means of BPMN. The diagrams are validated by end-users, and the purpose
of the system is then analyzed through the goal/strategy Map approach in order to agree on the effect that
the system should have on the business processes. Finally, functional requirements are specified by means
of the description of the business process tasks to be supported by the system.
1 INTRODUCTION
Requirements analysis is a success factor of software
projects. Nevertheless, problems can easily arise
from the requirements stage of information system
(IS) development for organizations.
One of these problems is lack of understanding
of the business by system analysts. As a solution, it
has been acknowledged the importance of
organizational modelling (Kirikova, Bubenko,
1994). Business process modelling has been
declared as a good approach for organizational
modelling and also as a must for IS development
(Dumas, Aalst, Hofstede, 2005).
Nevertheless, business process diagrams (BPD)
alone might not be enough to understand the
business. System analysts should focus on the
purpose of the system and explore both the goals of
different stakeholders and the activities that they
carry out (Rolland, Salinesi, 2005). The use of an
approach that facilitates goal analysis is advisable.
End-user involvement is essential and very
positive during organizational modelling and
requirements analysis (Stirna, Persson, Sandkuhl,
2007). To benefit from end-user involvement, good
communication between end-users and system
analysts is necessary. However, miscommunication
can appear because of their different background.
Therefore, models that facilitate communication
should be used, such as BPDs.
This paper presents an approach that tries to
facilitate and benefit from end-user involvement
during requirements analysis. It is characterized by
the use of BPMN (OMG, 2006) for business process
modelling and the goal/strategy Map approach
(Rolland, Salinesi, 2005) for system purpose
analysis.
Organizations are modelled in the form of BPDs.
End-users validate the diagrams, and the system
purpose is then analyzed in order to come on
agreement on the effect that the IS should have on
the business processes. Finally, requirements are
specified by means of the description of the business
process tasks to be supported by the IS.
The paper is organized as follows: section 2
describes the approach, and section 3 presents our
conclusions and future work.
2 APPROACH DESCRIPTION
As explained above, the approach is characterized
by the use of BPMN and Map. Map focuses on
system purpose and can be used for business process
modelling. However, BPMN is better suited for
business process modelling, but it does not provide
any mechanism for purpose analysis. Therefore,
BPMN and Map can complement each other.
The approach (Figure 1) consists of three stages:
organizational modelling, purpose analysis, and
316
Luis de la Vara J. and Sánchez J. (2008).
FACILITATING AND BENEFITING FROM END-USER INVOLVEMENT DURING REQUIREMENTS ANALYSIS.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 316-319
DOI: 10.5220/0001711803160319
Copyright
c
 SciTePress

functional requirements specification. The first one
depicts the current business environment (As-Is),
which has a problem that could be solved by an IS.
The organization will change to solve the problem
(To-Be), and business processes will be affected.
ORGANIZATIONAL
MODELLING
PURPOSE ANALYSIS
FUNCTIONAL
REQUIREMENTS
SPECIFICATION
Task Descriptions
Business Events
Business Rules
Role Model
Glossary
Map
Operationalization Table
New BPDs
Validation
Agreement
REQUIREMENTS ANALYSIS OF INFORMATION SYSTEM
As-Is
To-Be
Operational Goals
Organizational problem or need solvable by an IS
BPDs
Figure 1: Approach overview.
The organization is modelled in the first stage.
End-users must validate the models in order to
guarantee that the organization has been properly
depicted. Several iterations are usually needed.
The organizational problem is analyzed during
purpose analysis stage. The aim is to find strategies
that can solve the organizational problem, determine
how to operationalize the strategies, and agree on the
effect on the business processes.
Finally, functional requirements are specified by
means of the description of the business process
tasks to be supported by the IS. Every task will have
a textual template that describes it.
Section 2.1 describes organizational modelling
stage, and section 2.2 describes purpose analysis
stage. For further details about task descriptions, see
(Lauesen, 2003).
2.1 Organizational Modelling
To model an organization, the first step is to
interview the staff so that people that play the
different roles of the organization describe their
daily work. In addition, it is advisable to look
through the available documentation related to the
organization activity and the business policies.
A glossary is created in order to precisely define
all the organizational concepts difficult to
understand. Business events are recurrent and
significant things that happen while the organization
activity goes by and to which the organization has to
respond. Business rules constrain or define the
organizational behaviour. In the role model the
different organizational roles and the activities they
are in charge of are specified. The operational goals
are the goals that the processes must fulfil. They
indicate both the process purpose and when a
process instance can be considered completed, and
are used to identify business processes.
Finally, BPDs are modelled. Every business
process has a BPD. BPDs are created from the
weaving of the information gathered previously, so
BPMN graphical elements correspond to this
information. The activities of the roles are modelled
as tasks and included in the business processes
whose operational goals they contribute to. Events
have to be classified as start, intermediate or final,
associated to some trigger, and included in the BPD
where the activity they trigger is. Business rules are
modelled as gateways, or defined as documentation
of the business process tasks if they cannot be
represented graphically.
As a case study, we will use the business
processes for the product development of a software
company.
The organization develops a software product
that is provided to several customers. The product is
standard, so no customer has a personalized product.
However, customers can request improvements in
the product, and the request is included in a future
version of the product.
The product manager defines the activities that
have to be carried out to develop the product through
product workflow. When a customer requests a new
improvement, an employee defines the work item
that is necessary to provide the customer with the
request. Next, employees are assigned the activities
that are necessary to develop the work items, and
employees have to estimate how long the activities
will take.
The product manager is also responsible for the
periodical creation of product versions, which have a
strict deadline, and must decide the version in which
a work item will be developed. However, problems
may arise while developing versions. Employees
may not be able to finish the activities they are
responsible for. If a problem arises, the product
manager has to try to solve it.
2.2 Purpose Analysis
After organizational modelling, the system analyst
has enough knowledge to properly understand the
organizational activity. Nevertheless, he also needs
to understand the organizational problem to solve.
Consequently, purpose analysis is based on the
business processes and the organizational problem.
FACILITATING AND BENEFITING FROM END-USER INVOLVEMENT DURING REQURIEMENTS ANALYSIS
317

Purpose analysis consists of map construction,
map operationalization, and BPDs creation.
2.2.1 Map Construction
The organizational problem is modelled in a Map
diagram (called map) where the solutions that the IS
can provide are analyzed. The map is created in a
participative manner with end-users to agree on the
solution. First, a map is created to analyze the
problem. Second, the goals that the end-users want
to achieve in order to solve the problem through the
use of the IS are modelled as goals (nodes). Third,
system features that can fulfil the end-user goals are
modelled as strategies (edges), which link the nodes.
Finally, sections are refined if needed.
The map that corresponds to the case study is
shown in Figure 2. The organization has been
experiencing problems with delivery requests. Lack
of knowledge about version development has caused
requests to be delivered later than expected by
customers. The main reason for the delay is that
activity development is not always performed as
planned because of the great amount of work that
employees have to do. The product manager needs
to be able to better project, for example, if an
employee will miss working days, or if an employee
has spent more time than planned on an activity. The
product manager needs to foresee problems and find
solutions quickly. In addition, employees need to be
able to determine more accurately the time they have
to finish the activities and how long these activities
will take.
Improve
knowledge about
version status
Facilitate work
item development
Improve
knowledge about
activity status
Start
Stop
By sharing documents
By managing calendar
By detecting
problems
By changing activity
assigment
By following workflow
By recording
spent time
By recording
activity end
Minimize time of
request delivery
By
ending version
By changing work item
version
By removing
threats
By anticipating
problems
Figure 2: Map for product development processes.
To solve the problems, employees wanted the IS
to facilitate work item development and to improve
their knowledge about the status of the activities.
The product manager wanted the IS to improve the
knowledge about the status of the versions and to
minimize the time that it takes a request to be
delivered. The system analyst proposed system
features that could fulfil these goals and modelled
them in the map in accordance with end-users.
2.2.2 Map Operationalization
When the map is finished, the system analyst has to
determine how to operationalize the map strategies,
and come to an agreement on the effect that the
operationalization will have on the old business
processes. Existing BPD elements can be remove or
maintained, and new elements may be introduced. A
table with three columns is created: a column to list
the strategies; a column to specify the BPD elements
that will operationalize each map strategy and if the
element has been removed (R), maintained (M), or it
is new (N); and a column to specify the participant
that will be in charge of the element.
Table 1: Map operationalization for the case study.
Map strategy BPD element Participant
Define Product Workflow (M)
Assign Activities to Emps. (M)
Product M.
Start Activity (N)
Carry out Activity (M)
By following
workflow
Finish Activity (N)
Employee
Start Activity (N) By sharing
documents
Finish Activity (N)
Employee
By managing cal. Manage Calendar (N) Employee
Carry out Activity (M) By recording spent
time
Finish Activity (N)
Employee
Estimate Activity (M) By anticipating
problems
Need to start activity (N)
Employee
By rec. activ. end Finish Activity (N) Employee
Check Version Developm. (M)
Problem detected (M)
Product M.
Carry out Activity (M)
By detecting
problems
Unable to finish on time (M)
Employee
By changing act.
assignment
Change Activity Assignment
(N)
Product M.
By changing work
item version
Change Work Item Version
(N)
Product M.
Version deadline (N) By ending version
Release Version (N)
Product M.
Carry out Activity (M) Employee By removing
threats
Notify changes (N) Product M.
Table 1 shows the BPD elements that
operationalize each map strategy for the case study.
There are several new elements: “Start activity”
refers to the task in which an employee begins the
performance of an activity and has to receive the
necessary documents to carry it out; “Finish
Activity” refers to the task in which an employee
finishes an activity and has to share the documents
related to its performance; “Manage Calendar”
refers to the task in which an employee divides the
time that can spent in a working day; “Need to start
activity” refers to the condition in which
ICEIS 2008 - International Conference on Enterprise Information Systems
318

Figure 3: New BPDs for product development of a software company: a) definition of product workflow; b) calendar
management; c) request management; d) version development; e) problem resolution.
an employee must be notified that an activity has to
be started in order to finish the work item before
version deadline; “Change Activity Assignment”
refers to the task in which a product manager
changes the employee that is responsible for an
activity; “Change Work Item Version” refers to the
task in which the product manager changes the
version of a work item due to some problem.
2.2.3 BPDs Creation
Finally, the analyst and the end-users agree upon the
design of the new processes. First, changes are
modelled, i.e., elements can be removed or
introduced according to the operationalization of the
map strategies. Next, BPD elements are labelled
according to the IS support on them. Tasks, events
with triggers, and gateways that depict decisions are
labelled as: “O” (out of the system), if the element
will not be part of the IS; “IS” (controlled by the
system), if the IS will be in charge of its control and
execution with no human participation; or “U”
(executed by a user), if the element will be executed
by a person that interacts with the IS.
For the case study, Figure 3 shows the new
BPDs.
3 CONCLUSIONS
The approach presented in this paper allows system
analysts to properly understand an organization, its
needs and the system purpose in a participative way
with end-users. Business people and system analysts
share a common language that is understandable to
both of them thanks to BPMN and Map. BPDs are
the basis for the end-user to validate that the
organizational structure and behaviour have been
properly understood so that the system analyst can
propose solutions based on the system purpose.
Furthermore, the approach tries to mitigate the
weaknesses of a separate use of BPMN and Map,
and benefit from the advantages of their joint use.
The approach is the result of a project with the
company CARE Technologies (http://www.care-
t.com). It has been used in several small/medium
size projects. End-users stated that they could easily
understand and validate the models of the approach,
thus facilitating communication with them.
As future work, it is planned to use the approach
in more projects, to develop a tool that supports it,
and to introduce a technique for the analysis of non-
functional requirements.
ACKNOWLEDGEMENTS
This work has been developed with the support of
the Ministry of Education and Science of Spain
under the project SESAMO TIN2007-62894 and the
program FPU, and cofinanced by FEDER.
REFERENCES
Dumas, M., Aalst, W. van der, Hofstede, A. ter, (eds.),
2005. Process-Aware Information Systems, Wiley
Kirikova, M., Bubenko, J., 1994. Enterprise Modelling:
Improving the Quality of Requirements Specification.
Info. Sys. Research Seminar In Scandinavia, IRIS-17,
Lauesen, S., 2003. Task Descriptions as Functional
Requirements. IEEE Software, 20, 2, 58-65
OMG, 2006. Business Process Modelling Notation
(BPMN) (online), http://www.bpmn.org
Rolland, C., Salinesi, C., 2005. Modeling Goals and
Reasoning with Them. Engineering and Managing
Software Requirements, 189-217, Springer
Stirna, J., Persson, A., Sandkuhl, K., 2007. Participative
Enterprise Modeling: Experiences and
Recommendations. CAiSE’07, Trondheim
FACILITATING AND BENEFITING FROM END-USER INVOLVEMENT DURING REQURIEMENTS ANALYSIS
319