Using business process modelling to reduce the effects of requirements changes in software projects Eystein Mathisen
Kjell Ellingsen
Terje Fallmyr
Bodø Graduate School of Business N-8049 Bodø, Norway Email:
[email protected]
Bodø Graduate School of Business N-8049 Bodø, Norway Email:
[email protected]
Bodø Graduate School of Business N-8049 Bodø, Norway Email:
[email protected]
Abstract—Requests for changes to software systems have a potential damaging effect on software projects and the life span of software. Changes can not be avoided since it seems impossible to produce complete, correct and stable requirements. Late requests for deep, structural software changes are particularly harmful. We present an approach for early detection of evolutionary changes of software requirements, especially deep structural changes that have implications for the software architecture. The approach is based on using business process modelling (BPM) as a tool to increase the level of understanding of the problem domain in early stages. This enables the system stakeholders to identify and prevent certain types of changes earlier in the development process than what is usual with most commonly used development methods. We present a possible taxonomy of changes to help managing the different types of changes that are most important for our purpose. Index Terms—Business Process Modeling, requirements engineering, requirements changes, requirements management.
I. I NTRODUCTION The management of change in software systems seem to be a persistent problem in the software industry. If not handled properly, it is very likely that requests for changes in requirements will have a negative impact on software quality, cause cost overruns, delays, unsatisfied users and, in worst case, cancelled projects. Nevertheless, changes to software systems is unavoidable since it is not possible to come up with a complete and correct set of requirements that remains stable throughout a software system’s useful life. There are various reasons why these change requests occur. Some are outside the scope or control of a software development project, and the success or failure of a project can not be attributed to the use of a certain “best practice” software process model. Others are rooted in an inadequate and limited understanding of the problem the software system is supposed to solve. It is these latter types of changes and how we can deal with them that are the focus of our research. The traditional waterfall software process model [1] has largely been abandoned and replaced by iterative, incremental and agile approaches to software development [2], [3] in order to accommodate requirements changes during the project lifecycle. One of the basic principles of agile methods for instance, is to deliver stable, integrated and tested software increments to the customer who can provide feedback in
the form of new and/or changed requirements. It is assumed that the development team has access to customer representatives with sufficient understanding of the problem domain to be able to provide useful feedback on software increments. Furthermore, mature software organizations are continuously trying to improve their requirements management processes to estimate the impact and cost of requirements changes to the target software. This is normally handled through change impact analysis techniques, where the effects or consequences of a potential change to the system is identified together with implementation cost estimates. Most requirements are elicited during the early stages of a software project and evolve throughout the system’s life cycle. Requirements evolve or change in order to satisfy the changing needs of the system stakeholders. According to Humphrey [4], the customer does not initially know what is needed of a software system and as a consequence, requirements are wrong and will change and evolve over time. Changes to a software system during its lifetime are nevertheless necessary due to the growing mismatch between the system and the business it is intended to support. Some relevant examples of changes are noted in [5], [6]: • • • •
• •
changes in technology the requirements changes as a result of increased understanding of the problem during development the user’s needs evolves as a consequence of changes in business policies and procedures the problem the system is intended solve, changes as a consequence of changes in business policies and processes market changes, and legislative or regulatory changes.
These types of changes will have a more or less severe impact on the software system under consideration depending on a number of factors like time of change (early/late development stages, after delivery, etc.) or type of change. In our work we are primarily interested in identifying what kinds of changes are causing undesirable effects on a software system during its lifetime, in particular the software architecture. The paper proposes a hypothesis that business modelling enables the system stakeholders to identify and prevent some types of evolutionary changes earlier in the development
process. It is of particular interest to investigate if and how a greater emphasis on modelling the business processes in early stages of software development/evolution projects will impact the software quality in terms of increased system robustness, modifiability and, in general, provides for better design decisions. This, in turn, reduces the effort and impact of change and extends the lifetime of the system. In order to guide our research in this area, we need, among other things, to develop a classification of software changes and attributes of changes that identify and isolates those changes that can be traced back to identifiable conditions in the surrounding business context. The rest of the paper is organized in the following way. Chapter II briefly presents previous taxonomies of requirements changes relevant to our research. Chapter III outlines our approach to business process modelling. In chapter IV we discuss the relation between business process modelling and software development. Finally, chapter V describes some preliminary conclusions and outlines further work. II. TAXONOMIES OF REQUIREMENTS CHANGES As changes to systems seem inevitable, both system owners and developers need to be prepared for the situation that a system’s requirements will change. If we can analyze changes and their sources, it would be possible to identify the reason for changes, what types of changes are most likely to occur, what changes involves the highest cost, what types of changes are possible to control, etc. Consequently, we would be able to get a better understanding of future opportunities and threats and, thus minimize the negative impact of changes. In this section we briefly present a limited selection of work previously done on requirements change taxonomies. This research shows that changes can be classified along a number of dimensions. We use the results as a basis for developing a suitable taxonomy in section 4 that can assist in early detection and prevention of high-impact changes. Javed et al. [7] discusses the impact requirements volatility have on software defects, and presents a classification based on the temporal aspects of changes as well as severity of the proposed changes. Here, the time of change refers to changes occurring: 1) in the early phases of development (prefunctional specification changes), 2) in the late phases of development (post-functional specification changes) and 3) after software deployment (post-release changes). Furthermore, the categories “high”, “medium” or low” is used to categorize the severity of changes. It is suggested that type 2 and 3 may have detrimental effects on the development project and on the software quality depending on the level of impact the change requests have on the system. The paper indicates that the time spent on software design as well as communication with the clients, are among the factors that have an effect on the amount of requirements changes occurring during software development. Nurmuliani et al. [8] presents a taxonomy that is used to analyze causes of requirements volatility. The taxonomy presented in this work consists of three parts: 1) type of change,
2) reason of change and 3) origin of change. The change types identified and applied in this context are requirements addition, deletion and modification. The reason of change is a category describing why requirements changes are proposed, for instance error correction, missing or erroneous requirements, design improvement and product enhancement. The last part of the taxonomy relates to from who or where in the organization the proposed changes originate (defect reports, technical team discussion or reviews, marketing, customer feedback, etc.). According to Nurmuliani, there are three main reasons why requirements are changing during development: 1) changes in the market, leading to changed customer needs, 2) developers gain increased understanding and knowledge regarding product domain and 3) changes in business goals and policy. The focus of the work reported by Heales [9], concerns the factors that affect the life span of information systems and is, in this regard, related to software maintenance as well as software development in general. The classification identifies three sets of characteristics that represent different software aspects more or less relevant to the long-term effect they have on an information system’s overall stability. The first set of features reported in this work, the system’s deep structure, is of particular interest as it refers to the fundamental qualities of software architecture. The definition given by IEEE P14712000 [10] states that software architecture is: “. . . the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.” This definition involves not only the structural and contextual aspects of a software system, but also the architecture’s ability to evolve over time. Heales states that a system remains stable (and useful) as long as the system’s deep structure changes in accordance with the changes taking place in the real world it represents. The last two categories of system features in Heales’ taxonomy refer to the surface structure – i.e. the interface between the system’s deep structure and the user – and the physical structure which denotes the particular technology/technologies used to implement the other two sets of features. We complete our brief review of classification schemes for requirements changes by a short presentation of the taxonomy provided by Harker et al. [11]. Their work discusses sources of changes in user and organizational requirements and outlines the change taxonomy shown in table I. To summarize this relatively brief overview of previous work on requirements change taxonomies, we present a set of important change attributes found in this work: • • •
Javed et al.: emphasizes temporal aspects and severity: {early, late, post-release}, {high, medium, low} Nurmuliani et al.: identifies causes of requirements volatility: {type, reason, origin} Heales: focuses on the parts of software that affects its useful life: {deep structures, surface structure, physical
Table I T YPES OF REQUIREMENTS ( ADAPTED FROM H ARKER ET AL . [11] AND S OMMERVILLE [6])
Stable Changing
Type of requirement Enduring Mutable requirements Emergent requirements Consequential requirements
Compatibility requirements
Origins Requirements related to the technical core of the business. Requirements that change because of changes in the business environment. Requirements that surface as the customer’s understanding of the system changes during the system development. Requirements that change after a system has been adopted in the user organization. This may lead to changes in business processes and lead to new opportunities of working which, in turn, stimulates new system requirements. Requirements that depend on the particular systems or business processes within an organization. As these change, the requirements on the system under consideration may also have to evolve.
structure} Harker et al.: identifies general classes of requirements and, indirectly, sources of change in user and organizational requirements In our work we are primarily interested in a taxonomy that can motivate the: • identification of changes that are possible to predict from a set of business models and, to some extent, control when detected • early identification of different types of changes, especially those that are causing undesirable long-term effects on a software system, in particular the software architecture The taxonomies described in this section will be used as a basis for our own classification of change attributes presented in section 4. •
III. B USINESS MODELLING A business model is an abstraction that aims to present a holistic description of how a business functions. It may be based on different points of view and on many levels of detail. Business models may be used for several purposes e.g. strategy or organizational development. We intend to use business modelling as an early stage tool that helps capture changes and in this way develop software systems that fit the customer’s organization and business processes. Our technique is based on Eriksson and Penker’s UMLbased notation [12]. The modelling process itself normally starts with the identification and analysis of business goals, strategies and stakeholders. This is to ensure that the software is aligned with business strategy. Then, the main focus is on
the business processes – starting with high level descriptions, working iteratively towards more detailed process descriptions. The different perspectives associated with the business processes are ownership/responsibility, goals, input, output and the resources required to support the execution of the process. Information resources are of special interest, since these resources could be supplied by one ore more information systems. Dependent on the purpose of the modelling, attributes like time and resource consumption, cost, capacity and knowledge may be associated with the processes. The extent to which formalism is applied may be adjusted according to what is needed in the current situation. Sketches (simple drawings) may be appropriate in the early stages of modelling in order to stimulate the dialogue with participating groups. Later on, more formal semantic content may be associated with symbols and diagrams. If needed, parts of process descriptions may also be formalized such that simulations may be created based on the model. A higher degree of formalization may also be helpful in order to apply tools for consistency checks. A business model may also capture changes along time. During modelling, it may be natural to start with a description of the situation at present time. This may then be used as a basis for modelling a future situation that represents a goal according to some strategy. Based on our experience so far, we find that business modelling suits our purposes in several respects: • • • •
•
it increases the level of user participation the models may be both informal and formal provides models of both present and future situations may also be used in other areas than in software development: e.g. strategy, organizational development/change, process innovation (cost is not only associated with the software development project) may support tools
We now turn to how and why business modelling can improve the early phases of a software development project. IV. B USINESS MODELLING AND SOFTWARE DEVELOPMENT The position taken in this paper is that business modelling is an essential and necessary part of the initial stages of software development and that developing a set of business process models will have desirable effects on long-term qualities on a future software system in terms of robustness and modifiability, as well as the level of requirements volatility. In general, we believe that some of the problems related to missing, incomplete or erroneous requirements can be attributed to an insufficient understanding of the proposed software system’s organizational context – i.e. the business processes supported by the software system. Furthermore, the development of business process models, prior to, or in early phases of development will reduce the number of high-impact changes the system must undergo during its life span. To support our point of view, we discuss our claim with reference to relevant literature as well as our own experiences.
Figure 1.
Components of a socio-technical system
The success of software systems is, in general, dependent on the quality of services it provides to the surrounding organizational context. Before we discuss our point of view, it is important to define precisely what we mean about the terms “software system” and “organizational context”: • The organizational context: the business processes consisting of human actors as well as other (software or hardware) systems requesting information or some form of information processing. • The software system: a custom software product for a particular line of business, commissioned by a customer (i.e. we are not concerned with generic, off –the-shelf software products) As observed by Brier et al. [13], it is necessary to extend the perspective of the requirements engineering task where both the customer stakeholders and the software developers must take into account that the software system is a part of the larger socio-technical system shown in Figure 1. Software development methods that integrate requirements analysis with the organizational and external requirements are crucial in view of the fact that socio-technical systems are a vital part of the organization’s value chain. Earlier work in the field of requirements engineering has shown that insufficient focus on the surrounding business in the early phases of software development more often than not, leads to late requirements changes and project delay [14]–[17]. Business models that visualize business context, goals, processes, rules and information needs, are an important source for capturing software requirements [17]. A typical challenge for the stakeholders in the early stages of development is the uncertainty associated with the possible implications a proposed system will have on the organization in general, and on the business processes in particular [18]. If left unsettled, this can result in unstable or volatile requirements during software development and, in addition, premature design decisions that severely limits the system’s useful life. By modeling how the intended system should support the organization’s business process(es) (a to-be model), the system stakeholders will acquire a better understanding of the implications of various technical decisions. Of particular interest are decisions regarding the system’s deep structure [9], i.e. the software architecture. Decisions regarding architecture
Figure 2. [6]).
Requirements change and architectural decisions (adapted from
represent a considerable risk in any software development project, since they represent technical choices regarding how different types of requirements can be realized [19]. Furthermore, architectural choices have a long-term effect on the structure of the system and are generally very hard to change. High-level architectural design choices are typically made in the early stages of a development project, as shown in Figure 2. At this point in the software’s life cycle, there is a great deal of uncertainty associated with whether or not the initial requirements will provide the business services needed. This is reflected in the figure as the changed understanding of the problem, resulting in the corresponding changes in requirements. As pointed out by Lamsweerde [20], this also illustrates the conflict that exists between requirements volatility and long-term architectural stability. Figure 2 also indicates that the stakeholders, while working on a requirements definition, will acquire a deeper understanding of the problem the software is supposed to solve. Figure 3 illustrates how business modeling reduces problem uncertainty by using the as-is and to-be models as input to the requirements specification. Harker et al. [11] states that dealing with this problem uncertainty usually attracts far less attention in the early stages of software development than solution (technical) uncertainty. The latter form of uncertainty refers to whether or not a particular technical solution will satisfy a set of software requirements, and is not the subject of this paper. Early focus on the alignment of business and software requirements in software development may reduce this inherent problem uncertainty. The “tensions” between problem space and solution space focus is a phenomenon that exists between the customer and the software developer organization. Some of the factors causing this tension are listed in Figure 4. In accordance with the Scandinavian philosophy of user participation [11], there is a need to investigate how we could solve the customer organization’s problems illustrated in Figure 4. One possible way to reduce this tension and empower the users is to involve the customer stakeholders in modelling the organizational context as a multiperspective business model described in chapter III. In the rest of this section we will describe how we can adapt or expand on
Figure 3.
Figure 4.
Reducing the problem uncertainty with business modelling
The tension between problem and solution focus in software development
the previously outlined taxonomies in chapter II to suit our purposes, as well as extensions to the business modelling activities described in chapter III. Following the previous discussion in this section, we intend to propose a possible taxonomy of attributes of changes relevant to our problem. The preliminary change attribute hierarchy is shown in Figure 5. We have underlined the change attributes of particular interest in our study. The change attribute named EPD denotes the earliest possible moment a change could have been anticipated after software project initiation. By examining historical change data from real software projects (primarily logs, and change requests) we hope to identify cases of late change requests with deep structural effects and with an anticipated EPD close to the as-is and to-be stages on the time scale of Figure 3. To be able to use the EPD attribute to predict possible changes after the software system is deployed (i.e., in the software evolution phase) and to indicate which part(s) of the system will be affected by the changes, we propose to extend the as-is and to-be business models to include a “maybe” model. The may-be model is a description of a set of possible future scenarios, normally associated with a relatively high degree of uncertainty concerning trends in the economy, market changes, changes in customer needs, technology, etc. What future trends are relevant for the business under consideration, are described in a business context diagram. The
may-be model will be based on the as-is and to-be model and use techniques like trend analysis and scenario descriptions to project the future. In a similar manner, Harker et al. [18] used scenarios in the requirements generation for future systems. V. C ONCLUSIONS AND FURTHER WORK In this paper, we have presented our approach to early detection of changes of software requirements. We have concentrated our effort on deep, structural changes occurring late in the development process, since these have the most serious implications for issues related to software architecture. Experience shows that these changes are the most undesirable due to the negative effect they have on software projects and the long-term quality of the software itself. We propose to adapt and use business modelling as a tool to enable the system stakeholders to identify and prevent certain types of evolutionary changes earlier in the development process than is usually done with most modern development methods. This will reduce the effort and impact of change and extend the lifetime of the system. We have found sufficient support in the literature to continue our work on using business modelling in early phases to reduce the rate of changes in software development. Most referred works are based on requirement engineering, and do not necessarily give the problem domain as thorough analysis as we would do with business modelling. In addition, most works restrict themselves to changes in the
Figure 5.
A possible taxonomy of change attributes
development phase only, while we are also concerned with changes after deployment. Our work is still in an early stage and will be continued along the following lines. Business modelling will be further adapted both to enhance early detection of likely future changes and to be used as a modelling language and tool for facilitating user involvement. Our method will be applied to real projects. First, we intend to analyze change logs from software development projects in order to test the taxonomy and try to establish whether the reported changes could have been detected earlier. Second, our method will be applied in real development projects with industry partners. R EFERENCES [1] W. W. Royce, “Managing the development of large software systems.,” in Proc. Wescon., pp. 1–9, 1970. [2] K. Beck, “Embracing change with extreme programming„” IEEE Computer., pp. 70–77, 1999. [3] I. Jacobson, G. Booch, and J. Rumbaugh, “The unified process,” IEEE Computer, vol. 16, pp. 96–102, 1999. [4] W. S. Humphrey, Managing the software process. SEI Series in Software Engineering, Addison-Wesley, 1989. [5] J. E. Ecklund, L. Delcambre, and M. Freiling, “Change cases: use cases that identify future requirements,” in Proceedings of the 11th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, ACM Press, 1996. [6] I. Sommerville, Software Engineering. Addison-Wesley, 2007. [7] T. Javed, M. e Maqsood, and Q. Durrani, “A study to investigate the impact of requirements instability on software defects,” SIGSOFT Softw. Eng. Notes, vol. 29(3), pp. 1 – 7, 2004. [8] N. Nurmuliani, D. Zowghi, and S. Fowell, “Analysis of requirements volatility during software development life cycle,” in Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04), IEEE Computer Society, 2004. [9] J. Heales, “Proceedings of the twenty first international conference on information systems,” in Proceedings of the twenty first international conference on Information systems, (Brisbane, Queensland, Australia), Association for Information Systems, 2000. [10] IEEE, “Ieee p1471-2000. recommended practice for architectural description of software-intensive systems,” tech. rep., IEEE, 2000. [11] S. Harker, K. Eason, and J. Dobson, “The change and evolution of requirements as a challenge to the practice of software engineering,” in Proceedings of IEEE International Symposium on Requirements Engineering, (San Diego, CA, USA), pp. 266–272, 1993. [12] H.-E. Eriksson and M. Penker, Business modeling with UML. Business patterns at work. John Wiley & Sons, Inc, 2000. [13] J. Brier, L. Rapanotti, and J. Hall, “Problem-based analysis of organisational change: a real-world example,” in Proceedings of the 2006 international workshop on Advances and applications of problem frames, (Shanghai, China), ACM Press, 2006. [14] A. Blyth, “Modelling the business process to derive organisational requirements for information technology,” SIGOIS Bull., vol. 16(1), pp. 25–33, 1995. [15] C. Ebert, “Understanding the product life cycle: Four key requirements engineering techniques,” IEEE Software, vol. 23(3), pp. 19–25, 2006.
[16] B. Nuseibeh and S. Easterbrook, “Requirements engineering: a roadmap,” in Proceedings of the Conference on The Future of Software Engineering, (Limerick, Ireland), ACM Press, 2000. [17] K. Orr, “Agile requirements: Opportunity or oxymoron?,” IEEE Software, vol. 21(3), pp. 71–73, 2004. [18] S. Harker and K. Eason, “The use of scenarios for organizational requirements generation,” in Proceedings of the Thirty-Second Annual Hawaii International Conference on System Sciences-Volume 3 - Volume 3, vol. 3, IEEE Computer Society, 1999. [19] R. Kazman, G. Abowd, L. Bass, and P. Clements, “Scenario-based analysis of software architecture,” IEEE Software, vol. 13(6), pp. 47–55, 1996. [20] A. van Lamsweerde, “Requirements engineering in the year 00: a research perspective,” in Proceedings of the 22nd international conference on Software engineering, (Limerick, Ireland), ACM Press, 2000.
