Software Tools for Requirements Management in an ...

Paper no: EE-132

Software Tools for Requirements Management in an ERP system context 2nd Author

1st Author

3rd Author

1st author's affiliation 2nd author's affiliation 3rd author's affiliation 1st line of address 1st line of address 1st line of address 2nd 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.

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.

D.2.1 [Software Engineering]: Requirements/Specifications – elicitation methods.

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.

General Terms

2. ERP REQUIREMENTS MANAGEMENT

Enterprise Information Systems.

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.

Categories and Subject Descriptors

Keywords Enterprise Resource Software tools.

Planning,

Requirements

management,

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

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 nonfunctional 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 support

Partial Support

None support

Requirements flowdown

32

1

10

Traceability analysis

31

2

10

Configuration management

28

3

12

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.

the development of new software tools in the ERP requirements management area.

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].

7. REFERENCES

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.

5.

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

1.

2.

3. 4.

6.

7.

8. 9.

10.

11.

12.

13.

14.

15.

16.

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. Jackson, M., Software requirements & Specifications: a lexicon of practice, principles and prejudices. 1995, London: ACM Press. Jackson, M., The meaning of requirements. Annals of Software Engineering, 1997. 3(1): p. 5-21. Power, N.M., A grounded theory of requirements documentation in the practice of software development, in School 2002, Dublin City University: Dublin. p. 223. IEEE, IEEE STD 830-1998: IEEE recommended practice for software requirements specifications. 1998, Los Alamitos, CA: IEEE Computer Society Press Robertson, S. and J. Robertson, Mastering the requirements process. 1999, Harlow, UK: Addison Wesley. Zave, P. and M. Jackson, Four dark corners of requirements engineering. ACM Transactions on Software Engineering and Methodology, 1997. 6(1): p. 1-30. Wiegers, K.E., Software Requirements. Vol. 2nd ed. 2003, Redmond, Washington: Microsoft Press. 516. Odeh, M. and R. Kamm, Bridging the gap between business models and system models. Information and Software Technology, 2003. 45(15): p. 1053-1060. Daneva, M. and R. Wieringa, Cost estimation for crossorganizational ERP projects: research perspectives. Software Quality Journal, 2008. 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. INCOSE. INCOSE Requirements Management Tools Survey. 2009 [cited 07-09-2009]; Available from: http://www.incose.org/ProductsPubs/products/rmsurvey .aspx. INCOSE. Welcome to the INCOSE Requirements Management (RM) Tools Survey site. 2009 [cited 0709-2009]; Available from: http://www.paperreview.com/tools/rms/read.php. 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. Fowler, M. Continuous Integration. 2006 [cited 08-022009]; Available from: http://martinfowler.com/ articles/continuousIntegration.html. Evans, E., Domain-Driven Design: Tackling Complexity in the Heart of Software. 2004: Addison-Wesley.