Requirements engineering is the activity of matching product properties with stakeholder expectations. Products are bought or they would not be manufactured. That means that specifying product properties is an activity at the core of economics, the science and practice making decisions about which products to buy (and sell) in a world of finite resources. Which in turn means that the requirements of a product must align with the business model of the product, the description of how the product creates value, how value is delivered to the customer, and how the supplier captures value from this. Therefore the requirements of a product must align with the business model of the product. In this talk I discuss the consequences of this view for RE research and practice.

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.

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.

An enterprise architecture (EA) is a high-level representation of an enterprise, used for managing the relation between business and IT. In order to improve the contribution of IT to the business, all elements of an EA should be traceable to the business model and vice versa. However, in practice this is not the case. In addition to reasoning about cost structures and goal contributions of IT to the business, as is customary in EA, traceability would allow practitioners to reason about the contribution of IT to the value offerings of a business. In this research paper we present the results from an experiment where we wanted to refine guidelines for transforming a business model into an EA that we have derived in earlier research. Based on this experiment we refine the guidelines, identify building blocks for a business model (BM) based EA design and illustrate this with an example.

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.

Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries worldwide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents are common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.

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.

In addition to in-house applications, networked enterprises are increasingly using data and services from various external sources. Conversion of data to useful information and IT alignment with business goals are big challenges faced by these enterprises. Integration platforms (IPs) aid enterprises in solving such challenges. However, the large number of commercial and academic IPs currently available have created a new problem for enterprises, namely whether to build their own IP or buy/rent a existing IP. Also, how to choose from the plethora of different design/solution options that are available? This paper presents a study and analysis of 31 IPs to bring out best practices in IP design. Following a commonality analysis of IPs from different research domains, an IP reference architecture is proposed. The reference architecture will aid enterprises in making better IP design/solution choices. It can also contribute to IP research by acting as a common reference point for future IP analysis.

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.

This paper argues that for each advance in RE that has been made in the past 1000 years, the older practices were not replaced but still exist, and need to be studied empirically.

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.

Software energy efficiency is a research topic where experimentation is widely adopted. Nevertheless, current studies and research approaches struggle to find generalizable findings that can be used to build a consistent knowledge base for energy-efficient software. To this end, we will discuss how to combine the traditional hypothesis-driven (top-down) approach with a bottom-up discovery approach. In this technical briefing, participants will learn the challenges that characterize the research in software energy efficiency. They will experience the complexity in this field and its implications for experimentation.

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.

Since 2003, an award has been presented annually at the IEEE International Requirements Engineering Conference for the Most Influential Paper presented at the conference 10 years previously. In 2013, we celebrate 21 years of the Requirements Engineering Conference, and we use this as an opportunity to reflect on the Most Influential Papers to date. Two sessions of the 2013 conference highlight the work of previous award winners and provide the authors with the opportunity to describe the trajectory of their work over the ten years that led to the award, and to discuss its impact since.

This position paper argues that industry tracks have no place in any research conference. Instead, a research conference should always have room for industrial case studies, evaluated according to criteria for empirical research. Such case studies would not be acceptable at a practitioners' industrial conference, just as papers presented at such conferences would not be acceptable at research conferences. It follows as corollary that if researchers want to become familiar with problems and solutions of RE practice, they should visit industrial conferences.

In this paper we consider service-oriented applications composed of component services provided by different, economically independent service providers. As in all composite applications, the component services are composed and configured to meet requirements for the composite application. However, in a field experiment of composite service-oriented applications wef found that, although the services as actually delivered by the service providers meet their requirements, there is still a mismatch across service providers due to unstated assumptions, and that this mismatch causes an incorrect composite application to be delivered to end-users. Identifying and analyzing these initially unstated assumptions turns requirements engineering for service-oriented applications into risk analysis. In this paper, we describe a field experiment with an experimental service-oriented homecare system, in which unexpected behavior of the system turned up unstated assumptions about the contributing service providers. We then present an assumptions-driven risk identification method that can help identifying these risks, and we show how we applied this method in the second iteration of the field experiment. The method adapts some techniques from problem frame diagrams to identify relevant assumptions on service providers. The method is informal, and takes the “view from nowhere” in that it does not result in a specification of the component services, but for every component service delivers a set of assumptions that the service must satisfy in order to contribute to the overall system requirements. We end the paper with a discussion of generalizability of this method.

Abstract Model‐based design is a promising technique to improve the quality of software and the efficiency of the software development process. We are investigating how to efficiently model embedded software and its environment to verify the requirements for the system controlled by the software. The software environment consists of mechanical, electrical and other parts; modelling it involves learning how these parts work, deciding what is relevant to model and how to model it. It is not possible to fully automate these steps. There are general guidelines, but given that every modelling problem differs, much is left to the modeller's own preference, background and experience. Still, when the next generation of a system is designed, the new system will have common elements with its previous version. Therefore, lessons learned from the current model could inform future models. We propose a framework for identifying the non‐formal elements of knowledge, insights and a model itself, which can support modelling of the next system generation. We will present the application of our framework on an action research case – modelling mechanical parts of a paper‐inserting machine.

Abstract—Background: Current checklists for empirical soft-ware engineering cover either experimental research or case study research but ignore the many commonalities that ex-ist across all kinds of empirical research. Identifying these commonalities, and explaining why they exist, would enhance our understanding of empirical research in general and of the differences between experimental and case study research in particular. Aim: In this short paper we design a unified checklist for empirical research, that identify commonalities and differences between experimental and case study research. Method: We design the unified checklist as a specialization of the general engineering cycle, which itself is a special case of the rational choice cycle. The unified checklist is based on an analysis and integration of a number of existing checklists. Results: The current version of the checklist exhibits a shared structure of experimental and case study research. Conclusions: Although the checklist exhibits a shared underlying structure of empirical research, its limitations are that it ignores other research methods such as meta-research or surveys and that very little empirical validation of usability and utility of the checklist has been performed so far. We are currently performing one validation, and are planning additional ones. These validations will likely lead to improvements of the current proposal. Keywords-Empirical research methodology, unified checklist, experimental research, observational research I.

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.

A business web is a collection of enterprises designed to jointly satisfy a consumer need. A model that shows the creation, distribution, and consumption of goods or services of economic value in a business web is called value model. The goal of a value model is to help the stakeholders build a shared understanding of the business case and assess the potential profitability of collaboration in the business web. The participating stakeholders in a business web are assumed to act trustfully in the collaboration and therefore trust is left entirely outside the picture. However the assumption that stakeholders act trustfully is often not useful in practice (since there are malicious actors). In this paper we consider business webs from a trust perspective and introduce an approach for measuring the trustworthiness of the stakeholders participating in a business web.

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.

When showing that a software system meets certain security requirements, it is often necessary to work with formal and informal descriptions of the system behavior, vulnerabilities, and threats from potential attackers. In earlier work, Haley et al. [1] showed structured argumentation could deal with such mixed descriptions. However, incomplete and uncertain information, and limited resources force practitioners to settle for good-enough security. To deal with these conditions of practice, we extend the method of Haley et al. with risk assessment. The proposed method, RISA (RIsk assessment in Security Argumentation), uses public catalogs of security expertise to support the risk assessment, and to guide the security argumentation in identifying rebuttals and mitigations for security requirements satisfaction. We illustrate RISA with a realistic example of PIN Entry Device.

For today’s organisations, having a reliable information system is crucial to safeguard enterprise revenues (think of on-line banking, reservations for e-tickets etc.). Such a system must often offer high guarantees in terms of its availability; in other words, to guarantee business continuity, IT systems can afford very little downtime. Unfortunately, making an assessment of IT availability risks is difficult: incidents affecting the availability of a marginal component of the system may propagate in unexpected ways to other more essential components that functionally depend on them. General-purpose risk assessment (RA) methods do not provide technical solutions to deal with this problem. In this paper we present the qualitative time dependency (QualTD) model and technique, which is meant to be employed together with standard RA methods for the qualitative assessment of availability risks based on the propagation of availability incidents in an IT architecture. The QualTD model is based on our previous quantitative time dependency (TD) model (Zambon et al. in BDIM ’07: Second IEEE/IFIP international workshop on business-driven IT management. IEEE Computer Society Press, pp 75–83, 2007), but provides more flexible modelling capabilities for the target of assessment. Furthermore, the previous model required quantitative data which is often too costly to acquire, whereas QualTD applies only qualitative scales, making it more applicable to industrial practice. We validate our model and technique in a real-world case by performing a risk assessment on the authentication and authorisation system of a large multinational company and by evaluating the results with respect to the goals of the stakeholders of the system. We also perform a review of the most popular standard RA methods and discuss which type of method can be combined with our technique.

Increasingly, organizations collaborate with other organizations in value webs with various arrangements, such as outsourcing, partnering, joint ventures, or subcontracting. As the Jericho Forum (an industry consortium of the Open Group) observed, in all these forms of collaboration, the boundaries between organizations become permeable and, as a consequence, insiders and outsiders can no longer be neatly separated using the notion of a perimeter. Such organizational arrangements have security implications because individuals from the value web are neither outsiders nor completely insiders. To address this phenomenon this paper proposes a third set of individuals, called External Insiders. External insiders add challenges to the already known insider threat problem because, unlike outsiders, external insiders have granted access and are trusted; and, unlike traditional insiders, external insiders are not subjected to as many internal controls enforced by the organization for which they are external insiders. In fact, external insiders are part of two or more organizational control structures, and business-to-business contracts are often insufficiently detailed to establish security requirements at the level of granularity needed to counter the threat they pose.

CRAC is an IT-infrastructure-based method for assessing and comparing confidentiality risks of distributed IT systems. The method determines confidentiality risks by taking into account the effects of the leakage of confidential information (e.g. industrial secrets), and the paths that may be followed by different attackers (e.g. insider and outsider). We evaluate its effectiveness by applying it to a real-world outsourcing case.

Design scientists have to balance the demands of methodological rigor that they share with purely curiosity-driven scientists, with the demands of practical utility that they share with utility-driven engineers. Balancing these conflicting demands can be conceptually complex and may lead to methodological mistakes. For example, treating a design question as an empirical research question may lead to researcher to omit the identification of the practical problem to solve, to omit the identification of stakeholder-motivated evaluation criteria, or to omit trade-off and sensitivity analysis. This tutorial aims to clear up this methodological mist in the case of software engineering (SE) research.

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.

Today, companies are required to be in control of their IT assets, and to provide proof of this in the form of independent IT audit reports. However, many companies have outsourced various parts of their IT systems to other companies, which potentially threatens the control they have of their IT assets. To provide proof of being in control of outsourced IT systems, the outsourcing client and outsourcing provider need a written service level agreement (SLA) that can be audited by an independent party. SLAs for availability and response time are common practice in business, but so far there is no practical method for specifying confidentiality requirements in an SLA. Specifying confidentiality requirements is hard because in contrast to availability and response time, confidentiality incidents cannot be monitored: attackers who breach confidentiality try to do this unobserved by both client and provider. In addition, providers usually do not want to reveal their own infrastructure to the client for monitoring or risk assessment. Elsewhere, we have presented an architecture-based method for confidentiality risk assessment in IT outsourcing. In this paper, we adapt this method to confidentiality requirements specification, and present a case study to evaluate this new method.

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.

Inter-organizational cooperations are complex in terms of coordination, agreements, and value creation for involved partners. When managing complex cooperations, it is vital to maintain models describing them. Changing one model to regain consistency with the running system might result in new inconsistencies. As a consequence, this maintenance phase grows in complexity with increasing number of models. In this context, challenges are to ensure consistency at design time and to monitor the system at runtime, i.e., at design time, consistency between different models describing the cooperation needs to be ensured. At runtime, behavior of the software system needs to be compared with its underlying models. In this paper, we propose a structured and model-independent method that supports ensuring and maintaining consistency between running system and underlying models for inter-organizational cooperations.

Attack graphs are an important support for assessment and subsequent improvement of network security. They reveal possible paths an attacker can take to break through security perimeters and traverse a network to reach valuable assets deep inside the network. Although scalability is no longer the main issue, Attack Graphs still have some problems that make them less useful in practice. First, Attack Graphs remain difficult to relate to the network topology. Second, Attack Graphs traditionally only consider the exploitation of vulnerable hosts. Third, Attack Graphs do not rely on automatic identification of potential attack targets. We address these gaps in our MsAMS (Multi-step Attack Modelling and Simulation) tool, based on Mobile Ambients. The tool not only allows the modelling of more static aspects of the network, such as the network topology, but also the dynamics of network attacks. In addition to Mobile Ambients, we use the pagerank algorithm to determine targets and hub scores produced by the HITS (Hypertext Induced Topic Search) algorithm to guide the simulation of an attacker searching for targets.

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.

Scientific evaluation papers investigate existing problem situations or validate proposed solutions with scientific means, such as by experiment or case study. There is a growing amount of literature about how to report about empirical research in software engineering, but there is still some confusion about the difference between a scientific evaluation paper and other kinds of research papers. This is related to lack of clarity about the relation between empirical research, engineering, and industrial practice. In this minitutorial we give a brief rundown on how to structure a scientific evaluation papers as a special kind of research paper, using experiment reports and case study reports as examples. We give checklists of items that a reader should be able to find in these papers, and sketch the dilemmas that writers and readers of these papers face when applying these checklists.

In recent years, the automation of business processes has become one of the most prominent and promising uses of Web service technology. Consequently several languages have been created for the execution of business processes, making it possible to define new and more complex services or business processes which are implemented for example by means of Web service composition. Nevertheless, these kinds of languages are not suitable for use in the early stages of the development process of information systems. Special methodologies or techniques are therefore necessary to allow systems analysts to understand services from a business point of view, while facilitating the design and development of Web service composition. In this paper, we present a service-oriented approach to information system development that starts by identifying, through business modeling, the services required by the customers of a business, to make it possible to create a Web service composition model. This model will facilitate the transformation to specific languages for business process execution, thereby reducing the development efforts made in service-oriented applications. The method proposed is illustrated by means of a Web application for the management of medical images, which we have taken as a case study.

Electronic service bundles such as Internet access and voice over IP become increasingly important for the economy. The requirements engineering problem is how to compose an e-service bundle such that consumer needs are met optimally, and the suppliers provide the services economically sustainable. We propose a technique to match a consumer need with a multi-supplier bundle of commercial e-services, which we illustrate by means of a telecommunication case study.

For several decades there has been a debate in the computing sciences about the relative roles of design and empirical research, and about the contribution of design and research methodology to the relevance of research results. In this minitutorial we review this debate and compare it with evidence about the relation between design and research in the history of science and technology. Our review shows that research and design are separate but concurrent activities, and that relevance of research results depends on problem setting rather than on rigorous methods. We argue that rigorous scientific methods separate design from research, and we give simple model for how to do this in a problem-driven way.

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.

In many industries, the adoption of technology developed at universities and independent research labs is the prevalent paradigm. However, in the software space, this is a relatively rare occurrence. In many cases, academic software engineering tends to lag rather than lead commercial developments. The goal of this Workshop is to open a dialouge between researchers and practitioners to address this problem.

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

In goal-oriented requirements engineering (GORE), one usually proceeds from a goal analysis to a requirements specification, usually of IT systems. In contrast, we consider the use of GORE for the design of IT-enabled value constellations, which are collections of enterprises that jointly satisfy a consumer need using information technology. The requirements analysis needed to do such a cross-organizational design not only consists of a goal analysis, in which the relevant strategic goals of the participating companies are aligned, but also of a value analysis, in which the commercial sustainability of the constellation is explored. In this paper we investigate the relation between strategic goal- and value modeling. We use theories about business strategy such as those by Porter to identify strategic goals of a value constellation, and operationalize these goals using value models. We show how value modeling allows us to find more detailed goals, and to analyze conflicts among goals

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.

Ambient intelligent (AmI) systems are electronic environments that are responsive and sensitive to the presence of people (Weiser, 1991). Eliciting requirements for AmI systems, like for any novel technology, is hard because of high uncertainties, such as: 1) both the users and use context are unknown; 2) there is no identified problem that needs to be solved (people cannot state in advance what they want); 3) there is no product idea; 4) it is unclear what future technology can do. There are currently no requirements engineering method for novel AmI technologies. In this short note, we present the current state of our research, which aims at defining a method for identifying requirements for AmI systems.

We want to explore and analyse design decisions that influence maintainability of software. Software maintainability is important because the effort expended on changes and fixes in software is a major cost driver. We take an empirical, qualitative approach, by investigating cases where a change has cost more or less than comparable changes, and analysing the causes for those differences. We will use this analysis of causes as input to following research in which the individual contributions of a selection of those causes will be quantitatively analysed.

This paper presents a framework for architecture alignment that can be positioned between approaches for software architecture, which concern software artefacts only, and strategic alignment models, which have a business focus. The framework is currently applied in case study research to find alignment patterns used in practice. First results presented in this paper indicate that the framework might yield an operationalization of strategic architecture alignment models. We also present an alignment pattern which shows a difference between how architectures are designed at the application level and the infrastructure level. We think this difference is significant for practical alignment models.

We describe a tool that supports verification of workflow models specified in UML activity diagrams. The tool translates an activity diagram into an input format for a model checker according to a mathematical semantics. With the model checker, arbitrary propositional requirements can be checked against the input model. If a requirement fails to hold, an error trace is returned by the model checker, which our tool presents by highlighting a corresponding path in the activity diagram. We summarize our formal semantics, discuss the techniques used to reduce an infinite state space to a finite one, and motivate the need for strong fairness constraints to obtain realistic results. We define requirement-preserving rules for state space reduction. Finally, we illustrate the whole approach with a few example verifications.

The Second International Workshop on From SofTware Requirements to Architectures (STRAW'03) was held in Portland, Oregon, USA on 9 May 2003 just after the Twenty-Fifth International Conference on Software Engineering (ICSE'03). This brief paper outlines the motivation, goals, and organization of the workshop.

We describe a tool that supports verification of workflow models specified in UML activity graphs. The tool translates an activity graph into an input format for a model checker according to a semantics we published earlier. With the model checker arbitrary propositional requirements can be checked against the input model. If a requirement fails to hold an error trace is returned by the model checker. The tool automatically translates such an error trace into an activity graph trace by high-lighting a corresponding path in the activity graph. One of the problems that is dealt with is that model checkers require a finite state space whereas workflow models in general have an infinite state space. Another problem is that strong fairness is necessary to obtain realistic results. Only model checkers that use a special model checking algorithm for strong fairness are suitable for verifying workflow models. We analyse the structure of the state space. We illustrate our approach with some example verifications.

In this paper, we present the logic ATCTL, which is intended to be used for model checking models that have been specified in a lightweight version of the Unified Modelling Language (UML). Elsewhere, we have defined a formal semantics for LUML to describe the models. This paper's goal is to give a specification language for properties that fits LUML; LUML includes states, actions and real time. ATCTL extends CTL with concurrent actions and real time. It is based on earlier extensions of CTL by De Nicola and Vaandrager (ACTL) and Alur et al. (TCTL). This makes it easier to adapt existing model checkers to ATCTL. To show that we can check properties specified in ATCTL in models specified in LUML, we give a small example using the Kronos model checker.

A conceptual model of a system is an explicit description of the behaviour required of the system. Methods for conceptual modelling include entity-relationship (ER) modelling, data flow modelling, Jackson System Development (JSD) and several object-oriented analysis methods. Given the current diversity of modelling methods, it is important for teaching as well as using these methods to know what the relationships between them is and to be able to indicate what the (im)possibilities of integrating different methods are. This paper compares three classical modelling methods (ER, data flow, JSD) on their possibilities for integration and combination. It is shown that there is a common core of these methods, which centres around the concept of system transaction and that unifies the static view of a system taken by ER modelling, with the dynamic view taken by JSD and the functional view taken by data flow modelling. Several object-oriented analysis methods integrate these three views. This paper illustrates how this is done in the analysis stage of Object Modelling Technique. Finally, it is shown that the transaction decomposition table can be used as a pivot around which to combine different methods. The results of this paper can be used in teaching to explain the relationships and differences between the methods analysed here, and in system development practice to ease the transition from structured to object-oriented methods.

Abstract The use of logic in database theory is commonly restricted to the specification of database states. Reasoning about state changes (the database updates) must then be done outside the logic. In this report, we consider a logic that also takes the updates into account. Taking propostional dynamic logic as a starting point, we define PDDL: prepositional dynamic database logic. The main features of PDDL are: •There are two kinds of atomic updates in PDDL, passive and active updates. Passive updates just change the truth value of an atom to true/false and active updates set one atom to true/false and then compute derived updates using a logic program. Just like the atomic actions of dynamic logic, the atomic updates can be combined into update programs with the operators sequential composition, choice and iteration. We have one more update action (also present in dynamic logic): the test of a formula. •The declarative semantics for formulas and updates, is based on Kripke structures. Because of the specific language of updates, we have many properties of the semantics that are not present in propositional dynamic logic (PDL). One of these properties is that we can identify worlds with the same valuation in a structure, the resulting structure is called normalized, and it is equivalent to the original structure. •We have a proof system for PDDL which is soundand complete for the class of ‘full’ structures. For non-full structures, the main problem is the axiomatization of successor worlds. For the most interesting class of (non-full) structures given some set of constraints, we give a reduction of the non-full case to the full case. •We have a Plotkin-style operational semantics for update programs. The operational semantics allows us to compute the result of executing an update in some database state. A database state is a set of (propositional) formulas and specifies some subset of the worlds in a structure (the worlds in whichs the database state is true). The operational and declarative semantics are shown to be equivalent.