Next Article in Journal
Biospeckle Activity of Highbush Blueberry Fruits Infested by Spotted Wing Drosophila (Drosophila suzukii Matsumura)
Previous Article in Journal
The Structure of T-DNA Insertions in Transgenic Tobacco Plants Producing Bovine Interferon-Gamma
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Identifying Key Characteristics of Business Rules That Affect Software Project Success

1
Faculty of Computer and Information Science, University of Ljubljana, Večna pot 113, SI-1000 Ljubljana, Slovenia
2
Department of Information Systems, Vilnius Gediminas Technical University, Sauletekio al. 11, LT-10223 Vilnius, Lithuania
3
Institute of Applied Computer Science, Vilnius Gediminas Technical University, Sauletekio al. 11, LT-10223 Vilnius, Lithuania
*
Author to whom correspondence should be addressed.
Appl. Sci. 2022, 12(2), 762; https://doi.org/10.3390/app12020762
Submission received: 8 December 2021 / Revised: 5 January 2022 / Accepted: 7 January 2022 / Published: 12 January 2022

Abstract

:
Today, businesses need to continuously adjust to a dynamic environment. Enterprises have to deal with global competition and technological advances, meet government regulations, and keep their expenses under control. Under these pressures, enterprises need to implement and improve software that supports and helps to evolve their business. However, as practice shows, software implementation projects are complex, and a considerable percentage of them do not meet business requirements. Therefore, a business needs to manage software implementation properly. Existing research shows that using business rules (BR) in software implementation projects helps to ensure its success. The purpose of our study is to advance the understanding of how BR affect software implementation success, namely, which key characteristics of BR are the most important. To achieve this goal, the top thousand enterprises in Slovenia, by added value, facing typical software implementation projects were surveyed. The obtained results show that BR that are specifically prepared for a particular project and easy to understand have a statistically significant positive effect on software implementation project success.

1. Introduction

1.1. Problem Statement

A business rule (BR) approach is widely accepted in the software development community as a way to express different types of business restrictions and constrain components of software [1,2]. We can understand BR as a constraint that defines what must or must not be the case. The BR has to be true in a logical sense; otherwise, it has to be corrected. In this paper, the authors examine how BR affect the success of software implementation projects.
The impact of BR on enterprise software implementation project success has been argued in several software disciplines, such as requirements specification [3,4,5,6], software quality assurance [7], software evolution [8], business modelling [9,10], etc. Moreover, Lal [4] claims that BR are relevant to the entire software project life cycle.
The theory emphasizes that BR need to be well defined [5,11], consistent [12], and written [12,13] to positively affect software implementation project success. The Standish Group found that when an application team focuses on BR rather than technology, it can reduce the time and resources needed to integrate applications [13]. Moreover, the usage of the Business Rule Management System (BMRS) is beneficial for efficiently validating software execution data in software development [7].
There are only a few empirical studies that have examined which key characteristics of BR importantly affect software implementation project success. Moreover, existing surveys are concentrating on business rules (i.e., taxonomy of BR organizing approaches regarding business process compliance [14], factors affecting the business process and BR integration [15], dynamically stable business processes operation [16], modeling context for BR management [17], etc.) or on software project success (such as soft skills for IT project success [18], scope creep factors and their impact on software project success [19], agile software project success [20], transparent task allocation [21], etc.), but there are no studies on the conjunction of those two topics. Therefore, there is a significant gap in knowledge about which key characteristics of BR affect software implementation project success. This gap can be explained by the difficulties in conducting empirical quantitative research. However, the existing studies on software project success (presented above) show that it is an important issue that merits further investigation.
The limitation of the previous studies is that those studies have not empirically analyzed BR impact on project success. This is the novelty proposed in this study.

1.2. Aim and Scope of the Current Study

To help close this research gap, we have developed a questionnaire of six questions to examine which key characteristics of BR affect software implementation project success. We started by reviewing the related work, where we identified six BR characteristics that affect software implementation project success. Those characteristics were formulated in the form of six questions, which we validated with a focus group of Lithuanian and Slovenian experts. Next, we applied an empirical survey to identify the key characteristics of BR, which significantly affect software implementation project success.
The study aims to determine the key characteristics of BR which affect software implementation project success in practice, thus our literature review focuses on identifying these BR characteristics.
To address this problem, we examine the following six research questions (RQ):
RQ1: Is the software implementation project success positively impacted when all business rules are in written form?
RQ2: Is the software implementation project success positively impacted when all business rules are specifically prepared for the project?
RQ3: Is the software implementation project success positively impacted when all business rules are consistent?
RQ4: Is the software implementation project success positively impacted when all business rules are easy to understand?
RQ5: Is the software implementation project success positively impacted when all business rules are well-defined?
RQ6: Is the software implementation project success positively impacted when all business rules are traceable from the business level to the implementation level?
This study contributes to BR research by identifying the key characteristics of BR that affect software implementation project success and by studying the current practices of using BR in software implementation projects. Moreover, as was mentioned previously, our study addresses the lack of knowledge about key characteristics of BR that affect software implementation project success.
The study is intended to support researchers and practitioners working on software implementation projects. The practical benefit of the paper is that researchers and practitioners can become familiar with the identified key characteristics of BR and can apply them to increase the success of software implementation projects. Besides, a direction is opened for further research in using identified key characteristics of BR to increase software implementation project success.
The remainder of the paper is structured as follows: Section 2 presents the related work. Section 3 explains the research method used. Section 4 presents the results of the study. Section 5 discusses the results in the context of existing studies. Section 6 concludes the paper.

2. Related Works Review

Several authors highlight the significance of BR usage in business and business supporting systems development and evolution. L’Erario et al. [22] note that BR are often the core of software development. Their understanding by the developer and the customer’s ability to relate to them is the starting point of a successful software project. Abe et al. [23] proposed portfolio-optimization techniques for selecting optimal business transformation based on resource constraints, budget constraints, and other BR. They have proposed a set of success metrics that business executives can use to evaluate large IT projects. The importance of BR in software projects can also be seen through BR standards, such as the Semantics of Business Vocabulary and Rules (SBVR, https://www.omg.org/spec/SBVR/ (accessed on 6 December 2021)), Production Rule Representation (PRR, https://www.omg.org/spec/PRR/ (accessed on 6 December 2021)), etc., and rule-centric management tools and application development support environments, such as the IBM Operational Decision Manager (ODM) (https://www.ibm.com/products/operational-decision-manager (accessed on 6 December 2021)), Drools (https://drools.org/ (accessed on 6 December 2021)), IBM WebSphere ILOG JRules (https://www.ibm.com/docs/en/iis/11.5?topic=applications-websphere-ilog-jrules (accessed on 6 December 2021)), CA Aion Business Rules Expert (http://www.lookupmainframesoftware.com/soft_detail/dispsoft/529 (accessed on 6 December 2021)), Usoft Developer (https://developer.usoft.com/ (accessed on 6 December 2021)), Visual Rule Studio (https://visual-rule-studio.software.informer.com/1.0/ (accessed on 6 December 2021)), Integrated Business Rule Engine (https://www.axonivy.com/business-rule-engine (accessed on 6 December 2021)), etc. Influence of BR on project delivery was examined by a number of authors as follows. Kardasis et al. [24] provide a repository schema for managing BR to assist the transition from analysis to design and implementation of the information system. Lal et al. [4] note that BR with scenarios are relevant in all IT projects, especially: (1) in the requirements analysis phase—for specifying requirements in the form of BR and scenarios; (2) in the solution design phase—for solution design by expanding BR and scenarios; (3) in the application design phase—for ensuring that the detailed BR and scenarios are considered while designing, and (4) in the test design phase—for creating test cases.
We conclude the related work analysis with the theoretical backgrounds of RQ presented in Table 1.
As can be seen from Table 1, in the analyzed articles authors emphasize only a particular characteristic of BR that affect software implementation project success, but not the set of characteristics. Therefore, there is a need for a more detailed study to identify key characteristics of BR that affect software implementation project success.

3. Materials and Methods

Our study was performed in the seven key steps as shown in Figure 1.
In the first step (1), we reviewed existing literature in the field of BR to define the hypothesis and the six research questions presented in the introduction and Table 1. As was mentioned in the introduction section, since the main focus of this study is a practical perspective, but not a summarization of the analyzed topic in the literature, a systematic literature review was not performed here. We have applied a narrative review, which is towards a qualitative interpretation of prior knowledge [34,35]. It attempts to summarize or synthesize what has been written on a particular topic, but does not seek generalization or cumulative knowledge from what is reviewed [36,37].
The review of the BR field was based on a systematic search in Web of Science (Clarivate Analytics) and Google Scholar for articles published between 2008 and 2021 on which key characteristics of BR importantly affect software implementation project success, using as keywords as follows: “business rule”, “project success”, “software development”, “software project”, “IT project”, “software development success”. Articles dealing with software project success and business rules that were most relevant for our research were considered. Their insights formed the basis for the identification of the key BR characteristics that significantly affect software implementation project success.
The analysis results of the found articles, the questions, and the possible answers to the six defined research questions (RQ) are presented in Table 1. The RQ were validated and approved by a focus group of Lithuanian and Slovenian experts.
In the second step (2), the questionnaire was developed, which measures Chief Information Officers’ (CIOs’) perceptions regarding the research questions and the net benefits of software implementation projects. The net benefits of software implementation projects were defined following DeLone-Mclean model of IS success [38]. All items use seven-point Likert scales ranging from 1 (strongly disagree) to 7 (strongly agree).
In the third step (3), we conducted a survey. We focused on the top 1000 enterprises in Slovenia by generated added value [39]. The importance of these enterprises for the national economy makes them a relevant study group. As IT is a key strategic technology for most of these enterprises, they face typical problems in software implementation project management. The surveys were distributed to the CIOs of the 1000 enterprises by mail. The response rate was 11.2% (n = 112). Such response rates are typical for mail surveys conducted in enterprises (not only in Slovenia) [40]. Existing research demonstrated that even with response rates of around 10%, we can treat such a sample as a random sample [41,42]. The participants were asked to relate to a recently concluded important software implementation project they had been involved in regardless of its success.
In the fourth step (4), we examined the distribution of all variables that we included in the study. Skewness and kurtosis of all examined variables did not exceed the ranges that would violate the assumptions about the normal distribution of the variables [43,44].
Therefore, in the fifth step (5), we were able to perform an independent sample t-test [44,45].
Before using a t-test, we split the sample into three groups based on the software implementation project overall success. The first group represents enterprises that evaluated themselves as having below-average software implementation project success (Likert values of net benefits of software implementation projects 1 to 4) i.e., low performers (scale n = 26), the second group represents enterprises with average software implementation project success (Likert value of net benefits of software implementation projects 5) (n = 38), while the third group represents enterprises with above-average software implementation project success (Likert values of net benefits of software implementation projects 6 to 7) i.e., high performers (n = 48). Using a t-test, we compared differences in BR research questions between the high and the low performing group.
In the sixth step (6), we analyzed the results as presented in Section 5, and finally (7) we interpret the results in the context of existing studies as presented in Section 6.

4. Results

The main results are presented in Table 2 and Table 3. Table 2 consists of six columns, where the first column denotes research questions for which the following columns were computed. The second column specifies whether the analysis is related to low or high performing projects group. The third, fourth fifth, and sixth columns specify the number of responses of each group (N), mean of each group, standard deviation of each group, and standard error of the mean of each group, respectively.
Table 3 consists of seven columns, where the first column denotes research questions for which the independent sample t-test was computed. The second and third columns present Levene’s Test for Equality of Variances showing F-value (F) and significance (Sig.) for each RQ. The fourth, fifth, and sixth columns show t-test for Equality of Means results for each RQ, namely t-value (t), degrees of freedom (df) and significance (Sig.). The seventh column shows the effect size of the difference between two independent samples (Cohen’s delta).
We compared low and high performing project groups to determine which BR characteristics (RQ1–RQ6) statistically significantly affect software implementation project success (see Table 2 and Table 3 and Figure 2). The independent t-test gave us two statistically significant results. First, the second research question (RQ2), which examines if the software implementation project success is positively impacted when all business rules are specifically prepared for the project, was confirmed as having statistically significantly better responses for the group of high performers than the group of low performers. Second, the fourth research question (RQ4), which examines if the software implementation project success is positively impacted when all business rules are easy to understand, was confirmed as having statistically significantly better responses for the group of high performers than the group of low performers. Both research questions also have a medium effect size (higher than 0.5) [46]. Finally, the remaining four research questions (RQ1: Is the software implementation project success positively impacted when all business rules are in the written form?; RQ3: Is the software implementation project success positively impacted when all business rules are consistent?; RQ5: Is the software implementation project success positively impacted when all business rules are well-defined?; RQ6: Is the software implementation project success positively impacted when all business rules are traceable from the business level to implementation level?) did not prove to be statistically significant. However, in all four questions, the project implementation success means of the high performers’ group were higher than of the low performers’ group.

5. Discussion

As can be seen from the obtained results (see Table 2 and Table 3), research questions RQ2 (i.e., a set of rules specifically prepared for a particular project positively affects the software implementation project success) and RQ4 (i.e., ease of understanding of BR positively affects the software implementation project success) have a statistically significant effect.
The necessity to define a BR set specifically for a particular project (RQ2) originates from the fact that projects vary in size, price, number of developers, complexity, number of development teams [47], and other unique characteristics [48]. The definition of BR and especially business terms must be understandable to business users (e.g., using SBVR [9,25]) and developers (e.g., platform-specific BR, like Ilog, Bonita, etc.). BR should be specifically prepared for a particular project [4,12].
One of the main causes of software implementation project failure [49] are poorly defined requirements, which also include poorly defined BR for the project. Consequently, we should improve understanding of BR (RQ4) by standardizing their content and form e.g., a shared rule set facilitates successful work [12]. Based on this finding, the more general BR in the form of good practices can be developed [50,51]. Moreover, standardization helps users and software developers to build a shared understanding of business terms and BR, which facilitates successful and efficient SW implementation [52,53].
Other research questions (RQ1 (i.e., defining BR in written form positively affect the software implementation project success), RQ3 (i.e., consistency of BR positively affect the software implementation project success), RQ5 (i.e., proper definition of BR positively affect the software implementation project success) and RQ6 (i.e., traceability of BR from business level to implementation level positively affect the software implementation project success)), according to the obtained results, are not statistically significant. Although the literature review presented in the related works shows that those questions are important [9,12,29], our study did not find statistically significant influences of these BR characteristics on software implementation project success.

Threats to Validity and Limitations of the Study

Threats to construct validity were addressed by a rigorous literature review. Threats to external and internal validity were addressed by sending the survey to the 1000 biggest enterprises in Slovenia [39], thus we had no impact on group composition and the group composition is representative for software implementation projects in Slovenia. We addressed threats to statistical conclusion validity by using appropriate statistical techniques as follows. An independent sample t-test was used, as it is an appropriate statistical technique for normally distributed data. Additionally, we computed effect sizes for our research questions to ensure that our research questions do not lack sufficient power and represent non-trivial effects.
Nevertheless, some limitations of these findings need to be considered. First, the fact that respondents already knew the outcome of their project when answering the survey may have caused response bias. Following the approach of similar studies [47], we surveyed mainly objective information related to project characteristics. Second, the limitation is also a relatively low response rate. Such response rates are typical for mail surveys conducted in enterprises and still allow researchers to treat the sample as a random sample [41,42]. Third, the study was conducted in a specific cultural and business environment. Fourth, we did not conduct exploratory research to identify key BR characteristics, but included only the ones already present in the literature. Fifth, the research was conducted on software implementation projects. Sixth, the survey was conducted in IT departments of 1000 biggest enterprises in Slovenia, which generally conduct software development and implementation with professional IT partners, thus our sample is not representative of development approaches conducted by people without thorough knowledge in computer science and scarce skills in programming.

6. Conclusions

According to the results of our study, research questions RQ2 (i.e., the software implementation project success is positively impacted when all business rules are specifically prepared for the project?) and RQ4 (i.e., the software implementation project success is positively impacted when all business rules are easy to understand) have a statistically significant impact on software implementation project success. Thus, we can conclude that these BR characteristics importantly contribute to software implementation project success. According to the obtained results, research questions RQ1, RQ3, RQ5, and RQ6 do not statistically significantly contribute to software implementation project success.
Hence, we can conclude that enterprises on one hand should prepare a set of BRs that are directly tailored to each specific project, and, on the other hand, they should assure that BR and vocabulary are easy to understand for all project participants. This answers the main RQ about which key characteristics of BR importantly affect SW project success.
Future work should focus on testing if the impact of the studied characteristics of BR on software implementation project success replicates in different cultural and business environments. Additionally, exploratory research should be conducted to identify other BR characteristics that may have not to be present in the literature, but might have an important impact.

Author Contributions

Conceptualization, D.V., T.H., O.V. and D.K.; methodology, T.H and D.V.; validation, O.V. and D.K.; formal analysis, T.H., D.V., O.V. and D.K.; investigation, O.V., D.K., D.V. and T.H.; data curation, D.V. and T.H.; writing—original draft preparation, D.V., T.H., D.K. and O.V.; writing—review and editing, D.V., T.H., D.K. and O.V.; visualization, D.V.; supervision, T.H.; funding acquisition, D.V. All authors have read and agreed to the published version of the manuscript.

Funding

This work was supported by Slovenian Research Agency [Grant Number P2-0359]. The funding source had no role in study design; in the collection, analysis, and interpretation of data; in the writing of the report; and in the decision to submit the article for publication.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The data presented in this study are available on request from the corresponding author.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Kalibatiene, D.; Vasilecas, O. Ontology axioms for the implementation of business rules. Technol. Econ. Dev. Econ. 2010, 16, 471–486. [Google Scholar] [CrossRef]
  2. Morgan, T. Business Rules and Information Systems: Aligning IT with Business Goals; Addison-Wesley Professional: Boston, MA, USA, 2002; ISBN 0201743914. [Google Scholar]
  3. Alves, C.; Valença, G.; Fraga, G. Integrating requirements and business process models in BPM projects. In Proceedings of the 44th Euromicro Conference on Software Engineering and Advanced Applications, SEAA, Prague, Czech Republic, 29–31 August 2018; pp. 273–280. [Google Scholar]
  4. Lal, M.K. Knowledge Driven Development: Bridging Waterfall and Agile Methodologies; Cambridge University Press: Cambridge, UK, 2018; ISBN 9781108475211. [Google Scholar]
  5. Kassab, M. The changing landscape of requirements engineering practices over the past decade. In Proceedings of the 5th International Workshop on Empirical Requirements Engineering, EmpiRE 2015—Proceedings, Ottawa, ON, Canada, 24 August 2015; pp. 1–8. [Google Scholar]
  6. Brad, E.; Brad, S. Requirements Analysis in Disruptive Engineering Solutions Using the Paradigm of Living Systems. Appl. Sci. 2021, 11, 9854. [Google Scholar] [CrossRef]
  7. Zawistowski, P. The method of measurement and control systems design and validation with use of BRMS systems. In Proceedings of the 2016 IEEE Symposium on Service-Oriented System Engineering, SOSE 2016, Oxford, UK, 29 March–2 April 2016; pp. 324–332. [Google Scholar]
  8. Mumtaz, H.; Alshayeb, M.; Mahmood, S.; Niazi, M. A survey on UML model smells detection techniques for software refactoring. J. Softw. Evol. Process 2019, 31, 2154. [Google Scholar] [CrossRef]
  9. Valente, P.; Silva, T.; Winckler, M.; Nunes, N. The goals approach: Enterprise model-driven agile human-centered software engineering. In Human-Centered and Error-Resilient Systems Development; Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); Springer: Berlin/Heidelberg, Germany, 2016; Volume 9856 LNCS, pp. 261–280. [Google Scholar]
  10. Valente, P.; Silva, T.; Winckler, M.; Nunes, N. Bridging enterprise and software engineering through an user-centered design perspective. In Web Information Systems Engineering—WISE 2016; Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); Springer: Berlin/Heidelberg, Germany, 2016; Volume 10042 LNCS, pp. 349–357. [Google Scholar]
  11. Ambler, S.W. Agile Requirements Changement Management. Available online: http://agilemodeling.com/essays/changeManagement.htm (accessed on 25 October 2021).
  12. Johanssen, J.O.; Kleebaum, A.; Paech, B.; Bruegge, B. Continuous software engineering and its support by usage and decision knowledge: An interview study with practitioners. J. Softw. Evol. Process 2019, 31, e2169. [Google Scholar] [CrossRef]
  13. Tarawneh, M.M.I.; Al-Tarawneh, H.; Elsheikh, A. Software development projects: An investigation into the factors that affect software project success/failure in Jordanian firms. In Proceedings of the 1st International Conference on the Applications of Digital Information and Web Technologies, ICADIWT 2008, Ostrava, Czech Republic, 4–6 August 2008; pp. 246–251. [Google Scholar]
  14. Corea, C.; Delfmann, P. A Taxonomy of Business Rule Organizing Approaches in Regard to Business Process Compliance. Enterp. Model. Inf. Syst. Archit. 2020, 15, 1–27. [Google Scholar] [CrossRef]
  15. Wang, W. Identification of factors affecting business process and business rule integration. In Lecture Notes in Business Information Processing; Springer: Berlin/Heidelberg, Germany, 2019; Volume 343, pp. 60–72. [Google Scholar]
  16. Guerreiro, S. Conceptualizing on dynamically stable business processes operation: A literature review on existing concepts. Bus. Process Manag. J. 2021, 27, 24–54. [Google Scholar] [CrossRef]
  17. Burgstaller, F.; Steiner, D.; Schrefl, M. Modeling Context for Business Rule Management. In Proceedings of the CBI 2016: 18th IEEE Conference on Business Informatics, Paris, France, 29 August–1 September 2016; Volume 1, pp. 262–271. [Google Scholar]
  18. Iriarte, C.; Bayona Orè, S. Soft Skills for IT project success: A systematic literature review. In Advances in Intelligent Systems and Computing; Springer: Berlin/Heidelberg, Germany, 2018; Volume 688, pp. 147–158. [Google Scholar]
  19. Komal, B.; Janjua, U.; Anwar, F.; Madni, T.M.; Cheema, M.F.; Malik, M.N.; Shahid, A.R. The impact of scope creep on project success: An empirical investigation. IEEE Access 2020, 8, 125755–125775. [Google Scholar] [CrossRef]
  20. Kandengwa, E.; Khoza, L.T. Measuring Agile software project success beyond the triple constraint. S. Afr. J. Inf. Manag. 2021, 23, 1–8. [Google Scholar] [CrossRef]
  21. Gupta, C.; Gupta, V. A Decentralized Framework for Managing Task Allocation in Distributed Software Engineering. Appl. Sci. 2021, 11, 10633. [Google Scholar] [CrossRef]
  22. L’Erario, A.; Thomazinho, H.C.S.; Fabri, J.A. An Approach to Software Maintenance: A Case Study in Small and Medium-Sized Businesses IT Organizations. Int. J. Softw. Eng. Knowl. Eng. 2020, 30, 603–630. [Google Scholar] [CrossRef]
  23. Abe, N.; Akkiraju, R.; Buckley, S.; Ettl, M.; Huang, P.; Subramanian, D.; Tipu, F. On optimizing the selection of business transformation projects. IBM Syst. J. 2007, 46, 777–795. [Google Scholar] [CrossRef]
  24. Kardasis, P.; Loucopoulos, P. Expressing and organising business rules. Inf. Softw. Technol. 2004, 46, 701–718. [Google Scholar] [CrossRef]
  25. Mickeviciute, E.; Butleris, R.; Gudas, S.; Karciauskas, E. Transforming BPMN 2.0 business process model into SBVR business vocabulary and rules. Inf. Technol. Control 2017, 46, 360–371. [Google Scholar] [CrossRef] [Green Version]
  26. Normantas, K.; Vasilecas, O. A Systematic Review of Methods for Business Knowledge Extraction from Existing Software Systems. Balt. J. Mod. Comput. 2013, 1, 29–51. [Google Scholar]
  27. Nelson, M.L.; Peterson, J.; Rariden, R.L.; Sen, R. Transitioning to a business rule management service model: Case studies from the property and casualty insurance industry. Inf. Manag. 2010, 47, 30–41. [Google Scholar] [CrossRef]
  28. Valente, P.; Silva, T.; Winckler, M.; Nunes, N. The goals approach: Agile enterprise driven software development. Lect. Notes Inf. Syst. Organ. 2017, 22, 201–219. [Google Scholar] [CrossRef] [Green Version]
  29. Rai, A.; Sambamurthy, V.; Agarwal, R. How CIOs Can Enable Governance of Value Nets. MIS Q. Exec. 2008, 7, 193–204. [Google Scholar]
  30. Wang, W.; Indulska, M.; Sadiq, S. Guidelines for Business Rule Modeling Decisions. J. Comput. Inf. Syst. 2018, 58, 363–373. [Google Scholar] [CrossRef]
  31. Wheatcraft, L.S.; Ryan, M.J.; Dick, J. On the Use of Attributes to Manage Requirements. Syst. Eng. 2016, 19, 448–458. [Google Scholar] [CrossRef]
  32. Boyer, J.; Mili, H. Agile Business Rule Development. In Agile Business Rule Development; Springer: Berlin/Heidelberg, Germany, 2011; pp. 49–71. [Google Scholar]
  33. Bajec, M.; Krisper, M. A methodology and tool support for managing business rules in organisations. Inf. Syst. 2005, 30, 423–443. [Google Scholar] [CrossRef]
  34. Sylvester, A.; Tate, M.; Johnstone, D. Beyond synthesis: Re-presenting heterogeneous research literature. Behav. Inf. Technol. 2013, 32, 1199–1215. [Google Scholar] [CrossRef]
  35. Lau, F.; Kuziemsky, C. Handbook of eHealth Evaluation: An Evidence-based Approach; University of Victoria: Victoria, BC, Canada, 2016; ISBN 9781550586015. [Google Scholar]
  36. Davies, P. The Relevance of Systematic Reviews to Educational Policy and Practice. Oxf. Rev. Educ. 2000, 26, 365–378. [Google Scholar] [CrossRef]
  37. Green, B.N.; Johnson, C.D.; Adams, A. Writing narrative literature reviews for peer-reviewed journals: Secrets of the trade. J. Chiropr. Med. 2006, 5, 101–117. [Google Scholar] [CrossRef] [Green Version]
  38. Urbach, N.; Müller, B. The Updated DeLone and McLean Model of Information Systems Success. In Information Systems Theory; Springer: New York, NY, USA, 2012; pp. 1–18. [Google Scholar]
  39. AJPES. Agency of the Republic of Slovenia for Public Legal Records and Related Services. Available online: https://www.ajpes.si/?language=english (accessed on 5 January 2022).
  40. Vavpotič, D.; Robnik-Šikonja, M.; Hovelja, T. Exploring the Relations Between Net Benefits of IT Projects and CIOs’ Perception of Quality of Software Development Disciplines. Bus. Inf. Syst. Eng. 2020, 62, 347–360. [Google Scholar] [CrossRef] [Green Version]
  41. Hovelja, T. Organisational Effects on Information Technology Productivity in Enterprises: The Case of Slovenia. Econ. Bus. Rev. 2008, 10, 243–261. [Google Scholar]
  42. Hovelja, T.; Rožanec, A.; Rupnik, R. Measuring the success of the strategic information systems planning in enterprises in Slovenia. Manag. J. Contemp. Manag. Issues 2010, 15, 25–46. [Google Scholar]
  43. Leech, N.; Barrett, K.; Morgan, G.A. SPSS for Intermediate Statistics; Routledge: London, UK, 2013. [Google Scholar]
  44. Ozgur, C.; Strasser, S.E. A Study of the Statistical Inference Criteria: Can We Agree on When to use Z Versus t? Decis. Sci. J. Innov. Educ. 2004, 2, 177–192. [Google Scholar] [CrossRef]
  45. Rasch, D.; Verdooren, R.; Pilz, J. Applied Statistics: Theory and Problem Solutions with R; John Wiley & Sons: Hoboken, NJ, USA, 2019; ISBN 9781119551584. [Google Scholar]
  46. Cohen, J. Statistical Power Analysis for the Behavioral Sciences; Academic Press: New York, NY, USA, 2013. [Google Scholar]
  47. Jørgensen, M. Do agile methods work for large software projects? In Lecture Notes in Business Information Processing; Springer: Berlin/Heidelberg, Germany, 2018; Volume 314, pp. 179–190. [Google Scholar]
  48. Ahimbisibwe, A.; Daellenbach, U.; Cavana, R.Y. Empirical comparison of traditional plan-based and agile methodologies: Critical success factors for outsourced software development projects from vendors’ perspective. J. Enterp. Inf. Manag. 2017, 30, 400–453. [Google Scholar] [CrossRef]
  49. The Standish Group. CHAOS Report 2015. Available online: https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf (accessed on 29 November 2021).
  50. Huijgens, H.; Van Solingen, R.; Van Deursen, A. How to build a good practice software project portfolio? In Proceedings of the 36th International Conference on Software Engineering, ICSE Companion 2014, New York, NY, USA, 31 May–7 June 2014; Association for Computing Machinery: New York, NY, USA, 2014; pp. 64–73. [Google Scholar]
  51. Oyedeji, S.; Penzenstadler, B. Karlskrona Manifesto: Software Requirement Engineering Good Practices; CEUR Workshop: Aachen, Germany, 2018; Volume 2223, pp. 15–23. [Google Scholar]
  52. Vasilecas, O.; Kalibatiene, D.; Guizzardi, G. Towards a formal method for the transformation of ontology axioms to application domain rules. Inf. Technol. Control 2009, 38, 271–282. [Google Scholar]
  53. Trinkunas, J.; Vasilecas, O. A graph oriented model for ontology transformation into conceptual data model. Inf. Technol. Control 2007, 36, 126–132. [Google Scholar]
Figure 1. The key steps of our study.
Figure 1. The key steps of our study.
Applsci 12 00762 g001
Figure 2. Graphical representation of mean differences of studied groups for each research question.
Figure 2. Graphical representation of mean differences of studied groups for each research question.
Applsci 12 00762 g002
Table 1. Research questions and their theoretical background.
Table 1. Research questions and their theoretical background.
Research QuestionTheoretical Background for RQ
RQ1Authors found that BR defined in a written form significantly positively affect software implementation projects success since creating an SBVR model before the software implementation stage facilitates software development, maintenance and evolution [25,26], and helps in the assistance of business [27].
RQ2Authors [4,9,10,28] found that BR specifically prepared for the project positively affect software implementation project success because they can help in specifying requirements, software design, software architecture and creating test cases.
RQ3Authors [12] found that consistent BR positively affect software implementation project success since consistent BR promotes coordination [29].
RQ4Authors [4,9,10,28] found that easy-to-understand BR positively affects software implementation project success since such BR are typically easier to reuse, have a lighter impact on business model complexity, and are easier to modify [30]. According to L’Erario et al. [22], business rules are often the core of software development, thus the developer’s understanding of business rules and the customer’s ability to relate to them is the starting point of a successful software project.
RQ5Well-defined BR are among key best practices for successful software implementation projects according to Kassab [5] and Ambler [11]. Wheatcraft et al. [31] consider BR as a specific type of requirements, which should be well-defined, since they have to be understood similarly by a wide range of different stakeholders in activities such as programming, planning, maintenance, developing test plans, etc. Johanssen et al. [12] consider well-defined shared rulesets as very important for software engineering. Boyer and Mili [32], and emphasize the importance of well-defined BR that make
sense and do not have logical conflicts. Consequently, according to the analyzed articles, well-defined BR positively affect software implementation projects success.
RQ6Authors [9,10] found that ensuring traceability of BR from business level to implementation level positively affects software implementation project success because traceability ensures an explicit link between each business rule in the BR model and its implementations in one or several application systems. If such a link is established, then it is much easier to maintain IS [33]. To ensure project success organizations need a way of ensuring traceability between BR descriptions and the actual implementations of the BR [32].
Table 2. Group statistics according to RQ.
Table 2. Group statistics according to RQ.
Research QuestionProject Implementation SuccessNMeanStd. DeviationStd. Error Mean
RQ1Low performing projects264.651.4680.288
High performing projects484.901.5330.221
RQ2Low performing projects263.081.4680.288
High performing projects484.001.7010.246
RQ3Low performing projects264.461.2720.249
High performing projects484.751.3760.199
RQ4Low performing projects264.581.3620.267
High performing projects485.231.2420.179
RQ5Low performing projects264.731.2510.245
High performing projects485.131.3780.199
RQ6Low performing projects254.361.4690.294
High performing projects484.791.3830.200
Table 3. t-test analysis.
Table 3. t-test analysis.
Research QuestionLevene’s Test for Equality of Variancest-Test for Equality of MeansEffect Size
FSig.tdfSig. (2-Tailed)Cohen’s Delta
RQ10.0350.852−0.658720.5130.165
RQ20.6480.423−2.335720.0220.567
RQ30.9710.328−0.883720.3800.216
RQ40.1200.730−2.085720.0410.506
RQ51.6710.200−1.213720.2290.300
RQ60.0340.854−1.239710.2190.304
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Vavpotič, D.; Kalibatiene, D.; Vasilecas, O.; Hovelja, T. Identifying Key Characteristics of Business Rules That Affect Software Project Success. Appl. Sci. 2022, 12, 762. https://doi.org/10.3390/app12020762

AMA Style

Vavpotič D, Kalibatiene D, Vasilecas O, Hovelja T. Identifying Key Characteristics of Business Rules That Affect Software Project Success. Applied Sciences. 2022; 12(2):762. https://doi.org/10.3390/app12020762

Chicago/Turabian Style

Vavpotič, Damjan, Diana Kalibatiene, Olegas Vasilecas, and Tomaž Hovelja. 2022. "Identifying Key Characteristics of Business Rules That Affect Software Project Success" Applied Sciences 12, no. 2: 762. https://doi.org/10.3390/app12020762

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop