The structural features of a code section that may indicate a more serious issue with the design of a system or code are known as code smells. Design patterns, on the other hand, are meant to describe the best reusable solution for creating object‐oriented software systems. Even though design patterns and code smells are very different, they may co‐occur. In fact, there may be a significant connection among the two, which requires further research. This study aims to (i) identify design patterns and code smells in web gaming code, (ii) investigate the co‐occurrence of the two, and (iii) analyze the effects of these co‐occurrences on internal quality aspects of code. An experiment is carried out on JavaScript (JS) web games utilizing machine learning classifiers to investigate the influence of co‐occurrence on potential code smells and design patterns to evaluate games from a quality perspective. Moreover, statistical testing is performed to identify the impact of co‐occurrences of code smells and design patterns on internal quality attributes. After examining the data, we determined that random forest is the most effective classifier, achieving an accuracy of 99.126% and 98.99% for both experimental situations, respectively. Moreover, on applying the Wilcoxon signed rank test, we found that co‐occurrence has no impact on the coupling and complexity of web games codes, whereas there is a significant impact of co‐occurrence on cohesion, size, and inheritance. Our results may guide developers in writing efficient games code to add to this swiftly growing market.

Conceptual models offer numerous benefits but require significant investments, requiring modelers to strive to balance costs and benefits. Understanding the modeling process and the frustrations experienced by modelers can provide valuable insights for this assessment. While research acknowledges certain instances of modelers’ dissatisfaction, its scope often limits detailed examination. This study seeks to identify and analyze the main pain points associated with domain modeling through a five-phase empirical study using a multi-method approach. We identified 71 pain points, synthesized them to 41 , and prioritized 16 as the most significant and prevalent in domain modeling. We then refined, documented, and exemplified the prioritized pain points, analyzed their potential causes, and discussed their practical implications. Our findings provide valuable insights for improving modelers’ experiences and optimizing the modeling process. • 41 pain points in structural conceptual modeling were mapped. • 16 pain points were identified as the most significant and prevalent. • Pain points may stem from a lack of experience among modelers and stakeholders. • Pain points may arise from issues with modeling methods, tools, and languages. • Pain points may arise from factors related to the organization, domain, and project.

The increasing success and user satisfaction of agile methods’ application in their original context (eg small co-located teams), motivated large organizations to utilize agile methods to deal with the rapidly changing markets and the distributed global workforce. Several studies have reported a variety of quality requirements (QRs) challenges in large-scale distributed agile (LSDA) context, so a recent empirical study has identified 15 QRs challenges in LSDA projects. This paper proposes an approach based on the concept of goal documentation to deal with the 15 QRs challenges reported previously. Our proposal, the Agile Quality Requirements Elaboration (AQRE) approach, introduces a new organizational role and a two-step process to elaborate high-level goals (s) into epics and user stories alongside QRs. The fitness and the usefulness of AQRE are evaluated by using a focus group with eight practitioners in the IT department of a large Dutch government organization. The evaluation indicated that 12 of the 15 QRs challenges could be mitigated by the AQRE. Our main contribution is two-fold,(i) we proposed a solution approach to deal with QRs challenges in LSDA context, and (ii) our evaluation provided empirical evidence about its usefulness in realworld context.

Abstract Industry 4.0 refers to the digital transformation in the manufacturing domain through new technology. Currently, it expands well beyond manufacturing, affecting many areas of life and posing implications for all types of business. This paper focuses on the relationships between Industry 4.0 and Healthcare which transitions to increased interconnectivity, automation and smart decision making. The integration context of Industry 4.0 into Healthcare is only partly understood. Little was done until now to consolidate what is known on the integration benefits and the challenges. This article reports results of a systematic mapping study that analysed 69 papers to extract knowledge about the concepts of Industry 4.0 and the emerging Healthcare 4.0., and the relationships between them. We found 10 different perspectives of Healthcare 4.0, ranging from strategic to tactical and operational levels. Next, our results show: (i) nine applications of Industry 4.0 in the Healthcare domain: Augmented Reality and Simulation, Autonomous Robotics, Cybersecurity, Big Data Analytics, Internet of Things, Cloud Computing, Additive Manufacturing and Systems Integration; and (ii) 10 benefits and nine challenges in Healthcare 4.0. The most frequently mentioned benefits are patients' diagnosis, monitoring, treatment, and financial benefits. The most researched challenges are data fragmentation, heterogeneity, complexity, and privacy.

High-quality labeled textual data are vital for automatic mining and analysis of massive textual data produced by software systems. Several tools have been designed to facilitate manual labeling of textual data on different levels of granularity. However, these tools neither aim to provide statistics and analysis of labeled textual data, nor support collaboration among the coders to reduce the time cost in manual labeling and enhance the quality of labeling results. In this paper, we developed a Web-based labeling tool named CoolTeD (available at http://williamsriver.cn) for collaborative labeling of the textual datasets. Specifically, CoolTeD can be used: (1) to label textual data from the perspective of requirements types based on ISO 25010, (2) to review the labeling results with different confidence levels and contradictory labels, (3) to automatically calculate Cohen's Kappa coefficient of multiple coders, and (4) to visualize the labeling results. The tool demo is available at https://youtu.be/xVkrB_Cs1J8

Abstract Currently, the digital transformation of the provisioning of IT consulting services to clients forces many companies to reinvent their business models. While the importance of digital transformation is well recognised, very little has been done until now to closely examine the concepts characterising this phenomenon in the domain of IT consulting. This paper aims at mapping out what is currently known in scientific literature about the digitalisation of IT consulting service provisioning and its characterising concepts and approaches. Analysing 20 selected articles, we identified 10 concepts characterising the digital IT consulting and 14 areas considered to be candidates for inclusion in the design of digital IT consulting services. Moreover, we found only one approach to the digitalisation of service provisioning that was empirically evaluated. We conclude that (i) the digital transformation is multifaceted and characterised through many aspects; (ii) digital IT consulting services are primarily explored from business perspective, while research of stakeholders' needs, technical requirements, and designs of relevant artefacts is scarce; (iii) while individual solutions and practices that worked in real‐world contexts are reported, very little empirical evaluation was done. Finally, we reflected on the limitations and on the theoretical and practical implications of this work.

Release planning for mobile apps has recently become an area of active research. Prior research in this area concentrated on the analysis of release notes and on tracking user reviews to support app evolution with issue trackers. However, little is known about the impact of user reviews on the evolution of mobile apps. Our work explores the role of user reviews in app updates based on release notes. For this purpose, we collected user reviews and release notes of Spotify, the ߢnumber one’ app in the ‘Music’ category in Apple App Store, as the research data. Then, we manually removed non-informative parts of each release note, and manually determined the relevance of the app reviews with respect to the release notes. We did this by using Word2Vec calculation techniques based on the top 80 app release notes with the highest similarities. Our empirical results show that more than 60 % of the matched reviews are actually irrelevant to the corresponding release notes. When zooming in at these relevant user reviews, we found that around half of them were posted before the new release and referred to requests, suggestions, and complaints. Whereas, the other half of the relevant user reviews were posted after updating the apps and concentrated more on bug reports and praise.

Quality Requirements (QRs) pose challenges in many agile large-scale distributed enterprise systems. Often, enterprises counter such challenges by borrowing some heavyweight practices, e.g. adding more documentation. At the same time, agile methodologists proposed several scaled agile frameworks to specifically serve agile enterprises working on large and distributed systems. Little is known about the extent to which the proposed scaled frameworks address QRs and the specific ways in which this happens. Moreover, do these frameworks approach the QRs challenges in ways consistent with the Agile Manifesto? This paper treats these questions by analyzing one well-documented scaled framework, namely Scrum@Scale. We evaluated the alignment of Scrum@Scale with the Agile Manifesto, by means of the 4-Dimentional Analytical Tool proposed by other researchers. We then analyzed the practices of Scrum@Scale from the perspective of practitioners responsible for the QRs in a project, in order to understand how the Scrum@Scale practices mitigate those QRs challenges reported in previous work. Our analysis indicated that Scrum@Scale supports the agile values defined by the Agile Manifesto. Plus, we identified 12 Scrum@Scale practices that could (partially) mitigate one or more of the reported QRs challenges. Four of the reported QRs challenges got no remedy offered by Scrum@Scale.

Requirements engineering (RE) for startups has only recently become an area of intense exploration. This paper provides results of a qualitative study with 45 practitioners from four startup companies in four countries. This research was planned and executed using the design science research (DSR) methodology and yielded a descriptive framework that was subjected to a first evaluation in empirical settings. The authors found that practitioners in startups deploy rapid prototyping practices and user feedback but in a different way than the agile methods assume. This research concludes with discussion on validity threats and some implications for practice and research.

Abstract The increased need for constant connectivity and complete automation of existing systems fuels the popularity of Cyber Physical Systems (CPS) worldwide. Increasingly more, these systems are subjected to cyber attacks. In recent years, many major cyber‐attack incidents on CPS have been recorded and, in turn, have been raising concerns in their users' minds. Unlike in traditional IT systems, the complex architecture of CPS consisting of embedded systems integrated with the Internet of Things (IoT) requires rather extensive planning, implementation, and monitoring of security requirements. One crucial step to planning, implementing, and monitoring of these requirements in CPS is the integration of the risk management process in the CPS development life cycle. Existing studies do not clearly portray the extent of damage that the unattended security issues in CPS can cause or have caused, in the incidents recorded. An overview of the possible risk management techniques that could be integrated into the development and maintenance of CPS contributing to improving its security level in its actual environment is missing. In this paper, we are set out to highlight the security requirements and issues specific to CPS that are discussed in scientific literature and to identify the state‐of‐the‐art risk management processes adopted to identify, monitor, and control those security issues in CPS. For that, we conducted a systematic mapping study on the data collected from 312 papers published between 2000 and 2020, focused on the security requirements, challenges, and the risk management processes of CPS. Our work aims to form an overview of the security requirements and risks in CPS today and of those published contributions that have been made until now, towards improving the reliability of CPS. The results of this mapping study reveal (i) integrity authentication and confidentiality as the most targeted security attributes in CPS, (ii) model‐based techniques as the most used risk identification and assessment and management techniques in CPS, (iii) cyber‐security as the most common security risk in CPS, (iv) the notion of “mitigation measures” based on the type of system and the underline internationally recognized standard being the most used risk mitigation technique in CPS, (v) smart grids being the most targeted systems by cyber‐attacks and thus being the most explored domain in CPS literature, and (vi) one of the major limitations, according to the selected literature, concerns the use of the fault trees for fault representation, where there is a possibility of runtime system faults not being accounted for. Finally, the mapping study draws implications for practitioners and researchers based on the findings.

This review paper aims to explore state-of-the-art research and scientific literature about Enterprise Architecture (EA) resilience. Based on a systematic literature review, 850 articles have been subjected to evaluation for relevance. Based on the findings in 58 selected papers, we conclude that the field of EA resilience is still in its infancy. We identified several definitions and classified six types of resilience measures, based on information type (qualitative/quantitative), the source of the disruption (internal/external), and the duration of the resilience (short-term/long-term). Based on the review, we found 19 metrics that are candidates for EA practitioners to consider for the design of measurement and assessment methods for EA resilience. In addition, we identified relevant research from Information Systems sub-domains and other sciences that can be incorporated to create a holistic view on EA resilience. Based on published definitions of resilience in the selected papers, we propose a definition of the concept of EA resilience. This definition is validated using expert opinion and creates a starting point for reasoning about EA resilience and future research.

[Background] Publications on the professional occupation of Requirements Engineering (RE) reported on market demands for both RE and non-RE qualifications and indicated the state-of-the-practice of RE roles in industry. However, prior research was not from the perspective of the RE area in the Software Engineering Body of Knowledge (SWEBOK). Nor, they shed light on the industry needs of RE professionals in China. [Aims] This paper focused on RE-specific tasks and skills sought after in China, from the perspective of RE activities elaborated in SWEBOK. [Method] Using an empirical qualitative research method, we selected and analyzed 535 job ads from China's two largest job portals. Job titles and descriptions of these ads were analyzed to uncover RErelevant responsibilities in the categories of RE activities in SWEBOK as well as RE skills. [Results] We identified the qualifications, experience and skills demanded by Chinese employers. Specifically, we reported 23 RE tasks demanded in the 535 job ads, from the perspective of SWEBOK RE activities. [Conclusion] Our findings reveal that in China's job market, 'requirements engineer' is explicitly used as a title of job ads. Plus, around 78% of the selected job positions want the employees to perform tasks in requirements elicitation. Editing requirements specification is the most in-demand task in RE activities. In addition, employers placed more emphasis on both RE-specific and broad industry experience.

Published empirical research using agile practitioners’ perceptions indicated several important Quality Requirements (QRs) challenges experienced in agile large-scale distributed projects. It also indicated that a popular solution approach to those challenges is to inject some heavyweight practices into agile, for example adding documentation or roles of authorities for QRs. At the same time, agile methodologists proposed several scaled agile frameworks to specifically serve agile organizations working on large and distributed projects. How do these frameworks address QRs? Do they put forward any heavyweight practices as a solution to QRs challenges, or do they invent new agile practices fully aligned with the values of the Agile Manifesto? Currently, very little is known about the extent to which the QRs issues are accounted for in the design of these frameworks as proposed by agile methodologists. This paper attempts to narrow this gap of knowledge. It analyses Large-Scale Scrum (LeSS), a prominent scaled framework, from the perspective of QRs engineering and the Agile Manifesto’s values. To this end, we first applied the 4-Dimensional Analytical Tool to evaluate the degree of agility of the practices of the LeSS framework. We then analysed these practices and evaluated their applicability to mitigate the QRs challenges reported in previous work.

In many global outsourcing projects, the software requirement specifications (SRS) are often orchestrated by requirements analysts who have sufficient business knowledge but are not equipped to ask the kind of questions that are needed to unearth architecturally relevant information from the customer. Often, the resultant SRS therefore lacks some critical details needed by software architects to make informed architectural decisions. To remedy this, the software architects either make assumptions or conduct additional stakeholder interviews resulting in expensive refactoring efforts and project delays. Using an empirical approach, we have designed an approach of using architectural knowledge that can serve as a communication medium between requirements analyst and software architects. In this paper, we present a detailed empirical evaluation of our proposed approach, with practitioners from real-world organizations. Using two studies, we found that in the experience of the participating practitioners, the approach is relevant, easy to use and effective.

Abstract Cyber physical systems (CPSs) are safety‐critical, be it weapon systems, smart medical devices, or grid stations. This makes ensuring security of all the components constituting a CPS unavoidable. The rise in the demand of interconnectedness has made such systems vulnerable to attacks, ie, cyberattacks. Over 170 cases of cyber‐security breaches in CPS were reported over the past two decades. An increase in the number of cyberattack incidents on CPS makes them more exposed and less trustworthy. However, identifying the security requirements of the CPS to pinpoint the relevant risks may help to counteract the potential attacks. Literature reveals that the most targeted security requirements of CPS are authentication, integrity, and availability. However, little attention has been paid on certain crucial security attributes such as data freshness and nonrepudiation. One major reason of security breaches in CPS is the lack of custom or generalized countermeasures. Therefore, we propose a security risk mitigation framework for a CPS focused on constraints, ie, authentication, data integrity, data freshness, nonrepudiation, and confidentiality. Furthermore, we evaluate the proposed work using a case study of a safety critical system. The results show a decrease in the severity of the identified security risks, ie, man‐in‐the‐middle attack, spoofing, and data tempering.

[Context] Research on the professional occupation of Requirements Engineering (RE) indicated soft skills as very important in employers' search for RE specialists. A very long list of soft skills came out of prior research, with proficiency in English being ranked as the Number One skill. [Question/problem] To what extent, however, are these skills deemed critical in RE in practice, and also in making hiring decisions in RE, and why? Which skills are to be ranked higher in regard to hiring decisions, and which lower? In this study, we compare results based on analyses of job ads with practitioners' perceptions in real-life organizations. [Methodology] We executed two focus groups (FGs) with RE practitioners from industry, as part of the REFSQ 2018 conference. [Principal ideas/results] The soft skills from previous studies were discussed in depth with the FGs participants regarding where and why these skills are needed or sometimes are even unnecessary. Here, we report a ranked list of soft skills, among which communication skills were considered as the most important. Next, some of the skills ranked as the most important in job ads, are not needed everywhere. [Contribution] The results lead to a more differentiated view on those soft skills that requirements engineers need in practice, and the reasons for these skills' importance.

This paper presents a systematic literature review of software architecture approaches that support the implementation of Continuous Delivery (CD) and DevOps. Its goal is to provide an understanding of the state-of-the-art on the topic, which is informative for both researchers and practitioners. We found 17 characteristics of a software architecture that are beneficial for CD and DevOps adoption and identified ten potential software architecture obstacles in adopting CD and DevOps in the case of an existing software system. Moreover, our review indicated that micro-services are a dominant architectural style in this context. Our literature review has some implications: for researchers, it provides a map of the recent research efforts on software architecture in the CD and DevOps domain. For practitioners, it describes a set of software architecture principles that possibly can guide the process of creating or adapting software systems to fit in the CD and DevOps context.

Recent research on the automatic classification of app reviews either focused on grouping app reviews into categories relevant to software evolution, or employed app reviews as the only research data to improve app reviews classification.Although it was reported that app review classification can benefit from supplementing user reviews with the data from other sources, only a few studies employed app changelogs for this purpose.This paper explores how to augment app reviews with changelogs to improve the accuracy and performance of classifying functional and non-functional requirements in app reviews.Specifically, we propose AUG-AC as an approach to extract feature words from app changelogs and construct the augments for app reviews.Next, we designed a series of experiments to evaluate our approach, varying in the length of AC-based augments for app reviews.The results show that AUG-AC outperforms the existing method by using app changelogs as a source of data next to app reviews.

Abstract Crowdsourcing is an appealing concept for achieving good enough requirements and just‐in‐time requirements engineering (RE). A promising form of crowdsourcing in RE is the use of feedback on software systems, generated through a large network of anonymous users of these systems over a period of time. Prior research indicated implicit and explicit user feedback as key to RE‐practitioners to discover new and changed requirements and decide on software features to add, enhance, or abandon. However, a structured account on the types and characteristics of user feedback useful for RE purposes is still lacking. This research fills the gap by providing a mapping study of literature on crowdsourced user feedback employed for RE purposes. On the basis of the analysis of 44 selected papers, we found nine pieces of metadata that characterized crowdsourced user feedback and that were employed in seven specific RE activities. We also found that the published research has a strong focus on crowd‐generated comments (explicit feedback) to be used for RE purposes, rather than employing application logs or usage‐generated data (implicit feedback). Our findings suggest a need to broaden the scope of research effort in order to leverage the benefits of both explicit and implicit feedback in RE.

[Background] Prior research on the professional occupation of Requirements Engineering (RE) in Europe and Latin America indicated incongruities between RE practice as perceived by industry and as in textbooks, and conducted detailed analysis of both RE and non-RE job aspects. Relatively little is published on the RE competencies and skills industry expects, and seldom investigated the application domains calling for RE professionals. [Aims] We felt motivated by those findings to carry out research on RE job posts in a North-American market. Especially, we focused solely on RE-specific tasks, competencies and skills, from the perspective of defined position categories. Plus, we intend to explore the application domains in need for RE professionals to reveal the wide range of RE roles in industry. [Methods] Coding process, analysis, and synthesis were applied to the textual descriptions of the 190 RE job ads from Canada's most popular online job search site, especially to the text referring to tasks and competencies. [Results] We contribute to the empirical analysis of RE jobs, by providing insights from Canada's IT market in 2017. Using 109 RE job ads from the most popular IT job search portal T-Net, we identified the qualifications, experience and skills demanded by Canadian employers. Furthermore, we explored the distribution of those RE tasks and competences over the 11 categories of RE roles. [Conclusions] Our results suggest that the majority of the employers were big to very big companies in 29 business domains, and the most in-demand RE skills for them were related to RE methods and to project management aspects affecting requirements. In addition, employers placed much more emphasis on experience - both RE-specific and broad software engineering experience, than on higher education.

[Background] Recent research on mining app reviews for software evolution indicated that the elicitation and analysis of user requirements can benefit from supplementing user reviews by data from other sources. However, only a few studies reported results of leveraging app changelogs together with app reviews. [Aims] Motivated by those findings, this exploratory experimental study looks into the role of app changelogs in the classification of requirements derived from app reviews. We aim at understanding if the use of app changelogs can lead to more accurate identification and classification of functional and non-functional requirements from app reviews. We also want to know which classification technique works better in this context. [Method] We did a case study on the effect of app changelogs on automatic classification of app reviews. Specifically, manual labeling, text preprocessing, and four supervised machine learning algorithms were applied to a series of experiments, varying in the number of app changelogs in the experimental data. [Results] We compared the accuracy of requirements classification from app reviews, by training the four classifiers with varying combinations of app reviews and changelogs. Among the four algorithms, Naïve Bayes was found to be more accurate for categorizing app reviews. [Conclusions] The results show that official app changelogs did not contribute to more accurate identification and classification of requirements from app reviews. In addition, Naïve Bayes seems to be more suitable for our further research on this topic.

Industry-relevant information systems (IS) and software engineering (SE) research assumes practitioners' involvement, be it in the exploration of the state-of-the-art practice or in the investigation of real-life problems experienced in organizations. Crowdsourcing is an appealing concept for collecting practitioners' perceptions on an industry-relevant phenomenon that is of interest to researchers. As practitioners-generated contents are easily available in social media platforms such as practitioners' blogs or professional discussion groups in LinkedIn, researchers face the opportunity to use this crowdsourced information for the purpose of gaining understanding of a situation from the point of view of the professionals involved therein. While there are many benefits of using crowdsourcing for data collection, there are also challenges, all of which pose validity threats of various degrees to the empirical results obtained. This tutorial will provide a systematic understanding of the use of practitioners' crowdsourced data for empirical research purposes, and of the possible ways to safely apply it in IS and SE research. The tutorial leverages the tutor's experience and lessons learned from using practitioners' blogs articles for qualitative research in business-IT alignment and in large scale online games. At the end of the tutorial, attendees should be able to critically reason about (i) the possible choices in designing a crowdsourcing-based research process, (ii) the quality criteria for judging their research designs, and (iii) the criteria for evaluating their studies.

Smart cities are gaining increasingly more importance in both research and business circles. Much effort is spent to defining what a smart city is and how it could be realized with today's or future technologies. However, from requirements engineering perspective, our knowledge of smart cities is fragmented; little is known about the requirements for smart cities as complex systems, or as systems of systems, in specific application domains. In this paper, we elicit requirements for smart city systems by carrying out a systematic review of scientific literature focused on the so-called “hard” domains of smart cities. Based on 32 selected publications, we gathered and classified requirements in respect to three types of smart city systems (instrumented, interconnected, and intelligent systems) and four classes of requirements: end-to-end experience, architectural, security, and infrastructure requirements. Our most important findings are that: (1) most authors took a bottom-up approach to defining requirements for smart cities; their efforts focused mainly on requirements important for designing an architecture that could scale up to any size and include any device or system; and (2) very little is mentioned on the newly emerging security and privacy challenges that are critical to gain the citizens' acceptance of smart city apps.

In the last few years, agile development methods are getting increasingly popular in large-scale distributed contexts. Despite this popularity, empirical studies have reported several challenges that large-scale distributed agile projects face regarding the implementation of quality requirements. However, there is little known about the mechanisms behind those challenges and the practices currently used by agile practitioners to adequately assure the implementation of quality requirements in distributed context. To look deeper into this, we performed a qualitative multi-case study in six different organizations in the Netherlands. Our multi-case study included seventeen semi-structured open-ended in-depth interviews with agile practitioners of different background and expertise. The analysis of the collected data re-sulted in identifying eleven mechanisms that could be associated with the previously published list of challenges. Moreover, the analysis uncovered nine practices used by agile practitioners as solutions to the challenges, in order to ensure the implementation of quality requirements. Last, we have mapped the identified mechanisms and practices to the previously identified challenges to get insight into the possible cause and mitigation of those challenges.

Reasonable reduction and controlling of software cost is always a challenge for software companies. To estimate software development cost more precisely, current research effort is focused on improving the measurement of software size or complexity by combining or adjusting key cost drivers, such as function points and other observable project context factors. However, personnel factors are seldom investigated or treated in depth as a way to reduce the estimated software development cost. On the premise that a software project is decomposed in a number of tasks, and that predetermined developers are available as resources for it, this paper intends to optimize the allocation of available personnel for lower development cost. In this research, we consider the problem of allocating competent developers to suitable tasks as an unbalanced personnel assignment problem, and improve the traditional Hungarian Algorithm by applying three strategies to find optimal personnel allocation solutions for diverse requirements. Moreover, the performance of our improved algorithms is evaluated and compared through a series of experiments on simulation datasets to identify and validate the measurement indicators and influence factors of their performance.

Agile software development methods have become increasingly popular in the last years. Despite their popularity, they have been criticized for focusing on delivering functional requirements and neglecting the quality requirements. Several studies have reported this shortcoming. However, there is little known about the challenges organizations currently face when dealing with quality requirements. Based on a qualitative exploratory case study, this research investigated real life large-scale distributed Agile projects to understand the challenges Agile teams face regarding quality requirements. Eighteen semi-structured open-ended in-depth interviews were conducted with Agile practitioners representing six different organizations in the Netherlands. Based on the analysis of the collected data, we have identified nine challenges Agile practitioners face when engineering quality requirements in large-scale distributed Agile projects that could harm the implementation of the quality requirements and result in neglecting them.

Recently, the requirements engineering (RE) community recognized the increasing need for understanding how industry perceives the jobs of requirements engineers and their most important qualifications. This study contributes to the community's research effort on this topic. Based on an analysis of RE job ads in 2015 from the Netherlands' three most popular online IT-job portals, we identified those task and skill related qualifications that employers demand from RE job seekers. We found that the job titles used in industry for the specialists that the RE community calls 'requirements engineers', are 'Product Owner' and 'Analyst', be it Information Analyst, Application Analyst, or Data Analyst. Those professionals supposed to perform RE tasks also take responsibility for additional tasks including quality assurance, realization and deployment, and project management. The most in-demand skills are soft skills: proficiency in Dutch and English, plus communication and analytical skills. RE is perceived as an occupation for experts, with 23% of all job ads asking explicitly for RE experience and 63% asking for experience similar to RE.

Abstract Organizations are introducing agile and lean software development techniques in operations to increase the pace of their software development process and to improve the quality of their software. They use the term DevOps, a portmanteau of development and operations, as an umbrella term to describe their efforts. In this paper, we describe the ways in which organizations implement DevOps and the outcomes they experience. We first summarize the results of a systematic literature review that we performed to discover what researchers have written about DevOps. We then describe the results of an exploratory interview‐based study involving 6 organizations of various sizes that are active in various industries. As part of our findings, we observed that all organizations were positive about their experiences and only minor problems were encountered while adopting DevOps.

Software requirements specifications (SRSs) often lack the detail needed to make informed architectural decisions. Architects therefore either make assumptions, which can lead to incorrect decisions, or conduct additional stakeholder interviews, resulting in potential project delays. We previously observed that software architects ask Probing Questions (PQs) to gather information crucial to architectural decision-making. Our goal is to equip Business Analysts with appropriate PQs so that they can ask these questions themselves. We report a new study with over 40 experienced architects to identify reusable PQs for five areas of functionality and organize them into structured flows. These PQ-flows can be used by Business Analysts to elicit and specify architecturally relevant information. Additionally, we leverage machine learning techniques to determine when a PQ-flow is appropriate for use in a project, and to annotate individual PQs with relevant information extracted from the existing SRS. We trained and evaluated our approach on over 8,000 individual requirements from 114 requirements specifications and also conducted a pilot study to validate its usefulness.

Today many organizations use service-oriented architecture and agile software development as their software paradigms. While both certainly have their advantages, in the fields of Empirical Software Engineering and Information Systems these have been treated in relative isolation and their impact on each other is not well understood. This paper performs a grounded theory research by empirically analyzing professional blog posts published in IBM's Developerworks platform, to find good practices and common pitfalls of using a service-oriented architecture and agile software development together. The perspective taken in this study is the one of service-oriented architecture practitioners involved in agile projects. We found that continuous integration, collaboration, governance and continuous improvement are good practices that result out of merging the two paradigms. We found that the challenges of the joint use of service-oriented architecture and agile lie in the engineering of non-functional requirements, compliance requirements as well as up-front architecture evaluation.

Model-Driven Development (MDD) is no longer a novel development paradigm. It has become mature from a research perspective and recent studies show its adoption in industry. Still, some issues remain a challenge. Among them, we are interested in the treatment of non-functional requirements (NFRs) in MDD processes. Very few MDD approaches have been reported to deal with NFRs (and they do it in a limited way). However, it is clear that NFRs need to be considered somehow in the final product of the MDD process. To better understand how NFRs are integrated into the existing MDD approaches, we have initiated the NFR4MDD project, a multi-national empirical study, based on interviews with companies working on MDD projects. Our project aims at surveying the state of the practice for this topic. In this paper, we summarize our research protocol and present the current status of our study. The discussion will focus on the peculiarities of our study's context and organization involving about 20 researchers from 8 European countries.

Software architects are responsible for designing an architectural solution that satisfies the functional and non-functional requirements of the system to the fullest extent possible. However, the details they need to make informed architectural decisions are often missing from the requirements specification. An earlier study we conducted indicated that architects intuitively recognize architecturally significant requirements in a project, and often seek out relevant stakeholders in order to ask Probing Questions (PQs) that help them acquire the information they need. This paper presents results from a qualitative interview study aimed at identifying architecturally significant functional requirements' categories from various business domains, exploring relevant PQs for each category, and then grouping PQs by type. Using interview data from 14 software architects in three countries, we identified 15 categories of architecturally significant functional requirements and 6 types of PQs. We found that the domain knowledge of the architect and her experience influence the choice of PQs significantly. A preliminary quantitative evaluation of the results against real-life software requirements specification documents indicated that software specifications in our sample largely do not contain the crucial architectural differentiators that may impact architectural choices and that PQs are a necessary mechanism to unearth them. Further, our findings provide the initial list of PQs which could be used to prompt business analysts to elicit architecturally significant functional requirements that the architects need.

Context: To software architects (SAs), the quality requirements (QRs) to a software system are key to designing the software architecture. However, understanding SAs' roles in the QRs engineering activities only recently became a topic in empirical requirements engineering research and very little is still known about QRs engineering from SAs' in large and distributed projects. Goal: This exploratory study aims at explicating how SAs are involved in engineering QRs in a specific distributed development setting, namely in organizations that distribute software development activities to closely located business units, known as near-shore development centres (NDCs), and in a specific geographic zone, namely Eastern Europe. Method: Based on interviews with 16 practitioners working on large projects in NDCs, we explicate the participation and involvement of NDCs' architects in QRs tasks. Results: We found that SAs from NDCs (i) are actively involved in QRs documentation and validation, (ii) are relatively passive participants in QRs elicitation and prioritization, and (iii) are not at all involved in QRs negotiation. Perhaps, our most surprising finding is that NDCs may often have economic incentives to misalign with onshore QRs practices. Conclusions: We explicated QRs practices, compared them to previously published ones, and found implications for both researchers and practitioners. Though, our results are preliminary, as they are from an exploratory study.

Software development can profit from improvements in the deployment and maintenance phases. DevOps improves these phases through a collection of principles and practices, centered around close collaboration between Development and Operations personnel. Both sides have paid little attention to issues faced by each other. Yet knowledge sharing is invaluable. Development personnel can for example make software more robust by implementing scalability and performance features desired by operations personnel.

Context: Requirements engineering process improvement (REPI) approaches have gained much attention in research and practice. Goal: So far, there is no comprehensive view on the research in REPI in terms of solutions and current state of reported evidence. We aims to provide an overview on the existing solutions, their underlying principles and their research type facets, i.e. their state of empirical evidence. Method: To this end, we conducted a systematic mapping study of the REPI publication space. Results: This paper reports on the first findings regarding research type facets of the contributions as well as selected methodological principles. We found a strong focus in the existing research on solution proposals for REPI approaches that concentrate on normative assessments and benchmarks of the RE activities rather than on holistic RE improvements according to individual goals of companies. Conclusions: We conclude, so far, that there is a need to broaden the work and to investigate more problem-driven REPI which also targets the improvement of the quality of the underlying RE artefacts, which currently seem out of scope.

This paper is an empirical study on the application of Function Points (FP) and a FP-based reuse measurement model in Enterprise Resource Planning (ERP) projects in three organizations in the telecommunication sector. The findings of the study are used to compare the requirements reuse for one particular package, namely SAP. We found (1) that reuse is possible up to 80% at best, and (2) that, while for some modules, the organizations achieved the same levels of reuse, for other modules, the organizations' levels of reuse varied widely. We conclude with some implications of our findings for both practitioners and researchers.

Compliance with standards or levels in maturity models and agile approaches are two radically different ways to address and achieve software quality. There is a mixed understanding of the possibility for their co-existence within an organization. Outside of the dogmatic debate regarding their co-existence, however, voices have been raised recently to recognize that both approaches have their merits, and perhaps, can be combined. This paper presents the results of an interview-based exploratory case study on the practices that an agile-by-design organization has put in place in order to profit from the opportunities that compliance to a quality standard can offer in respect to value creation for clients. Our conclusions are (i) that being compliant with a standard helps an agile company achieve client satisfaction, improved product quality and waste reduction; and (ii) that standards compliance does not necessarily impose significant changes on the agile process of an organization. Implication for practice is twofold: our results indicate (1) that agile organizations should strive for becoming more mature as this brings additional benefits, and (2) that for organizations to get standards-compliant there is a need of guidelines to direct them in complementing their agile processes with standards-compliant practices.

Gameplay requirements are central to game development. In the business context of massive multiplayer online role-playing games (MMOGs) where game companies' revenues rely on players' monthly subscriptions, gameplay is also recognized as the key to player retention. However, information on what gameplay requirements are and how practitioners `engineer' them in real life is scarce. This exploratory study investigates how practitioners developing MMOGs reason about gameplay requirements and handle them in their projects. 12 practitioners from three leading MMOGs-producing companies were interviewed and their gameplay requirements documents were reviewed. The study's most important findings are that in MMOG projects: (1) gameplay requirements are co-created with players, (2) are perceived and treated by practitioners as sets of choices and consequences, (3) gameplay is endless within a MMOG, and while gameplay requirements do not support any game-end goal, they do support a level-end goal, (4) `paper-prototyping' and play-testing are pivotal to gameplay validation, (5) balancing the elements of the gameplay is an on-going task, perceived as the most difficult and labor-consuming, (6) gameplay happens both in-game and out-of-the game. We conclude with discussion on validity threats to our results and on implications for research and practice.

A new technology shift brings to the ERP domain a change in the industry and a new platform build on in-memory optimized databases, introduced and known as SAP HANA [1]. This technology shift in the ERP domain led to SAP's ERP on HANA, the solution where the ERP suite is offered on the same platform as ERP Services such as Business Analytics. The integration of ERP Services and the ERP suite brings to the industry new opportunities to "fine tune" customer and industry specific business processes. This radical shift in innovation brings with it new challenges in terms of ERP effort estimation. No longer can we rely on a single method such as functional size measurement methods, due to the wide range of customization possibilities. This shift from a typical predefined solution scope to a highly customizable landscape poses a challenge to project estimation practitioners as the functional size estimation techniques used in the past for ERP solutions address a fixed scope deployable in multiple landscapes, and hence are no longer suitable for dynamically definable scope. Today's highly volatile and customized ERP landscape demands a new approach to estimate effort by leveraging ERP professionals' tacit knowledge and expert judgments. This paper presents the ERP Service estimation method that leverages the strengths of expert-judgment-based estimation techniques while using a more structured approach to reduce the effects of expert bias and avoid common pitfalls associated with judgment-based estimation.

The COSMIC method provides a standardized way of measuring the functional size of software from the functional domains commonly referred to as 'business application' or 'Management Information Systems' (MIS) and 'real-time' software, and hybrids of these. In practice it is often sufficient to measure a functional size approximately. Typical situations where such a need arises are early in the life of a project, before the functional user requirements ('FUR') have been specified down to the level of detail where the precise size measurement is possible or when a measurement is needed, but there is insufficient time or no need to measure the required size using the standard method. The guideline describes the current state of the art with regard to approximate COSMIC functional size measurement. All proposed COSMIC approximation methods rely on determining some average of the size(s) and/or number(s) of functional processes. The fact that the size of a single functional process has no upper finite limit is probably the reason why multiple COSMIC approximation methods have been developed for different types of software. Therefore the guideline describes a number of approximation methods with their pros and cons, their recommended area of application and their validity, rather than document a single COSMIC approximation method.

Agile practices on requirements dependencies are a relatively unexplored topic in literature. Empirical studies on it are scarce. This research sets out to uncover concepts that practitioners in companies of various sizes across the globe and in various industries, use for dealing with requirements dependencies in their agile software projects. Concepts were revealed through online focus group research, using an adapted forum for discussion, and grounded theory to analyze the responses. Our study resulted in the following findings: (1) requirements dependencies occur in agile projects and are important to these projects' success just as this is known for `traditional' software projects'; (2) requirements dependencies (i) were considered and treated as part of risk management, (ii) were deemed a responsibility of the individual team members, and (iii) mostly did affect project planning; (3) continuous communication and collaboration - two essential features of any agile method, were found critical to mitigating the risks due to dependencies; (4) a hybrid approach to architecture between agile and plan-driven methods was perceived to yield maximum scalability and help coping with dependencies; (5) `cross-cutting concerns', a category of dependencies, were not uniformly understood in an agile context and require more research.

In 2006–2010, 12 practices for engineering the coordination requirements in inter-organizational Enterprise Resource Planning (ERP) projects were identified, classified to levels of inter-organizational coordination complexity, and subjected to a preliminary evaluation. Aim: This set of practices is now the object of a broader evaluation effort, including 8 focus groups with practitioners working in various project contexts (e.g. outsourced, cloud, agile), so that we get deeper understanding about those practices that happen in certain contexts and not in others. Method: In this paper, we present the focus group research pertaining to the agile ERP project context. We analyze the coordination requirements experiences of 9 practicing ERP consultants, specialized in agile ERP exclusively, for the purpose of understanding the fit of the 12 practices with these practitioners' project realities. Results/Conclusion: Our results suggest that all 12 practices have been observed by the practitioners. However, three out of the 12 practices were associated to levels of inter-organizational coordination complexity which were different than what we thought.

This short paper summarizes and discusses the result of an iterative construction and evaluation of a checklist for writing and reading reports about experimental and observational research.

Many publications have dealt with various types of security requirements in cloud computing but not all types have been explored in sufficient depth. It is also hard to understand which types of requirements have been under-researched and which are most investigated. This paper's goal is to provide a comprehensive and structured overview of cloud computing security requirements and solutions. We carried out a systematic review and identified security requirements from previous publications that we classified in nine sub-areas: Access Control, Attack/Harm Detection, Non-repudiation, Integrity, Security Auditing, Physical Protection, Privacy, Recovery, and Prosecution. We found that (i) the least researched sub-areas are non-repudiation, physical protection, recovery and prosecution, and that (ii) access control, integrity and auditability are the most researched sub-areas.

In this paper we analyse possible reasons for the relatively low use of theories in software engineering (SE) papers found by Hannay et al. [16]. We provide an initial explanation in terms of properties of theories, test this by analyzing 32 of the 40 theories reviewed by Hannay et al., and then revise our analysis based on this test. Our analysis revealed that background theories from other disciplines are context-free and make idealizing assumptions, which make it easier for them to be (re)used across settings. Theories built in SE are mid-range and context-sensitive, and make less idealizing assumptions. This is normal for engineering theories, but it does make them harder to (re)use across settings. We also found that background theories from other disciplines usually provide explanations for phenomena in terms of mechanisms, whereas SE theories are statistical models of phenomena observed in an experiment, which also makes them harder to (re)use across settings. We end the paper with a recommendation of bottom-up development of theories about mechanisms in software engineering projects by doing case studies.

In software industry, many organizations either focus their traceability efforts on Functional Requirements (FRs) or else fail entirely to implement an effective traceability process. Non-Functional Requirements (NFRs) such as security, safety, performance, and reliability are treated in a rather ad hoc fashion and are rarely traced. This is mainly because of the unique nature of NFRs. They are subjective, relative and they tend to become scattered among multiple modules when they are mapped from the requirements domain to the solution space. Furthermore, NFRs can often interact, in the sense that attempts to achieve one NFR can help or hinder the achievement of other NFRs at particular software functionality. Such an interaction creates an extensive network of interdependencies and tradeoffs among NFRs which is not easy to trace. In a previous work, we proposed a conceptualization of NFRs through the NFRs Ontology. In this paper, we extend the previous work by proposing a change management mechanism for tracing the impact of NFRs on the other constructs in the ontology such as FR or NFR operationalization and vice versa, and providing a traceability mechanism using Datalog expressions to implement queries on a relational model-based representation for the ontology. The proposed traceability queries are then evaluated through a multi-project variation quasi-experiment on regression testing conducted in the industry.

This paper reports on the findings of a case study in a company in the financial services sector in which we replicated the use of a previously published approach to systematically balance the contextual uncertainties in the estimation of Enterprise Resource Planning (ERP) projects. The approach is based on using three techniques, a parametric model, namely COCOMO II, a portfolio management model, and Monte Carlo simulations. We investigated (i) whether the adjustment of uncertain cost drivers in the COCOMO II model increases the chance of project success in a portfolio of ERP projects, (ii) which cost drivers of the COCOMO II model can be adjusted in a way that maximized the chance of portfolio success under time constraints, and (iii) which cost drivers of the COCOMO II model can be adjusted in a way that maximized the chance of portfolio success under effort constraints. We found that 11 COCOMO II cost drivers can be changed so that the change impacts the project outcomes under both time and effort constraints. This result is different from the result in the first case study in which 13 such factors were found.

This focus group study evaluates 12 practices for engineering the coordination requirements in inter-organizational Enterprise Resource Planning projects. The practices were proposed and initially evaluated in previously published articles. Here, we present independent feedback of practitioners on the fit of the practices with these practitioners' project realities. We found that all 12 practices have been observed by the practitioners. Four out of the 12 practices have been observed in contexts that we have not expected, which formed ideas for future research.

Requirements (re)prioritization is an essential mechanism of agile development approaches to maximize the value for the clients and to accommodate changing requirements. Yet, in the agile Requirements Engineering (RE) literature, very little is known about how agile (re)prioritization happens in practice. Conceptual models about this process are missing, which, in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time. We did a multiple case study on agile requirements prioritization methods to yield a conceptual model for understanding the inter-iteration prioritization process. The model is derived by using interview data from practitioners in 8 development organizations. Such a model makes explicit the concepts that are used tacitly in the agile requirements prioritization practice and can be used for structuring future empirical investigations about this topic, and for analyzing, supporting, and improving the process in real-life projects.

This focus group study presents our first validation of practices for engineering the coordination requirements in cross-organizational Enterprise Resource Planning (ERP) projects. The study evaluates 13 practices addressing a variety of coordination aspects crucial to ERP projects. These practices are results in previously published research publications by the first author. The practices are formulated in response to practitioners' needs at ERP adopting organizations. The proposed practices have now reached the stage where we need some independent feedback as to the extent to which they fit the realities of practitioners. We perform this validation by means of a qualitative research approach, namely the focus group method. Current software engineering literature provides few examples of using focus groups in the evaluation of good software development practices. Because of this, providing reflections on our focus-group-based validation experiences will be of value to both the research community and practitioners.

Continuous customer-centric requirements reprioritization is essential in successfully performing agile software development. Yet, in the agile RE literature, very little is known about how agile reprioritization happens in practice. Generic conceptual models about this process are missing, which in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time. This paper presents a Grounded Theory study on agile requirements prioritization methods to yield a conceptual model for understanding the inter-iteration prioritization process in terms of inputs and outcomes. The latter is derived by using qualitative empirical data, published earlier by other authors. Such a conceptual model makes explicit the concepts that are used tacitly in different agile requirements prioritization methods and can be used for structuring future empirical investigations about this topic.

Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory cross-case study on agile prioritization and business value delivery processes in eight software organizations. We found that some explicit and fundamental assumptions of agile requirement prioritization approaches, as described in the agile literature on best practices, do not hold in all agile project contexts in our study. These are (i) the driving role of the client in the value creation process, (ii) the prevailing position of business value as a main prioritization criterion, (iii) the role of the prioritization process for project goal achievement. This implies that these assumptions have to be reframed and that the approaches to requirements prioritization for value creation need to be extended.

This paper reports on an experiment that investigates the predictability of software project size from software product size. The predictability research problem is analyzed at the stage of early requirements by accounting the size of functional requirements as well as the size of non-functional requirements. The experiment was carried out with 55 graduate students in Computer Science from Concordia University in Canada. In the experiment, a functional size measure and a project size measure were used in building estimation models for sets of web application development projects. The results show that project size is predictable from product size. Further replications of the experiment are, however, planed to obtain more results to confirm or disconfirm our claim.

Agile requirements engineering is driven by creating business value for the client and heavily involves the client in decision-making under uncertainty. Real option thinking seems to be suitable in supporting the client's decision making process at inter-iteration time. This paper investigates the fit between real option thinking and agile requirements engineering. We first look into previously published experiences in the agile software engineering literature to identify (i) `experience clusters' suggesting the ways in which real option concepts fit into the agile requirements process and (ii) `experience gaps' and under-researched agile requirements decision-making topics which require further empirical studies. Furthermore, we conducted a cross-case study in eight agile development organizations and interviewed 11 practitioners about their decision-making process. The results suggest that options are almost always identified, reasoned about and acted upon. They are not expressed in quantitative terms, however, they are instead explicitly or implicitly taken into account during the decision-making process at inter-iteration time.

Abstract The increasing demand for Enterprise Resource Planning (ERP) solutions as well as the high rates of troubled ERP implementations and outright cancellations calls for developing effort estimation practices to systematically deal with uncertainties in ERP projects. This paper describes an approach—and a case study—to balancing uncertainties of context in the very early project stages, when an ERP adopter initiates a request‐for‐proposal process and when alternative bids are to be compared for the purpose of choosing an implementation partner. The proposed empirical approach leverages the complementary application of three techniques, an algorithmic estimation model, Monte Carlo simulation, and portfolio management. Our case study findings show how the ability of our approach to model uncertainty allows practitioners to address the challenging question of how to adjust project context factors so that chances of project success are increased. We also include a discussion on the implications of our approach for practice as well as on the possible validity threats and what the practitioner could do to counterpart them. Copyright © 2010 John Wiley & Sons, Ltd.

This paper describes an empirical mapping study, which was designed to identify what aspects of software requirement specifications (SRS) are empirically evaluated, in which context, and by using which research method. On the basis of 46 identified and categorized primary studies, we found that understandability is the most commonly evaluated aspect of SRS, experiments are the most commonly used research method, and the academic environment is where most empirical evaluation takes place.

The growing awareness of the importance of non-functional requirements (NFRs) among the requirements engineering (RE) community in the last few years led to a heightened interest in NFRs description and modeling and, in turn, to the emergence of several models intended to capture and structure the relevant concepts defining the NFRs and their relations. Yet, most of the terms and concepts in use for describing NFRs have been loosely defined, and often there is no commonly accepted taxonomy of NFRs. Common Foundation is required to enable effective communication and to enable integration of NFRs' related research activities within the RE community. In this paper, this Common Foundation will be realized by developing an ontology-based approach which is adequate for projects taking into consideration the NFRs and their relations earlier in the software development and throughout the life cycle.

In early phases of the software cycle, requirements prioritization necessarily relies on the specified requirements and on predictions of benefit and cost of individual requirements. This paper presents results of a systematic review of literature, which investigates how existing methods approach the problem of requirements prioritization based on benefit and cost. From this review, it derives a set of under-researched issues which warrant future efforts and sketches an agenda for future research in this area.

Requirements changes are an issue in the software development life cycle which often originates from an incomplete knowledge of the domain of interest. Hardly any requirement manifests in isolation, and usually the provision of one requirement may affect the level of provision of another. Understanding the relations among system requirements is essential to ensuring their consistency and change management. In practice, many organizations either focus their traceability efforts on functional requirements (FRs) or else fail entirely to implement an effective traceability process. Tracing non-functional requirements (NFRs) has, by and large, been neglected. In this paper, we propose a metamodel which explicitly captures NFRs and their relations, and which is independent from any programming paradigm. In addition, we present an implementation using XML-based representations for the metamodel and XQuery queries to represent tracing information.

There are many methods for estimating size, effort, schedule and other cost aspects of IS projects, but only one specifically developed for Enterprise Resource Planning (ERP) (Stensrud, Info Soft Technol 43(7):413–423, 2001) and none for simultaneous, interdependent ERP projects in a cross-organizational context. The objective of this paper is to sketch the problem domain of cross-organizational ERP cost estimation, to survey available solutions, and to propose a research program to improve those solutions. In it, we: (i) explain why knowledge in the cost estimation of cross-organizational ERP is fragmented, (ii) assess the need to integrate research perspectives, and (iii) propose research directions that an integrated view of estimating cross-organizational ERP project cost should include.

Aligning requirements of a business with its information technology is currently a major issue in enterprise computing. Existing literature indicates important criteria to judge the level of alignment between business and IT within a single enterprise. However, identifying such criteria in an inter-enterprise setting - or re-thinking the existing ones - is hardly addressed at all. Business-IT alignment in such settings poses new challenges, as in inter-enterprise collaborations, alignment is driven by economic processes instead of centralized decision-making processes. In our research, we develop a maturity model for business-IT alignment in inter-enterprise settings that takes this difference into account. In this paper, we report on a multi-method approach we devised to confront the validation of the business-IT alignment criteria that we included in the maturity model. As independent feedback is critical for our validation, we used a focus group session and a case study as instruments to take the first step in validating the business-IT alignment criteria. We present how we applied our approach, what we learnt, and what the implications were for our model.

This poster reports on a solution to ERP project cost estimation and on results from its first experimental application.

Cross-organizational information systems projects, such as ERP, imply an expensive requirements engineering (RE) cycle. Little is known yet about how to carry it out with more predictable alignment results and chances for success. We propose an approach that allows incremental, systematic improvement of cross-organizational RE. It builds on organizational network research, coordination theory, ERP misalignments, and existing RE improvement standards

A key issue in requirements engineering (RE) for enterprise resource planning (ERP) in a cross-organizational context is how to find a match between the ERP application modules and requirements for business coordination. This paper proposes a conceptual framework for analyzing coordination requirements in inter-organizational ERP projects from a coordination theory perspective. It considers the undocumented assumptions for coordination that may have significant implications for ERP adopting organizations. In addition, we build a library of existing coordination mechanisms supported by modern ERP systems, and use it to make a proposal for how to improve the match between ERP implementations and supported business coordination processes. We discuss the implications of our framework for practicing requirements engineers. Our framework and library are based on a literature survey and the experience with ERP implementation of one of us (Daneva). We further validate and refine our framework.

Generic off-the-shelf requirements engineering (RE) processes have been packaged by enterprise resource planning (ERP) vendors since 1997, and adopted by client organizations as the key strategy for getting the business requirements and the conceptual design for their complex solutions. We summarize one company's five years of experience in making a generic ERP RE model a live process. It rests on previously published ERP RE process assessment results and reports on what we learnt with particular focus on typical issues organizations face when adopting a standard model and solutions that can be used to avoid those issues in the future. Each of our lessons is described together with a RE practice, technical foundation for the practice and engineering techniques for the RE practitioner. The lessons were used to refine our corporate documentation model, a process-focused and template-based ERP-architecture framework.

Applying standard requirements engineering (RE) processes is a major trend in today's enterprise resource planning (ERP) software engineering. It emerged five years ago with the promise to provide a mechanism helping ERP project organizations deliver their business requirements timely and within budget. This paper looks in depth at a standard ERP RE process and seeks answers to four questions: how well it is defined, what are the risks associated with its application in mature/immature organizations, what are the essential practices that contribute to its success, and what are the costs of the process and the quality of the delivered results. The main motivation of this paper is to provide some practical advice for using assessments to increase project teams' understanding of the ERP RE process.