See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220999271

Software tools for requirements management in an ERP system context

Conference Paper · January 2010

DOI: 10.1145/1774088.1774123 · Source: DBLP

CITATIONS READS

9 3,874

2 authors:

Björn Johansson Rogério Atem De Carvalho

Linköping University Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFF)
108 PUBLICATIONS   760 CITATIONS    128 PUBLICATIONS   504 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Enterprise Information Systems View project

PROFNIT View project

All content following this page was uploaded by Rogério Atem De Carvalho on 24 October 2016.

The user has requested enhancement of the downloaded file.

Paper no: EE-132
Software Tools for Requirements Management in an ERP
system context
1st Author 2nd Author
1st author's affiliation 2nd author's affiliation
1st line of address 1st line of address
2nd line of address 2nd line of address
Telephone number, incl. country code Telephone number, incl. country code Telephone number, incl. country code
1st author's email address 2nd E-mail
ABSTRACT
Identification and specification of business requirements are
extremely important when development of Enterprise Resource
Planning systems (ERPs) take place. It can be stated that this is
still a problematic area not well researched and, as a result from
that, it does not exist much guidance on how to deal with
requirements. In this paper we investigate software tools for
requirements management in an ERP system context. The aim of
it is to present some prescriptive thoughts about requirements
management in an ERP system context that can be useful when
developing future requirements management software tools in the
ERP system realm. Five factors are suggested for evaluating the
tools: Fast and flexible requirements integration, support of
software releases in small pieces, support of a ubiquitous
language, support of requirements test, and support of integration.
From an initial test we suggest further research in this area that
could end up in some more practical guidelines on how to develop
a requirement management software tool that can be used when
developing future ERPs.
Categories and Subject Descriptors
D.2.1 [Software Engineering]: Requirements/Specifications –
elicitation methods.
General Terms
Enterprise Information Systems.
Keywords
Enterprise Resource Planning, Requirements management,
Software tools.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
SAC’10, March 22-26, 2010, Sierre, Switzerland.
Copyright 2010 ACM 978-1-60558-638-0/10/03…$10.00.
1. INTRODUCTION
It can be stated that requirements management in the context of
enterprise resource planning (ERPs) systems is a complex and
3rd Author
3rd author's affiliation
1st line of address
2nd line of address
3rd E-mail
costly task, since development of “wrong” requirements can result
in the need for huge changes. One of the major problems when
developing (as well as maintaining) ERPs in relation to
requirements management is how to deal with requirements in
what could be described as an ERP development value-chain. This
paper investigates some requirements management tools from an
ERP development chain perspective, also presenting some
limitations and future directions on requirements management in
the ERP context. This paper presents some prescriptive thoughts
on requirements management in an ERP system context which
could be useful when developing future requirements
management software tools in the ERP system realm. In fact this
work is part of an extensive investigation that aims at developing
a requirement management software tool that can be used when
developing future ERPs.
The paper is organized as follows: the next sections will briefly
describe ERP business requirements, how management of
requirements are made and, what problems there are within
requirements management in the ERP context. Finally, an initial
investigation of some software tools for requirements
management, followed by some conclusions, guidelines and
suggestions for future research on software tools for requirements
management in the ERP context.
2. ERP REQUIREMENTS MANAGEMENT
The basic assumption from where this paper starts from is that
organizations using ERP systems act in an environment that faces
constant changes and reassessment of organizational processes
and technology, therefore ERP requirements constantly change as
a consequence. This means that management of requirements
implemented within ERP systems must provide adaptability and
agility to support this evolutionary environment in which ERP
systems usage takes place. ERP systems development often
follows a form of waterfall development processes. It can be
claimed that the use of predictive strategies in an ERP
environment is inappropriate as well as ineffective since they do
not address the emergent and sometimes chaotic behaviors of the
market place for ERP systems.
It can be stated that requirements management in this respect
needs to be able to cope with this instability. To be able to do so
there is definitely a need for having some kind of supporting tool.
The question is then if existing software management tools are
supportive in the way they need to be. To be able to make some
kind of statement on this question the research reported in this
paper aimed at investigating existing software management tools.
This investigation was made from an ERP development chain
perspective, meaning that the investigation focused on
management of requirements from the three different stakeholders
(ERP vendor, ERP solution partner, ERP end-user), involved in a
indirect sales model (which is one way of delivering ERPs), that
all are more or less supposed to deal with development of ERP
systems – directly or indirectly. The basic assumption is that
ERPs are a standard software package which from the beginning
is developed by an ERP vendor. The ERP vendor develops the
core product which then often is changed or is further developed
by an ERP solution partner or ERP implementing consultancy
partner. The final development is then sometimes made by the
ERP end-user organization – sometimes they do it by themselves
and sometimes they use an external consultant to further develop
or, in other words, customize the ERP system.
A crucial functionality of ERP systems requirements management
software tools is therefore to support an efficient communication
as well as fast response to changes on requirements. In that way it
can be claimed that the tool needs to support agile development
methods by delivering software in small and frequent increments.
It can also be stated that one question that needs to be solved
when using agile methods, or any iterative incremental lifecycle in
general for customizing ERPs, is how to both achieve (a)
incremental requirements elicitation and (b) not to be forced to do
heavy rework due to late process integration identification [1].
This second situation, ´being forced to do heavy rework, occurs
when a given requirement is implemented into the software
without identifying all its connections with other requirements,
which is a natural situation in a process where the requirements
are identified incrementally. Thus, what happens in later iterations
is that when requirements are better understood and a given
requirement needs to be integrated to others lately, leads to
changes in code and consequent rework.
3. ERP BUSINESS REQUIREMENTS
A major problem in ERP development is the misfit between
required functionality and the functionality offered, which also
could be described as the distance between what end-users want to
have support for in the business processes they work within and
what the ERP de facto gives support for. There are definitely a lot
of different reasons for why this is the case and this paper will not
deal with all of them due to space constraints. But, it can be stated
that one important factor are difficulties of transferring business
requirements from identification to specification and further on
into implementation. To have some input on this it is first
important to stipulate what requirements and especially ERP
business requirements are. Jackson [2] describes requirements as
descriptions of the application domain and the problems to be
solved. He makes a distinction between requirements and
specifications and states that specifications are descriptions of the
interface between the developed system and the application
domain. This is in line with the statement that a requirement
specification should form a bridge between requirements
engineering and software engineering [3]. From this it could be
said that it is clear what requirements are, but, that is definitely
not the case, and there are several reasons for that. Earlier
research and practice have tried to classify and categorize
requirements. Many of these classification schemes distinguish
between functional and non-functional requirements [4]. For
example, the IEEE standard for the software requirements
specification [5] distinguishes fourteen types of requirements,
divided into functional requirements and thirteen types of non-
functional requirements. A similar distinction is made by
Robertsons [6], who identifies seventeen different types of
requirements divided into product constraints, functional
requirements and non-functional requirements. From this it can be
suggested that requirements could be seen as either: a function,
capability, or property of a proposed system; and/or, the statement
of such a function, capability, or property [4] and/or as described
by Jackson [2] as descriptions of the application domain and the
problems to be solved there. This last description emphasizes on
what and not how. This is to some extent in conflict with the
description from Zave and Jackson [7] that state: there was a time
when the epigram “requirements say what the system will do and
not how it will do it” summarized all of requirements engineering.
That time is long past. What Zave and Jackson state could be
interpreted as that a change in what requirements should describe
has occurred and that requirement specification now also to some
extent focus on how the developed system will execute the wanted
requirement. This statement suggests that the scope of what
requirements are have broaden a lot, however, it also shows the
importance of having requirements described in a way so that they
can be implemented in the way they need to be implemented.
Another angle of why there are some basic problems when
defining what requirements are, comes from the fact that many
stakeholders are involved [4] and that these stakeholders have
different perspectives on what requirements are [8]. For instance,
if a CIO says that the basic requirement on a new ERP is the need
to support the organization’s business processes, the developers
then probably will have a hard time to understand exactly how to
do that. This then results in the fact that, especially for ERPs, the
implemented solution does not reflect the specification. The
reason for this is that since the environment changes all the time
and the ERP has to be adjusted to the environment it works in, the
adopted ERP solution drifts away and relatively soon after its
adoption it has to change. Another reason, suggested for why the
specification not reflects the implemented solution, is that the
specification as such is seen as an end product and not the
evolutionary document of an ongoing process that the
specification of ERP requirements are.
It is shown from experience that the analysis and documentation
of business and software requirements by means of models are
essential for ERP development, which thereby makes it necessary
to use proper techniques and tools [9]. Odeh and Kamm [9] state
that for instance the Unified Modeling Language (UML) software
specification techniques are not suitable for translation of business
models into software models. One reason for this is that the
modeling tools does not take organizational background
characterized by shifting interests, interpretations, and power
relations into account to the extent that is necessary. It can be
stated that this is especially important when developing ERPs
since these are systems that are supposed to support the entire
organization and also support organizations interaction with
stakeholders outside the organization.
The critique Odeh and Kamm stipulate can be compared to the
three levels of software requirements that Wiegers suggests.
Wiegers [8] states that software requirements include three
distinct levels – business, user, and functional requirements. The
interesting level, in this context, is the business requirements.
According to Wiegers [8] business requirements are
representations of high-level objectives that the organization or
the customer requests from the system. In order to fully
understand what these requirements are about it is needed to
clarify what ERPs are. The definition we adopt of ERPs is the one
given by Daneva and Wieringa [10]. They state that ERPs are
packaged software solutions with the key function of coordinating
the work conducted in an organization. The coordination means
that ERPs should be seen as the vehicles that modern
organizations use to achieve business connectivity in which
everyone knows what everyone is doing in the organization. This
definition of ERPs gives a relatively clear view over what ERP
business requirements are, but, it also shows that identifying and
clearly specifying them are a difficult task. Monnerat et al., [11]
label the task of describing requirement at this level as systems
requirements definition, and it can be stated that requirements
management in the ERP context is so hard that it demands some
specific features of requirements management software tools, and
this is the focus of the next section.
4. AN OVERVIEW OF SOFTWARE
REQUIREMENTS MANAGEMENT TOOLS
There are a lot of software tools which deal with requirements
management in general software development. INCOSE
(International Council On Systems Engineering) presents a
comprehensive survey on requirements management tools [12].
The survey contains information on 43 different requirements
management tools [13]. The analysis of these builds on 14
categories which then have sub-categories connected. The 14
categories are: 1) Capturing Requirements/identification, 2)
Capturing system element structure, 3) Requirements Flowdown,
4) Traceability analysis, 5) Configuration Management, 6)
Documents and other output media, 7) Groupware, 8) Interfaces
to other tools, 9) System Environment, 10) User Interfaces, 11)
Standards, 12) Support and Maintenance, 13) Training, 14) Other
Comments. However, in the ERP context the most interesting
categories are requirements flowdown, traceability analysis, and
configuration management. The result of these three categories
from the INCOSE survey is presented in Table 1.
Table 1 Reported results from INCOSE requirements
management tools survey
Category Full Partial None
support Support support
Requirements 32 1 10
flowdown
Traceability analysis 31 2 10
Configuration 28 3 12
management
The results in Table 1 indicate that the major part of tools have
support for the three selected categories, however, an interesting
observation is that there actually there are 10-12 software tools
that do not have support for these. From this it can be concluded
that a deeper investigation of software tools for requirements
management in the ERP context is needed, and it can also be
concluded that such a investigation should be done from the
perspective that there are different stakeholders dealing with
requirements and therefore there is a need for having other
categories as support for the investigation. This is what we
describe in the next section.
5. INVESTIGATION OF SOFTWARE
REQUIREMENTS MANAGEMENT TOOLS
FROM AN ERP PERSPECTIVE
The investigation so far shows that there exists a need to
investigate existing software requirements management tools from
another perspective when it comes to ERP development. The
reason is that ERP development take place in a distributed
context. This means that the three categories, which we selected
and did a short analysis of, from the INCOSE survey, are
important. However, these categories need to be added with some
additional categories to be able to state something about what a
future requirements management tool for ERP systems would
need. There is also a need to test some tools from the perspective
of a distributed requirements management view that exists in the
ERP system development chain. Our initial investigation, by using
existing literature that compares software requirements
management tools, and also investigating some tools from their
marketing perspective, gave some additional factors that would be
of interest to further investigations. It can be suggested that an
investigation should be done from a set of factors that was
discovered as important for a “supportive” tool in the context of
ERP systems development and maintenance.
The factors we found that would be interesting to investigate were
the following: 1) Fast and flexible requirements integration, 2)
support of software releases in small pieces, 3) support of a
ubiquitous language, 4) support of requirements test, 5) support of
integration. We elaborate on each of these factors below.
Having fast and flexible requirements integration is something
extremely important in the ERP context. The reason is that
without flexibility, integration points identified later in the ERP
life-cycle demand heavy rework, which would result in a complex
and costly integration of new or adapted functionality. This means
that ERP requirements management tools should support fast and
flexible requirements integration. For doing so, the tool should
support abstract integration patterns that can be used to keep louse
coupling. For instance, instead of keeping the relationships among
business entities stored on the own entities, patterns such as the
Relationship Manager can be used [14]. This pattern manages all
the navigation and access code among entities’, making it easy to
integrate requirements.
An ERP system is not static, and it has to be able to change all the
time. The reason for that is that both technology and organizations
changes all the time. To be able to deal with this situation a
software requirements management tool in the ERP area needs to
support releases of software in small pieces, and also support and
improve communication between stakeholders. For doing so, the
tool should be able to keep track of the releases and also support
the impact evaluation of each release. One solution is to provide
ways of integrating the tool to Continuous Integration (CI)
structures. CI is a software development practice proposed to
solve the integration problems by providing both agility and fast
feedback, consisting of making (at least) daily project builds [15].
The concept of build used here is the whole process comprising:
get the latest source code from the main repository, build the
application and the database, perform both testing, inspection and
deploying, run software in a production similar environment and
give automatic and real-time feedback to developers, ensuring that
the integrated parts act as a cohesive whole and that there is
always a working version of the software available in the
repository. In that way, each release can be evaluated completely
 and immediately before it enters in production, avoiding errors
and their costs associated.
When developing and maintaining an ERP system it is of great
importance that different stakeholders understand each other, a
misunderstanding can result in major problems in the future and
be very costly to deal with. Therefore it is important that a
software tool for ERP requirements management support usage of
a language that reduces risk of misunderstandings, and, as a
consequence the misfit risks between delivered functionality and
asked functionality. The concept of ubiquitous language is very
important for communication, feedback and close collaboration
between customers and developers [16]. The ubiquitous language
is a common language for the whole project, covering the entire
communication chain from customer and business analysis to the
team’s internal conversations and coding. The ubiquitous
language reflects and feedbacks the knowledge about the domain
and must be exercised all the time in all communication tasks [1].
A software tool for ERP requirements management also needs to
have the feature of test automation providing a fast, reliable and
low cost way of guaranteeing that changes and upgrades are
compliant with earlier implemented requirements. This means that
for instance that in addition to have control over versions and
traceability of requirements it needs to provide a test bench for
new requirements. This is then related to another feature that is
needed by a software requirements management tool in the ERP
context and that is that it should support incremental development
and automated tests by providing a fast way of providing new
versions of the ERP system. This is probably extremely important
in the future since ERP systems delivery models will change by
introduction of new business models such as for instance software
as a service (SaaS). Again, integration with Continuous
Integration mechanisms is a must. Integration means to receive
messages from the testing and integration environment, in such
way that it becomes easy to check whether requirements are
correctly satisfied or not.
6. CONCLUSIONS AND IMPLICATION
FOR FUTURE TOOL DEVELOPMENT
One conclusion that can be suggested from the investigation is
that software management tools work from the assumption that,
new as well as old requirements must be connected to a project.
This is a problem in the ERP system context since development of
an ERP is not a single project event. Of course implementation of
ERP systems can be seen as a project – in fact it is probably one
of the biggest and among the most problematic IT projects,
however, since development of ERP systems is a standard
software package development, a specific requirement cannot be
connected to a single instance in the form of a project. Another
problematic area within existing software management tools is
that they do not support a distributed collaboratively collection
and analysis of requirements. Also this can be said is necessary in
the ERP system context since ERP requirements comes from a lot
of different stakeholders that act in a distributed environment.
The main conclusion from the investigation is that existing tools
do not support requirements management in the ERP system
context. The paper presents some ideas on changes for improving
the supportiveness of a requirements management tool in that
context, by introducing new factors that could be used for
investigating existing tools, but, they could also act as input for
View publication stats
the development of new software tools in the ERP requirements
management area.
7. REFERENCES
1. Carvalho, R.A., B. Johansson, and R. Soares Manhães,
Agile Software Development for Customizing ERPs, in
Enterprise Information Systems and Implementing IT
Infrastructures: Challenges and Issues. 2009,
Information Science Reference, IGI Global: Hershey,
PA, USA.
2. Jackson, M., Software requirements & Specifications: a
lexicon of practice, principles and prejudices. 1995,
London: ACM Press.
3. Jackson, M., The meaning of requirements. Annals of
Software Engineering, 1997. 3(1): p. 5-21.
4. Power, N.M., A grounded theory of requirements
documentation in the practice of software development,
in School 2002, Dublin City University: Dublin. p. 223.
5. IEEE, IEEE STD 830-1998: IEEE recommended
practice for software requirements specifications. 1998,
Los Alamitos, CA: IEEE Computer Society Press
6. Robertson, S. and J. Robertson, Mastering the
requirements process. 1999, Harlow, UK: Addison
Wesley.
7. Zave, P. and M. Jackson, Four dark corners of
requirements engineering. ACM Transactions on
Software Engineering and Methodology, 1997. 6(1): p.
1-30.
8. Wiegers, K.E., Software Requirements. Vol. 2nd ed.
2003, Redmond, Washington: Microsoft Press. 516.
9. Odeh, M. and R. Kamm, Bridging the gap between
business models and system models. Information and
Software Technology, 2003. 45(15): p. 1053-1060.
10. Daneva, M. and R. Wieringa, Cost estimation for cross-
organizational ERP projects: research perspectives.
Software Quality Journal, 2008.
11. Monnerat, R.M., R.A. de Carvalho, and R. de Campos,
Enterprise systems modeling: the ERP5 development
process, in Proceedings of the 2008 ACM symposium on
Applied computing. 2008, ACM: Fortaleza, Ceara,
Brazil.
12. INCOSE. INCOSE Requirements Management Tools
Survey. 2009 [cited 07-09-2009]; Available from:
http://www.incose.org/ProductsPubs/products/rmsurvey
.aspx.
13. INCOSE. Welcome to the INCOSE Requirements
Management (RM) Tools Survey site. 2009 [cited 07-
09-2009]; Available from: http://www.paper-
review.com/tools/rms/read.php.
14. CARVALHO, R.A. and R.M. MONNERAT, Using
Design Patterns for Creating Highly Flexible Enterprise
Information Systems, in IFIP International Conference
on Research and Practical Issues of Enterprise
Information Systems 2009. 2009, IFIP Series: Gyor,
Hungary.
15. Fowler, M. Continuous Integration. 2006 [cited 08-02-
2009]; Available from: http://martinfowler.com/
articles/continuousIntegration.html.
16. Evans, E., Domain-Driven Design: Tackling Complexity
in the Heart of Software. 2004: Addison-Wesley.