Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to main content
Continuously achieving and maintaining competitive advantage is the critical survival factor for software-intensive product development companies undergoing digitalization transformation. These companies remain uncertain if investments in... more
Continuously achieving and maintaining competitive advantage
is the critical survival factor for software-intensive product development
companies undergoing digitalization transformation. These companies
remain uncertain if investments in business modeling is sucient to
cope with rapidly changing business models, technology, and customer
demands. We conducted a Systematic Literature Review using the snowballing
methodology to explore the e ects of business modeling on business

exibility and variability in the realization. Our results con rm a
research gap regarding translating desired strategic
exibility into business
options that can eciently and e ectively be implemented using
software-based variability in the realization. We conclude that more research
is needed consolidating business model innovation, experimentation,
and operationalization. Building on theories for learning and knowledge
creation, we propose a framework for describing change and analyzing
strategic, tactical and operational choices in business model experimentation.
Deep Neural Networks (DNN) will emerge as a cornerstone in automotive software engineering. However , developing systems with DNNs introduces novel challenges for safety assessments. This paper reviews the state-of-the-art in verification... more
Deep Neural Networks (DNN) will emerge as a cornerstone in automotive software engineering. However , developing systems with DNNs introduces novel challenges for safety assessments. This paper reviews the state-of-the-art in verification and validation of safety-critical systems that rely on machine learning. Furthermore, we report from a workshop series on DNNs for perception with automotive experts in Sweden, confirming that ISO 26262 largely contravenes the nature of DNNs. We recommend aerospace-to-automotive knowledge transfer and systems-based safety approaches, e.g., safety cage architectures and simulated system test cases.
Research Interests:
[Context] Quality requirements are important for product success yet often handled poorly. The problems with scope decision lead to delayed handling and an unbalanced scope. [Objective] This study characterizes the scope decision process... more
[Context] Quality requirements are important for product success yet often handled poorly. The problems with scope decision lead to delayed handling and an unbalanced scope. [Objective] This study characterizes the scope decision process to understand influencing factors and properties affecting the scope decision of quality requirements. [Method] We studied one company's scope decision process over a period of five years. We analyzed the decisions artifacts and interviewed experienced engineers involved in the scope decision process. [Results] Features addressing quality aspects explicitly are a minor part (4.41%) of all features handled. The phase of the product line seems to influence the prevalence and acceptance rate of quality features. Lastly, relying on external stake-holders and upfront analysis seems to lead to long lead-times and an insufficient quality requirements scope. [Conclusions] There is a need to make quality mode explicit in the scope decision process. We propose a scope decision process at a strategic level and a tactical level. The former to address long-term planning and the latter to cater for a speedy process. Furthermore, we believe it is key to balance the stakeholder input with feedback from usage and market in a more direct way than through a long plan-driven process.
In this study, we investigate the state of the literature and practice about Value-Based Requirements Engineering. We focus on identifying what models for VBRE were presented and what challenges were discussed. We triangulate our results... more
In this study, we investigate the state of the literature and practice about Value-Based Requirements Engineering. We focus on identifying what models for VBRE were presented and what challenges were discussed. We triangulate our results with industrial practitioners by conducting an industrial survey with 59 respondents. We identified 26 primary and 3 secondary studies and synthesized the findings using content analysis. VBRE was identified to be having a positive impact among survey practitioners. However, challenges like aligning product, project and organization opinions, selecting a most valuable requirement for a particular release, and including time-dependent requirements were identified to be impacting the organizations. The results from the study also suggest that, value dimensions like stakeholder value and customer value were not so frequently discussed in RE processes in both literature and among our industry respondents.
Research Interests:
Background: Achieving and maintaining a strategic competitive advantage through business and technology innovation via continually improving effectiveness and efficiency of the operations are the critical survival factors for... more
Background: Achieving and maintaining a strategic competitive advantage through business and technology innovation via continually improving effectiveness and efficiency of the operations are the critical survival factors for software-intensive product development companies. These companies invest in business modeling and tool support for integrating business models into their product development, but remain uncertain, if such investments generate desired results. Aim: This study explores the effects of business modeling on effectiveness and efficiency for companies developing software-intensive products. Method: We conducted a systematic literature review using the snowballing methodology, followed by thematic and narrative analysis. 57 papers were selected for analysis and synthesis, after screening 16 320 papers from multiple research fields. Results: We analyzed the literature based on purpose, benefit, challenge, effectiveness, and efficiency with software and software-intensive products as the unit of analysis. The alignment between strategy and execution is the primary challenge, and we found no evidence that business modeling increases effectiveness and efficiency for a company. Any outcome variations may simply be a result of fluctuating contextual or environmental factors rather than the application of a specific business modeling method. Therefore, we argue that governance is the fundamental challenge needed for business modeling, as it must efficiently support simultaneous experimentation with products and business models while turning experiences into knowledge. Conclusion: We propose a conceptual governance model for exploring the effectiveness and efficiency of business modeling to occupy the missing link between business strategy, processes and software tools. We also recommend managers to introduce a systematic approach for experimentation and organizational learning, collaboration, and value co-creation.
Research Interests:
Background: Software testing benefits from the usage of Knowledge Management (KM) methods and principles. Thus, there is a need to adopt KM to the software testing core processes and attain the benefits that it provides in terms of cost,... more
Background: Software testing benefits from the usage of Knowledge Management (KM) methods and principles. Thus, there is a need to adopt KM to the software testing core processes and attain the benefits that it provides in terms of cost, quality, etc. Aim: To investigate the usage and implementation of KM for software testing. The major objectives include 1. To identify various software testing aspects that receive more attention while applying KM. 2. To analyse multiple software testing techniques, i.e. test design, test execution and test result analysis and highlight KM involvement in these. 3. To gather challenges faced by industry due to the lack of KM initiatives in software testing. Method: A Systematic Literature Review (SLR) was conducted utilizing the guidelines for snowballing reviews by Wohlin. The identified studies were analysed in relation to their rigor and relevance to assess the quality of the results. Results: The initial resulting set provided 4832 studies. From these, 35 peer-reviewed papers were chosen among which 31 are primary, and 4 are secondary studies. The literature review results indicated nine testing aspects being in focus when applying KM within various adaptation contexts and some benefits from KM application. Several challenges were identified, e.g., improper selection and application of better-suited techniques, a low reuse rate of software testing knowledge, barriers in software testing knowledge transfer, no possibility to quickly achieve the most optimum distribution of human resources during testing, etc. Conclusions: The study brings supporting evidence that the application of KM in software testing is necessary, e.g., to increase test effectiveness, select and apply testing techniques. The study outlines the testing aspects and testing techniques that benefit their users.
Research Interests:
Context: The development of software-intensive systems includes many decisions involving various stakeholders with often conflicting interests and viewpoints. Objective: Decisions are rarely systematically documented and sporadically... more
Context: The development of software-intensive systems includes many decisions involving various stakeholders with often conflicting interests and viewpoints. Objective: Decisions are rarely systematically documented and sporadically explored. This limits the opportunity for learning and improving on important decisions made in the development of software-intensive systems. Method: In this work, we enable support for the systematic documentation of decisions, improve their traceability and contribute to potentially improved decision-making in strategic, tactical and operational contexts. Results: We constructed a taxonomy for documentation supporting decision-making, called GRADE. GRADE was developed in a research project that required composition of a common dedicated language to make feasible the identification of new opportunities for better decision support and evaluation of multiple decision alternatives. The use of the taxonomy has been validated through thirty three decision cases from industry. Conclusion: This paper occupies this important yet greatly unexplored research gap by developing the GRADE taxonomy that serves as a common vocabulary to describe and classify decision-making with respect to architectural assets.
Research Interests:
Knowledge-intensive companies that adopt Agile Software Development (ASD) relay on efficient implementation of Knowledge Management (KM) strategies to promotes different Knowledge Processes (KPs) to gain competitive advantage. This study... more
Knowledge-intensive companies that adopt Agile Software Development (ASD) relay on efficient implementation of Knowledge Management (KM) strategies to promotes different Knowledge Processes (KPs) to gain competitive advantage. This study aims to explore how companies that adopt ASD implement KM strategies utilizing practices that promote the KPs in the different organizational layers. Through a systematic literature review, we analyzed 32 primary studies, selected by automated search and snowballing in the extant literature. To analyze the data, we applied narrative synthesis. Most of the identified KM practices implement personalization strategies (81%), supported by codification (19%). Our review shows that the primary studies do not report KM practices in the strategic layer and two of them in the product portfolio layer; on the other hand, in the project layer, the studies report 33 practices that implement personalization strategy, and seven practices that implement codification. KM strategies in ASD promote mainly the knowledge transfer process with practices that stimulates social interaction to share tacit knowledge in the project layer. As a result of using informal communication, a significant amount of knowledge can be lost or not properly transferred to other individuals and, instead of propagating the knowledge, it remains inside a few individuals' minds.
Research Interests:
Context. The increased popularity of Open Source Software (OSS) is affecting how software-intensive product development organizations (SIPDO) innovate and compete. Participation in OSS communities greatly dismantled the closed innovation... more
Context. The increased popularity of Open Source Software (OSS) is affecting how software-intensive product development organizations (SIPDO) innovate and compete. Participation in OSS communities greatly dismantled the closed innovation model and pushed SIPDOs towards Open Innovation (OI). Harnessing the potential that OI offers, requires better understanding regarding what to develop internally and what to acquire from outside the organization, how to cooperate with potential competitors, and when to conceal or reveal code while working with OSS communities. Aim. This paper aims at synthesizing a theory of openness for software engineering tools in SIPDOs, that can be utilized by managers in setting more efficient strategies towards OSS communities. Method. This paper synthesizes empirical evidence from a systematic mapping study, a case study, and a survey, using a narrative method. The synthesis method entails four steps: (1) Developing a preliminary synthesis, (2) Exploring the relationship between studies, (3) Assessing the validity of synthesis, and (4) Theory formation. Result. This paper presents a theory of openness for OSS tools in software engineering in relation to the four constructs: (1) Strategy, (2) Triggers, (3) Outcomes, and (4) Level of openness. Conclusion. The theory reasons that openness provides opportunities to reduce the development cost and development time. Furthermore, OI pos-Email addresses: hussan.munir@cs.lth.se (Hussan Munir), per.runeson@cs.lth.se (Per Runeson), krzysztof.wnuk@bth.se (Krzysztof Wnuk) A u t h o r s ' c o p y itively impacts on process and product innovation, but it requires investment by organizations in OSS communities. By betting on openness, organizations may be able to significantly increase their competitiveness.
Research Interests:
[Context and motivation] Quality requirements (QRs) are inherently difficult to manage as they are often subjective, context-dependent and hard to fully grasp by various stakeholders. Furthermore, there are many sources that can provide... more
[Context and motivation] Quality requirements (QRs) are inherently difficult to manage as they are often subjective, context-dependent and hard to fully grasp by various stakeholders. Furthermore, there are many sources that can provide input on important QRs and suitable levels. Responding timely to customer needs and realizing them in product portfolio and product scope decisions remain the main challenge. [Question/problem] Data-driven methodologies based on product usage data analysis gain popularity and enable new (bottom-up, feedback-driven) ways of planning and evaluating QRs in product development. Can these be efficiently combined with established top-down, forward-driven management of QRs? [Principal idea / Results] We propose a model for how to handle decisions about QRs at a strategic and operational level, encompassing product decisions as well as business intelligence and usage data. We inferred the model from an extensive empirical investigation of five years of decision making history at a large B2C company. We illustrate the model by assessing two industrial case studies from different domains. [Contribution] We believe that utilizing the right approach in the right situation will be key for handling QRs, as both different groups of QRs and domains have their special characteristics.
Research Interests:
Research Interests:
Selecting sourcing options for software assets and components is an important process that helps companies to gain and keep their competitive advantage. The sourcing options include: in-house, COTS, open source and outsourcing. The... more
Selecting sourcing options for software assets and components is an important process that helps companies to gain and keep their competitive advantage. The sourcing options include: in-house, COTS, open source and outsourcing. The objective of this paper is to further refine, extend and validate a solution presented in our previous work. The refinement includes a set of decision-making activities, which are described in the form of a process-line that can be used by decision-makers to build their specific decision-making process. We conducted five case studies in three companies to validate the coverage of the set of decision-making activities. The solution in our previous work was validated in two cases in the first two companies. In the validation, it was observed that no activity in the proposed set was perceived to be missing, although not all activities were conducted and the activities that were conducted were not executed in a specific order. Therefore, the refinement of the solution into a process-line approach increases the flexibility and hence it is better in capturing the differences in the decision-making processes observed in the case studies. The applicability of the process-line was then validated in three case studies in a third company.
Research Interests:
Background: Achieving and maintaining a strategic competitive advantage through business and technology innovation via continually improving effectiveness and efficiency of the operations are the critical survival factors for... more
Background: Achieving and maintaining a strategic competitive advantage through business and technology innovation via continually improving effectiveness and efficiency of the operations are the critical survival factors for software-intensive product development companies. These companies invest in business modeling and tool support for integrating business models into their product development, but remain uncertain, if such investments generate desired results. Aim: This study explores the effects of business modeling on effectiveness and efficiency for companies developing software-intensive products. Method: We conducted a systematic literature review using the snowballing methodology, followed by thematic and narrative analysis. 57 papers were selected for analysis and synthesis, after screening 16 320 papers from multiple research fields. Results: We analyzed the literature based on purpose, benefit, challenge, effectiveness, and efficiency with software and software-intensive products as the unit of analysis. The alignment between strategy and execution is the primary challenge, and we found no evidence that business modeling increases effectiveness and efficiency for a company. Any outcome variations may simply be a result of fluctuating contextual or environmental factors rather than the application of a specific business modeling method. Therefore, we argue that governance is the fundamental challenge needed for business modeling, as it must efficiently support simultaneous experimentation with products and business models while turning experiences into knowledge. Conclusion: We propose a conceptual governance model for exploring the effectiveness and efficiency of business modeling to occupy the missing link between business strategy, processes and software tools. We also recommend managers to introduce a systematic approach for experimentation and organizational learning, collaboration, and value co-creation.
Research Interests:
Background: Software testing benefits from the usage of Knowledge Management (KM) methods and principles. Thus, there is a need to adopt KM to the software testing core processes and attain the benefits that it provides in terms of cost,... more
Background: Software testing benefits from the usage of Knowledge Management (KM) methods and principles. Thus, there is a need to adopt KM to the software testing core processes and attain the benefits that it provides in terms of cost, quality, etc. Aim: To investigate the usage and implementation of KM for software testing. The major objectives include 1. To identify various software testing aspects that receive more attention while applying KM. 2. To analyse multiple software testing techniques, i.e. test design, test execution and test result analysis and highlight KM involvement in these. 3. To gather challenges faced by industry due to the lack of KM initiatives in software testing. Method: A Systematic Literature Review (SLR) was conducted utilizing the guidelines for snowballing reviews by Wohlin. The identified studies were analysed in relation to their rigor and relevance to assess the quality of the results. Results: The initial resulting set provided 4832 studies. From these, 35 peer-reviewed papers were chosen among which 31 are primary, and 4 are secondary studies. The literature review results indicated nine testing aspects being in focus when applying KM within various adaptation contexts and some benefits from KM application. Several challenges were identified, e.g., improper selection and application of better-suited techniques, a low reuse rate of software testing knowledge, barriers in software testing knowledge transfer, no possibility to quickly achieve the most optimum distribution of human resources during testing, etc. Conclusions: The study brings supporting evidence that the application of KM in software testing is necessary, e.g., to increase test effectiveness, select and apply testing techniques. The study outlines the testing aspects and testing techniques that benefit their users.
Research Interests:
Requirements Engineering (RE) has grown from its humble beginnings to embrace a wide variety of techniques, drawn from many disciplines, and the diversity of tasks currently performed under the label of RE has grown beyond that... more
Requirements Engineering (RE) has grown from its humble beginnings to embrace a wide variety of techniques, drawn from many disciplines, and the diversity of tasks currently performed under the label of RE has grown beyond that encom-passed by software development. We briefly review how RE has evolved and observe that RE is now a collection of best practices for pragmatic, outcome-focused critical thinking – applicable to any domain. We discuss an alternative perspective on, and de-scription of, the discipline of RE and advocate for the evolution of RE toward a discipline that supports the application of RE prac-tice to any domain. We call upon RE practitioners to proactively engage in alternative domains and call upon researchers that adopt practices from other domains to actively engage with their inspiring domains. For both, we ask that they report upon their experience so that we can continue to expand RE frontiers.
Research Interests:
— Requirements Engineering (RE) has grown from its humble beginnings to embrace a wide variety of techniques, drawn from many disciplines, and the diversity of tasks currently performed under the label of RE has grown beyond that... more
— Requirements Engineering (RE) has grown from its humble beginnings to embrace a wide variety of techniques, drawn from many disciplines, and the diversity of tasks currently performed under the label of RE has grown beyond that encompassed by software development. We briefly review how RE has evolved and observe that RE is now a collection of best practices for pragmatic, outcome-focused critical thinking – applicable to any domain. We discuss an alternative perspective on, and description of, the discipline of RE and advocate for the evolution of RE toward a discipline that supports the application of RE practice to any domain. We call upon RE practitioners to proactively engage in alternative domains and call upon researchers that adopt practices from other domains to actively engage with their inspiring domains. For both, we ask that they report upon their experience so that we can continue to expand RE frontiers.
Research Interests:
Despite growing interest of Open Innovation (OI) in Software Engineering (SE), little is known about what triggers software organizations to adopt it and how this affects SE practices. OI can be realized in numerous of ways, including... more
Despite growing interest of Open Innovation (OI) in Software Engineering (SE), little is known about what triggers software organizations to adopt it and how this affects SE practices. OI can be realized in numerous of ways, including Open Source Software (OSS) involvement. Outcomes from OI are not restricted to product innovation but also include process innovation, e.g. improved SE practices and methods. This study explores the involvement of a software organization (Sony Mobile) in OSS communities from an OI perspective and what SE practices (requirements engineering and testing) have been adapted in
relation to OI. It also highlights the innovative outcomes resulting from OI. An exploratory embedded case study investigates how Sony Mobile use and contribute to Jenkins and Gerrit;
the two central OSS tools in their continuous integration tool chain. Quantitative analysis was performed on change log data from source code repositories in order to identify the top contributors and triangulated with the results from five semi-structured interviews to
explore the nature of the commits. The findings of the case study include five major themes: i) The process of opening up towards the tool communities correlates in time with a general adoption of OSS in the organization. ii) Assets not seen as competitive advantage nor a
source of revenue are made open to OSS communities, and gradually, the organization turns more open. iii) The requirements engineering process towards the community is informal and based on engagement. iv) The need for systematic and automated testing is still in its
infancy, but the needs are identified. v) The innovation outcomes included free features and maintenance, and were believed to increase speed and quality in development. Adopting OI
was a result of a paradigm shift of moving fromWindows to Linux. This shift enabled Sony Mobile to utilize the Jenkins and Gerrit communities to make their internal development process better for its software developers and testers.
Research Interests:
—When choosing components for software intensive systems decisions are made on multiple levels. On the highest level, the component's origin or source is chosen (e.g. In-house versus Components Off-The-Shelf), which answers the... more
—When choosing components for software intensive systems decisions are made on multiple levels. On the highest level, the component's origin or source is chosen (e.g. In-house versus Components Off-The-Shelf), which answers the question where to get a component from. In this study we investigate how practitioners choose among the component sourcing options. The case survey method has been used to elicit and synthesize the cases. The case survey method combines the advantages of surveys (capturing a larger set of cases) and case studies (capturing rich information about each case). Overall, 22 decision cases have been obtained. Decisions were prepared in a group of people, while the actual decision was individually made by managers or decision makers. Cost, performance, and system reliability stand out as the most common criteria. More than two decision criteria are frequently considered, which has to be taken into account when supporting sourcing decisions. The final decision was perceived negatively in nine cases and positively in seven cases, while in the remaining cases it was perceived as neither positive nor negative. There exists a mismatch between industrial processes and the solution proposed with respect to number of considered criteria and methods utilized for decision making.
This papers describe the Open Source Officer role and the experiences from introducing this role in several companies. We outline the role description, main responsibilities, and interfaces to other roles and organizations. We... more
This papers describe the Open Source Officer role and the experiences from introducing this role in several companies. We outline the role description, main responsibilities, and interfaces to other roles and organizations. We investigated the role in several organization and bring interesting discrepancies and overlaps of how companies operate with OSS.
Research Interests:
— Open Source Software (OSS) has substantial impact on how software-intensive firms develop products and deliver value to the customers. These companies need both strategic and operational support on how to adapt OSS as a part of their... more
— Open Source Software (OSS) has substantial impact on how software-intensive firms develop products and deliver value to the customers. These companies need both strategic and operational support on how to adapt OSS as a part of their products and how to adjust processes and organizations to increase the benefits from OSS participation. This work presents the key insights from the journey that Sony Mobile has made from a company developing proprietary software to a respected member of OSS communities. We framed the experiences into an Open Source Maturity Model that includes two scenarios: engineering-driven and business-driven open source. We outline the most important decisions, roles, processes and implications.
Research Interests:
Open Source Software (OSS) has substantial impact on how software-intensive firms develop products and deliver value to the customers. These companies need both strategic and operational support on how to adapt OSS as a part of their... more
Open Source Software (OSS) has substantial impact
on how software-intensive firms develop products and deliver
value to the customers. These companies need both strategic
and operational support on how to adapt OSS as a part of their
products and how to adjust processes and organizations to
increase the benefits from OSS participation. This work
presents the key insights from the journey that Sony Mobile
has made from a company developing proprietary software to
a respected member of OSS communities. We framed the
experiences into an Open Source Maturity Model that includes
two scenarios: engineering-driven and business-driven open
source. We outline the most important decisions, roles,
processes and implications.
Research Interests:
—When choosing components for software intensive systems decisions are made on multiple levels. On the highest level, the component's origin or source is chosen (e.g. In-house versus Components Off-The-Shelf), which answers the question... more
—When choosing components for software intensive systems decisions are made on multiple levels. On the highest level, the component's origin or source is chosen (e.g. In-house versus Components Off-The-Shelf), which answers the question where to get a component from. In this study we investigate how practitioners choose among the component sourcing options. The case survey method has been used to elicit and synthesize the cases. The case survey method combines the advantages of surveys (capturing a larger set of cases) and case studies (capturing rich information about each case). Overall, 22 decision cases have been obtained. Decisions were prepared in a group of people, while the actual decision was individually made by managers or decision makers. Cost, performance, and system reliability stand out as the most common criteria. More than two decision criteria are frequently considered, which has to be taken into account when supporting sourcing decisions. The final decision was perceived negatively in nine cases and positively in seven cases, while in the remaining cases it was perceived as neither positive nor negative. There exists a mismatch between industrial processes and the solution proposed with respect to number of considered criteria and methods utilized for decision making.
Research Interests:
Context: Software supporting an enterprise's business, also known as a business support system, needs to support the correlation of activities between actors as well as in uence the activities based on knowledge about the value networks... more
Context: Software supporting an enterprise's business, also known as a business support
system, needs to support the correlation of activities between actors as well as in
uence
the activities based on knowledge about the value networks in which the enterprise acts.
This requires the use of policies and rules to guide or enforce the execution of strategies
or tactics within an enterprise as well as in collaborations between enterprises. With the
help of policies and rules an enterprise is able to capture an actor's intent in its business
support system, and act according to this intent on behalf of the actor. Since the value
networks an enterprise is part of will change over time the business intents' life cycle
states might change. Achieving the changes in an e ective and ecient way requires
knowledge about the a ected intents and the correlation between intents.
Objective: The aim of the study is to identify how a business support system can support
continuous changes to business intents. The rst step is to nd a theoretical model which
serves as a foundation for intent-driven systems.
Method: We conducted a case study using a focus group approach with employees from
Ericsson. This case study was in
uenced by the spiral case study process.
Results: The study resulted in a model supporting continuous de nition and execution
of an enterprise. The model is divided into three layers; De ne, Execute, and a com-
mon governance view layer. This makes it possible to support continuous de nition and
execution of business intents and to identify the actors needed to support the business
intents' life cycles. This model is supported by a meta-model for capturing information
into viewpoints.
Conclusion: The research question is addressed by suggesting a solution supporting con-
tinuous de nition and execution of an enterprise as a model of value architecture compo-
nents and business functions. The results will a ect how Ericsson will build the business
studio for their next generation business support systems.
Keywords: business intent; actor; viewpoint; business support system; intent-driven system; context frame; compositional system; knowledge creation; case study; continuous
Research Interests:
—Requirements Engineering has recently been greatly influenced by the way how firms use Open Source Software (OSS) and Software Ecosystems (SECOs) as a part of their product development and business models. This is further emphasized by... more
—Requirements Engineering has recently been greatly influenced by the way how firms use Open Source Software (OSS) and Software Ecosystems (SECOs) as a part of their product development and business models. This is further emphasized by the paradigm of Open Innovation, which highlights how firms should strive to use both internal and external resources to advance their internal innovation and technology capabilities. The evolution from market-driven requirements engineering and management processes, has reshaped the understanding of what a requirement is, and how it is documented and used. In this work, we suggest a model for analyzing and managing requirements that is designed in the context of OSS and SECOs, including the advances and challenges that it brings. The model clarifies how the main stages of requirements engineering and management processes can be adjusted to benefit from the openness that the new context offers. We believe that the model is a first step towards the inevitable adaptation of requirements engineering to an open and informal arena, where processes and collaboration are decentralized, transparency and governance are the key success factors.
Research Interests:
Background. Despite growing interest of Open Innovation (OI) in Software Engineering (SE), little is known about what triggers software organizations to adopt it and how this affects SE practices. OI can be realized in numerous of ways,... more
Background. Despite growing interest of Open Innovation (OI) in Software Engineering (SE), little is known about what triggers software organizations to adopt it and how this affects SE practices. OI can be realized in numerous of ways, including Open Source Software (OSS) involvement. Outcomes from OI are not restricted to product innovation but also include process innovation, e.g. improved SE practices and methods. Aim. This study explores the involvement of a software organization (Sony Mobile) in OSS communities from an OI perspective and what SE practices (requirements engineering and testing) have been adapted in relation to OI. It also highlights the innovative outcomes resulting from OI. Method. An exploratory embedded case study investigates how Sony Mobile use and contribute to Jenkins and Gerrit; the two central OSS tools in their continuous integration tool chain. Quantitative analysis was performed on change log data from source code repositories in order to identify the top contributors and triangulated with the results from five semi-structured interviews to explore the nature of the commits. Results. The findings of the case study include five major themes: i) The process of opening up towards the tool communities correlates in time with a general adoption of OSS in the organization. ii) Assets not seen as competitive advantage nor a source of revenue are made open to OSS communities, and gradually, the organization turns more open. iii) The requirements engineering process towards the community is informal and based on engagement. iv) The need for systematic and automated testing is still in its infancy, but the needs are identified. v) The innovation outcomes included free features and maintenance, and were believed to increase speed and quality in development. Conclusion. Adopting OI was a result of a paradigm shift of moving from Windows to Linux. This shift enabled Sony Mobile to utilize the Jenkins and Gerrit communities to
Research Interests:
—Change Impact Analysis (CIA) during software evolution of safety-critical systems is a labor-intensive task. Several authors have proposed tool support for CIA, but very few tools were evaluated in industry. We present a case study on... more
—Change Impact Analysis (CIA) during software evolution of safety-critical systems is a labor-intensive task. Several authors have proposed tool support for CIA, but very few tools were evaluated in industry. We present a case study on ImpRec, a recommendation System for Software Engineering (RSSE), tailored for CIA at a process automation company. ImpRec builds on assisted tracing, using information retrieval solutions and mining software repositories to recommend development artifacts, potentially impacted when resolving incoming issue reports. In contrast to the majority of tools for automated CIA, ImpRec explicitly targets development artifacts that are not source code. We evaluate ImpRec in a two-phase study. First, we measure the correctness of ImpRec's recommendations by a simulation based on 12 years' worth of issue reports in the company. Second, we assess the utility of working with ImpRec by deploying the RSSE in two development teams on different continents. The results suggest that ImpRec presents about 40 percent of the true impact among the top-10 recommendations. Furthermore, user log analysis indicates that ImpRec can support CIA in industry, and developers acknowledge the value of ImpRec in interviews. In conclusion, our findings show the potential of reusing traceability associated with developers' past activities in an RSSE.
Research Interests:
Safety standards prescribe change impact analysis (CIA) during evolution of safety-critical software systems. Although CIA is a fundamental activity , there is a lack of empirical studies about how it is performed in practice. We present... more
Safety standards prescribe change impact analysis (CIA) during evolution of safety-critical software systems. Although CIA is a fundamental activity , there is a lack of empirical studies about how it is performed in practice. We present a case study on CIA in the context of an evolving automation system , based on 14 interviews in Sweden and India. Our analysis suggests that engineers on average spend 50-100 hours on CIA per year, but the effort varies considerably with the phases of projects. Also, the respondents presented different connotations to CIA and perceived the importance of CIA differently. We report the most pressing CIA challenges, and several ideas on how to support future CIA. However, we show that measuring the effect of such improvement solutions is non-trivial, as CIA is intertwined with other development activities. While this paper only reports preliminary results, our work contributes empirical insights into practical CIA.
Research Interests:
—Software architecture is no more a mere system specification as resulting from the design phase, but it includes the process by which its specification was carried out. In this respect, design decisions in component-based software... more
—Software architecture is no more a mere system specification as resulting from the design phase, but it includes the process by which its specification was carried out. In this respect, design decisions in component-based software engineering play an important role: they are used to enhance the quality of the system, keep the current market level, keep partnership relationships, reduce costs, and so forth. For non trivial systems, a recurring situation is the selection of an asset origin, that is if going for in-house, outsourcing, open-source, or COTS, when in the need of a certain missing functionality. Usually, the decision making process follows a case-by-case approach, in which historical information is largely neglected. This solution avoids the overhead of keeping detailed documentation about past decisions, but hampers consistency among multiple, possibly related, decisions. The ORION project aims at developing a decision support framework in which historical decision information plays a pivotal role: it is used to analyse current decision scenarios, take well-founded decisions, and store the collected data for future exploitation. In this paper, we outline the potentials of such a knowledge repository, including the information it is intended to be stored in it, and when and how to retrieve it within a decision case.
Research Interests:
Companies developing software are constantly striving to gain or keep their competitive advantage on the market. To do so, they should balance what to develop themselves and what to get from elsewhere, which may be software components or... more
Companies developing software are constantly striving to gain or keep their competitive advantage on the market. To do so, they should balance what to develop themselves and what to get from elsewhere, which may be software components or software services. These strategic decisions need to be aligned with business objectives and the capabilities and constraints of possible options. These sourcing options include: in-house, COTS, open source and outsourcing. The objective of this paper is to present an approach to support decision-makers in selecting appropriate types of origins in a specific case that maximizes the benefits of the selected business strategy. The approach consists of three descriptive models, as well as a decision process and a knowledge repository. The three models are a decision model that comprises three cornerstones (stakeholders, origins and criteria) and is based on a taxonomy for formulating decision models in this context, and two supporting models (property models and context models).
Research Interests:
Context. Internet of Things (IoT) technology is significantly impacting software business. Several contributions were made in the literature regarding IoT. However, the importance of various business model elements for IoT and the impact... more
Context. Internet of Things (IoT) technology is significantly impacting software business. Several contributions were made in the literature regarding IoT. However, the importance of various business model elements for IoT and the impact of IoT on requirements engineering activities remains greatly unexplored. This paper focuses on the impact of IoT on software business models and requirements engineering. The objectives for this research include: 1) summarizing the current business models for IoT, 2) analyzing the impact of IoT on software business models 3) analyzing the impact of IoT on requirements engineering. We conducted a systematic snowballing literature review, followed by an industrial survey. We identified 21 peer reviewed papers which were analyzed in relation to their rigor and relevance and received 56 survey responses. The results of the literature review indicate 9 business model elements that IoT literature focus on. Morevoer, 4 business model aspects were described with respect to the business model structure, context and governance. The industrial survey results highlighted that value proposition , followed by customer segmentation and revenue streams were the most important business model elements for IoT. Moreover, the survey results suggest that requirement management, requirement prioritization and requirement modeling and analysis are highly impacted by IoT.
Research Interests:
—In many application domains, critical systems must comply with safety standards. This involves gathering safety evidence in the form of artefacts such as safety analyses, system specifications, and testing results. These artefacts can... more
—In many application domains, critical systems must comply with safety standards. This involves gathering safety evidence in the form of artefacts such as safety analyses, system specifications, and testing results. These artefacts can evolve during a system's lifecycle, creating a need for impact analysis to guarantee that system safety and compliance are not jeopardised. Although extensive research has been conducted on change impact analysis and on safety evidence management, the knowledge about how safety evidence change impact analysis is addressed in practice is limited. This paper reports on a survey targeted at filling this gap by analysing the circumstances under which safety evidence change impact analysis is addressed, the tool support used, and the challenges faced. We obtained 97 valid responses representing 16 application domains, 28 countries, and 47 safety standards. The results suggest that most practitioners deal with safety evidence change impact analysis during system development and mainly from system specifications. Furthermore, the level of automation in the process is low and insufficient tool support is the most frequent challenge. Other notable findings include that the different artefact types used as safety evidence seem to co-evolve, the evolution of safety case should probably be better managed, and no commercial impact analysis tool has been reported as used for all artefact types. Finally, we identified over 20 areas where the state of the practice in safety evidence change impact analysis can be improved.
Research Interests:
Context: Requirements scoping is one of the key activities in requirements management but also a major risk for project management. Continuously changing scope may create a congestion state in handling the requirements inflow which causes... more
Context: Requirements scoping is one of the key activities in requirements management but also a major risk for project management. Continuously changing scope may create a congestion state in handling the requirements inflow which causes negative consequences, e.g. delays or scope creep. Objectives: In this paper, we look at requirements scoping literature outside Software Product Line (SPL) by exploring the current literature on the phenomenon, summarizing publication trends, performing thematic analysis and analyzing the strength of the evidence in the light of rigor and relevance assessment. Method: We run a Systematic Mapping Study (SMS) using snowballing procedure, supported by a database search for the start set identification, and identified 21 primary studies and 2 secondary studies. Results: The research interest in this area steadily increases and includes mainly case studies, validation or evaluation studies. The results were categorized into four themes: definitions, negative effects associated with scoping, challenges and identified methods/tools. The identified scope management techniques are also matched against the identified requirements scoping challenges.
Research Interests:
Making the right decisions is an essential part of software ecosystem governance. Decisions related to the governance of a software ecosystem can influence the health of the ecosystem and can result in fostering the success or greatly... more
Making the right decisions is an essential part of software ecosystem governance. Decisions related to the governance of a software ecosystem can influence the health of the ecosystem and can result in fostering the success or greatly contributing to the failure of the ecosystem. However, very few studies touch upon the decision making of software ecosystem governance. In this paper, we propose decomposing software ecosystem governance into three activities: input or data collection, decision making, and applying actions. We focus on the decision making activity of software ecosystem governance and review related literature consisted of software ecosystem governance, organizational decision making , and IT governance. Based on the identified studies, we propose a framework for defining the decision making strategies in the governance of software ecosystems. We identify five decision areas for software ecosystem governance and four archetypes describing the way decisions are taken for each decision area. We explain this matrix-based framework by providing examples from existing software ecosystems.
Research Interests:
Context: To remain competitive, innovative and to grow, companies must change from cost-based decision-making to value-based decision-making where the decisions taken maximize software value and support company's overall value creation.... more
Context: To remain competitive, innovative and to grow, companies must change from cost-based decision-making to value-based decision-making where the decisions taken maximize software value and support company's overall value creation. Objective: The objective of this paper is to complement and expand an existing classification of value aspects within the context of product management and development with additional aspects relating to value within the context of project management and development. Method: In this study, we present the results from a snowballing literature review that focuses on software value in software project management. In the research for relevance literature we focus on software value aspects different than cost as cost is widely used in project management literature to estimate value. Results: We have identified nine primary studies in two snowball iterations. From these studies, we derived three categories of value aspects: financial, risk analysis and process improvement based on value identification.
Research Interests:
Deciding the optimal project scope that fulfills the needs of the most important stakeholders is challenging due to a plethora of aspects that may impact decisions. Large companies that operate in rapidly changing environments experience... more
Deciding the optimal project scope that fulfills the needs of the most important stakeholders is challenging due to a plethora of aspects that may impact decisions. Large companies that operate in rapidly changing environments experience frequently changing customer needs which force decision makers to continuously adjust the scope of their projects. Change intensity is further fueled by fierce market competition and hard time-to-market deadlines. Staying in control of the changes in thousands of features becomes a major issue as information overload hinders decision makers K. Wnuk is with the TRANSACTIONS OF SOFTWARE ENGINEERING , VOL. XX, NO. XX, DATE 2 from rapidly extracting relevant information. This paper presents a visual technique, called Feature Survival Charts+ (FSC+), designed to give a quick and effective overview of the requirements scoping process for Very Large-Scale Requirements Engineering (VLSRE). FSC+ are applied at a large company with thousands of features in the database and supported the transition from plan-driven to a more dynamic and change-tolerant release scope management process. FSC+ provides multiple views, filtering, zooming, state-change intensity views, and support for variable time spans. Moreover, this paper introduces five decision archetypes deduced from the dataset and subsequently analyzed and the atomic decision visualization that shows the frequency of various decisions in the process. The capabilities and usefulness of FSC+, decision patterns (state changes that features undergo) and atomic decision visualizations are evaluated through interviews with practitioners who found utility in all techniques and indicated that their inherent flexibility was necessary to meet the varying needs of the stakeholders.
Research Interests:
—A properly formed requirement is testable, a necessity for ensuring that design goals are met. While challenging in productivity applications, entertainment applications such as games compound the problem due to their subjective nature.... more
—A properly formed requirement is testable, a necessity for ensuring that design goals are met. While challenging in productivity applications, entertainment applications such as games compound the problem due to their subjective nature. We report here on our efforts to create testable experience requirements , the associated scope challenges and challenges with test design and result interpretation. We further report on issues experienced when performing focus group testing and provide practitioner guidance.
Research Interests:
Context: Open innovation (OI) is considered a main driver for inventions in general, and its challenges are touching software producing organizations (SPO) when they are moving from a closed innovation model to more open approaches, to... more
Context: Open innovation (OI) is considered a main driver for inventions in general, and its challenges are touching software producing organizations (SPO) when they are moving from a closed innovation model to more open approaches, to accelerate their internal innovation process. Objective: This study aims to identify the OI state of the art in software engineering domain and report existing themes in the published research. Method: We launched a systematic mapping study and use existing themes of open innovation to conducted a thematic analysis. Moreover, the strength of the evidence was analyzed in the light of rigor and relevance criteria of research. Results: We identified 33 publications, divided into 9 distinct themes related to OI. We also found that 17 studies fall in the high–rigor/high–relevance category , suggesting the results are highly relevant to the industrial context. The research indicates that start-ups have higher tendency to opt OI compared to incumbents, however, evidence also suggests that firms familiar with absorp-tive capacity and assimilating knowledge into their internal R&D activities, has higher likelihood of gaining financial advantages. Conclusion: We concluded that OI should be adopted as complementary approach to facilitate internal innovation process and not to substitute it.
Research Interests:
SUMMARY Lead time, defined as the duration between the moment a request was filed to the moment the decision was made, is an important aspect of decision making in market-driven requirements engineering. Minimizing lead time allows... more
SUMMARY Lead time, defined as the duration between the moment a request was filed to the moment the decision was made, is an important aspect of decision making in market-driven requirements engineering. Minimizing lead time allows software companies to focus their resources on the most profitable functionality and enables them to remain competitive within the quickly-changing software market. Achieving and sustaining low decision lead time and the resulting high decision efficiency requires better understanding of factors that may affect both decision lead time and outcome. In order to identify possible factors, we conducted an exploratory two-stage case study that combines the statistical analysis of seven possible relationships among decision characteristics at a large company with a survey of industry participants. Our results show that the number of products affected by a decision increases the time needed to make a decision. Practitioners should take this aspect into consideration when planning for efficient decision making and possibly reducing the complexity of decisions. Our results also show that when a change request originates from an important customer, the request is more often accepted. The results provide input into the discussion of whether a large company should focus on only a few of its large customers and disregard its significantly larger group of small customers. The results provide valuable insights for researchers, who can use them to plan research of decision-making processes and methods, and for practitioners, who can use them to optimize their decision-making processes. In future work, we plan to investigate other decision characteristics, such as the number of stakeholders involved in the discussion about the potential change or the number of dependencies between software components.
Research Interests:
Ecosystem governance becomes even more relevant for a set of companies or actors characterized by symbiotic relations evolved on the top of a technological platform, i.e. a software ecosystem. In this study, we focus on the governance of... more
Ecosystem governance becomes even more relevant for a set of companies or actors characterized by symbiotic relations evolved on the top of a technological platform, i.e. a software ecosystem. In this study, we focus on the governance of a hardware-dependent software ecosystem. More specifically, we evaluate the governance model applied by Axis, a network video and surveillance camera producer, that is the platform owner and orchestrator of the Application Development Partner (ADP) software ecosystem. We conduct an exploratory case study collecting data from observations and interviews and apply the gover-nance model for prevention and improvement of the software ecosystem health proposed by Jansen and Cusumano [1, 2]. Our results reveal that although the governance actions do not address the majority of the applied framework, the ADP ecosystem is considered a growing ecosystem providing opportunities for its actors. This can be explained by the fact that Axis, as the orchestrator and the platform owner, does not address the productivity and robustness of the ecosystem adequately, but has a network of vendors and resellers to support it and some of the governance activities (e.g. communication) are achieved by non-formal means. The current governance model does not take into consideration.
Research Interests:
Free software is often declared to be a positive movement that makes technology accessible to those who might not otherwise have access. While the positive effects, to one degree or another, have often been discussed there has been... more
Free software is often declared to be a positive movement that makes technology accessible to those who might not otherwise have access. While the positive effects, to one degree or another, have often been discussed there has been relatively little discussion of the possibly negative effects of the free software movements. In general, these approaches have led to ever-increasing concentration of economic power in a smaller number of entities, the reduction of margins to the point where there is little economic incentive to investment and a general casino-like approach to software development: build it, then build a customer base and then try to find a way to monetize the customer base rather than the product. The resulting conditioning of the customer base has led to a significant reduction in the availability of venture capital for software products and a corresponding increase in the availability of venture capital for software as a means to make the customer (and not the software) the product through data analytic approaches. This short paper discusses these observed effects of free software on the software economy and possible effects on requirements engineering practice.
Research Interests:
Test-Driven Development (TDD) is a software development approach where test cases are written before actual development of the code in iterative cycles. Context: TDD has gained attention of many software practitioners during the last... more
Test-Driven Development (TDD) is a software development approach where test cases are written before actual development of the code in iterative cycles. Context: TDD has gained attention of many software practitioners during the last decade since it has contributed several benefits to the software development process. However, empirical evidence of its dominance in terms of internal code quality, external code quality and productivity is fairly limited. Objective: The aim behind conducting this controlled experiment with professional Java developers is to see the impact of Test-Driven Development (TDD) on internal code quality, external code quality and productivity compared to Test-Last Development (TLD). Results: Experiment results indicate that values found related to number of acceptance test cases passed, McCabe's Cyclomatic complexity, branch coverage, number of lines of code per person hours, number of user stories implemented per person hours are statistically insignificant. However, static code analysis results were found statistically significant in the favor of TDD. Moreover, the results of the survey revealed that the majority of developers in the experiment prefer TLD over TDD, given the lesser required level of learning curve as well as the minimum effort needed to understand and employ TLD compared to TDD.
Research Interests:
—The popularity of Open Source Software (OSS) has increased the interest in using it in safety critical applications. The aim of this study is to review research carried out on usage of open source code in development of safety-critical... more
—The popularity of Open Source Software (OSS) has increased the interest in using it in safety critical applications. The aim of this study is to review research carried out on usage of open source code in development of safety-critical software and systems. We conducted a systematic mapping study through searches in library databases and manual identification of articles from open source conferences. We have identified 22 studies about using open source software, mainly in automotive, aerospace, medical and nuclear domains. Moreover, only a few studies present complete safety systems that are released as OSS in full. The most commonly used OSS functionalities are operating systems, imaging, control and data management. Finally most of the integrated OSS have mature code bases and a commit history of more than five years.
Research Interests:
As our society becomes more and more dependent on IT systems, failures of these systems can harm more and more people and organizations both public and private. Diligently performing risk and hazard analysis helps to minimize the... more
As our society becomes more and more dependent on IT systems, failures of these systems can harm more and more people and organizations both public and private. Diligently performing risk and hazard analysis helps to minimize the potential harm of the IT systems failures on the society and increases the probability of their undisturbed operation. In this paper, we present experiences gained by applying System Theoretic Process Analysis (STPA) method for hazard analysis on forward collision avoidance system. Our main objectives are to investigate effectiveness (in terms of the number and quality of identified hazards) and time efficiency (in terms of required efforts) of the studied method. Based on the findings of this study STPA has proved to be an effective and efficient hazard analysis method for assessing the safety of a safety-critical system and it requires a moderate level of effort.
Research Interests:
Context: Involving perspectives into risk analysis brings a potential to increase the efficiency of the risks analysis task and the confidence in the identified risks. Objective: The objective of the research carried out in this study is... more
Context: Involving perspectives into risk analysis brings a potential to increase the efficiency of the risks analysis task and the confidence in the identified risks. Objective: The objective of the research carried out in this study is to investigate the effectiveness of perspective-based risk analysis (PBRA) method in comparison with a traditional risk analysis (TRA) method. Method: In this paper, we opted for an experimental design to investigate if the Perspective-Based Risk Analysis (PBRA) method that involves different views and perspectives is more effective and offers higher confidence than the Traditional Risks Analysis (TRA) method. 43 subjects performed risks analysis of a software-controlled train door system using either TRA or PBRA. We measured the effectiveness of the methods by counting the number of relevant and non-relevant risks. Using a questionnaire, we also assessed the difficulty of the methods and the confidence of the subjects concerning the correctness of the identified risks. Conclusions: The found results suggest that PBRA helps to identify more relevant risks than TRA. On the other hand, our experiment failed to provide supporting evidence that PBRA helps to identify fewer non-relevant risks. Contrary to expectations, this study did find with a statistical significance that PBRA is more difficult to use than TRA.
Research Interests:
Background. Software ecosystems emerged as means for several actors to jointly provide more value to the market than any of them can do on its own. Recently, software ecosystems are more often used to support the development of... more
Background. Software ecosystems emerged as means for several actors to jointly provide more value to the market than any of them can do on its own. Recently, software ecosystems are more often used to support the development of hardware-dependent solutions.
Objectives. This work aims at studying barriers and bridges to participation in an ecosystem with substantial hardware dependencies.
Method. We conducted an interview-based case study of an ecosystem around Axis' network video surveillance systems, interviewing 10 internal experts and 8 external representatives of 6 companies, complemented by document studies
at Axis.
Results. Major bridges to the ecosystem include end customer demands, open and transparent communication and relationship, as well as internal and external standardizations. Barriers include the two-tier business model, entry barriers and execution performance issues. Approximately half of the identiii ed bridges and barriers could be considered hardware-dependent ecosystems specifi c.
Conclusion. Our results suggest that ecosystem leaders should share their sales channels with the ecosystem participants and focus on good communication and relationships as the dominant factors for the ecosystem participation. Moreover,
we report that internal and external standardization can play a dual role, not only ease the development but also enable additional sales channels and new opportunities for the ecosystem participants. At the same time, the business model selected by the ecosystem leaders and performance, are identi fied as the main barriers to ecosystem participation. We believe that the business model barrier may be much more important for similar hardware-dependent software ecosystems.
Research Interests:
—A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline... more
—A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline of RE is lacking an official Requirements Engineering Body of Knowledge (REBoK). This working session brings together researchers and practitioners to elaborate the goals, requirements and constraints for a REBoK that shall serve as commonly agreed basis for developing a draft over the following months.
Research Interests:
Streszczenie Inżynieria wymagań jest ważnym działem inżynierii oprogramowania. Znaczenie inżynierii wymagań i prawidłowego przebiegu procesów zarządzania wymaganiami jest często kluczowym czynnikiem sukcesu dla projektów informatycznych.... more
Streszczenie Inżynieria wymagań jest ważnym działem inżynierii oprogramowania. Znaczenie inżynierii wymagań i prawidłowego przebiegu procesów zarządzania wymaganiami jest często kluczowym czynnikiem sukcesu dla projektów informatycznych. Znane są przypadki, gdzie porażka projektu wynikała z błędów podczas analizy wymagań. [1, 2, 3, 4] Świadomość i znajomość tych procesów dla współczesnych inżynierów informatyków nie zawsze jest wystarczająca. W artykule został dokonany przegląd nauczania inżynierii wymagań w programach nauczania wybranych uczelni wyższych kształcących studentów na kierunku informatyka oraz metody kształce-nia w tym zakresie. W ostatnich latach obserwuje się rozwój edukacji inżynierii wymagań nie tylko na wyż-szych uczelniach, ale również w kształceniu ustawicznym. Powstają nowe inicjatywy i organizacje szerzące wiedzę i dobre praktyki inżynierii wymagań. Na rynku pojawiają się też certyfikaty z tego obszaru wiedzy. W artykule przedstawiono jedną z takich organizacji-International Requirements Engineering Board (IREB) oraz jej podejście do procesów inżynierii wymagań i certyfikacji dostępnej od 2012 roku również w Polsce, a certyfikat IREB CPRET ma około 11 000 osób [18] Inżynieria wymagań oprogramowania jest relatywnie nowym pojęciem w informatyce. Zostało ono stworzone w celu określenia wszystkich czynności związanych z szeroko rozumianym pozyskiwaniem, doku-mentowaniem i zarządzaniem wymaganiami dla systemów komputerowych. Słowo " inżynieria " w tym kontek-ście należy rozumieć jako systematyczną i zdefiniowaną działalność zapewniająca powodzenie tych procesów. Widoczne jest tu zatem odmienne do tradycyjnego podejścia, w którym inżynieria rozumiana jest jako " używa-nie właściwości materii, energii oraz obiektów abstrakcyjnych dla tworzenia konstrukcji, maszyn i produktów, przeznaczonych do wykonywania określonych funkcji lub rozwiązania określonego problemu " [5]. W tradycyjnych podejściach do prowadzenia projektów informatycznych, takich jak V-model czy model kaskadowy zakłada się, że wszystkie wymagania zostaną zdefiniowane, a cały proces zakończy się, przed fazą projektowania i implementacji. Wymaga się, aby wszystkie wymagania zostały zdefiniowane i odpowiednio dobrze opisane. Nie dopuszcza się możliwości zmiany wymagań po ich pierwotnym ustaleniu, choć na przykład Royce dopuszcza iteracje i podkreśla rolę sprzężenia zwrotnego w procesie wytwarzania w modelu kaskadowym [19]. Metodyki zwinne określane także jako lekkie, zakładają inne podejście do pozyskiwania wymagań. W projektach prowadzonych zgodnie z ich wytycznymi dopuszcza się zmiany w trakcie trwania projektu jako jego naturalny element. W początkowej fazie definiowane się wymagania zgodne z obecnym stanem wiedzy. W czasie trwania projektu mogą one ulec zmianie, co kontrolowane jest przez wyznaczonych do tego członków zespołu.
Research Interests:
Open innovation is an emerging innovation paradigm that can greatly accelerate technical knowledge innovation in software companies. The increasing importance and density of software in today's products and services puts extensive... more
Open innovation is an emerging innovation paradigm that can greatly accelerate technical knowledge innovation in software companies. The increasing importance and density of software in today's products and services puts extensive pressure on excelling the discovery, description and execution of innovation. Despite that, software engineering literature lacks methods, tools and frameworks for full exploitation of technological advantages that open innovation can bring. This paper proposes a software engineering framework, designed to foster open innovation by designing and tailoring appropriate software engineering methods and tools. Furthermore, this paper discusses the methodological and process dimensions and outlines challenge areas that should be reviewed when transitioning to software engineering driven open innovation.
Research Interests:
Mobile application development operates in a market characterized by low barriers to market entry, short time-to-market and the need for rapid return on investment, making it suitable for exploiting the potential of open innovation.... more
Mobile application development operates in a market characterized by low barriers to market entry, short time-to-market and the need for rapid return on investment, making it suitable for exploiting the potential of open innovation. Technology-driven entrepreneurs often diverge from the standard practice of antecedent business case analysis. We report here upon the result of a six-month empirical investigation of this question, performed within an incubator setting, and our analysis of the results indicates a reasonable probability of success, at least for ventures with access to experienced requirements practitioners. Our results indicate that incorporating RE techniques from the beginning of the venture has the potential to reduce the risks associated with the missing business case analysis. The field observations have also identified requirements engineering challenges in this domain worthy of further investigation. In particular, the relative impact of business requirements upon the technology requirements is extreme and requirements methods must respond not only to agile development processes but function even when a pivot (an instantaneous and complete change) in business focus occurs.
Research Interests:
[Motivation:] The requirements engineering (RE) research community is aware of the importance of performing feasibility studies before starting requirements elicitation. Unfortunately, projects still frequently fail to achieve commercial... more
[Motivation:] The requirements engineering (RE) research community is aware of the importance of performing feasibility studies before starting requirements elicitation. Unfortunately, projects still frequently fail to achieve commercial success, responsibility is often unknown , and requirements engineers may be deemed responsible for mistakes made by others. [Problem:] There is neither empirical evidence available from a post-mortem risk analysis for projects that performed adequate RE but commercially failed nor guidance for requirements engineers on validating a business case analysis to mitigate this risk. [Principal idea:] By performing a post-mortem analysis of software development projects that failed to achieve commercial success, we investigate the root causes for the failures and, in most cases, trace the causes back to business case issues. We identify risk areas and provide practical due diligence guidance to the practitioner. [Contribution:] This exploratory case study performs an in-depth review of a detailed post-mortem analysis of three software development projects performed over a 2.5 year period. Each of the analyzed projects failed to make the expected transition to commercialization despite using appropriate RE techniques and achieving satisfactory deliverables. The analysis identifies risk factors that the RE practitioner should consider and we provide a checklist for RE practitioners to use when checking for these risks in an antecedent business case as part of their due diligence. A low-cost commercial viability assessment technique, employing Fermi approximation, is provided to equip the RE practitioner with a risk mitigation tool in the absence of business analyst resources.
Research Interests:
— Despite the widely recognized importance of replications in software engineering, industrial replications in software engineering are still rarely reported. Although the literature provides some evidence about the issues and challenges... more
— Despite the widely recognized importance of replications in software engineering, industrial replications in software engineering are still rarely reported. Although the literature provides some evidence about the issues and challenges related to conducting experiments and replications the practitioner's view of the issues and challenges has not been fully explored. This paper reports an industrial practitioner's review of a replicated experiment on linguistic tool support for consolidation of requirements from multiple sources. The review identified potential confounding factors from a perspective that differed significantly from that of the designers of the experiment. The results suggest that industrial practice may focus upon specific process aspects that are not necessarily reflected in academic practice.
Research Interests:
— Replications play an important role in requirements engineering, furthering our knowledge about which results or observations hold and under what conditions. Despite the widely recognized importance of this type of research study,... more
— Replications play an important role in requirements engineering, furthering our knowledge about which results or observations hold and under what conditions. Despite the widely recognized importance of this type of research study, industrial replications in software engineering are still rarely reported. Although the literature provides some evidence about the issues and challenges related to conducting experiments and replications the view of the practitioners on the possible issues and challenges has not been fully explored. This paper reports on experience gained from conducting an industrial practitioner review of a replicated experiment on linguistic tool support for consolidation of requirements from multiple sources. The review identified further potential confounding factors from a perspective that differed significantly from that of the designers of the experiment. Our results suggest that industrial practice may focus upon specific aspects of processes that are not necessarily reflected in academic practice.
Research Interests:
[Context] Coping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in... more
[Context] Coping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in requirements obsolescence even before project completion. [Objective] Although the obsolete requirements phenomenon and the implications of not addressing them are known, there is a lack of empirical research dedicated to understanding the nature of obsolete software requirements and their role in requirements management. [Method] In this paper, we report results from an empirical investigation with 219 respondents aimed at investigating the phenomenon of obsolete software requirements. [Results] Our results contain , but are not limited to, defining the phenomenon of obsolete software requirements, investigating how they are handled in industry today and their
Research Interests:
Context: Scope management is a core part of software release management and often a key factor in releasing successful software products to the market. In a market-driven case, when not all the requirements are known 'a priori', the risk... more
Context: Scope management is a core part of software release management and often a key factor in releasing successful software products to the market. In a market-driven case, when not all the requirements are known 'a priori', the risk of overscoping may increase. Objective: This paper reports on findings from a case study aimed at understanding overscoping in a large-scale industrial set up, and how agile requirements engineering practices may affect this situation. Method: Based on an assumption of what factors are involved in an overscoping situation, semi-structured interviews were performed with nine practitioners at a large market-driven software company. The results from the interviews were then presented to six (other) practitioners at the case company and their level of agreement was gathered via a questionnaire. Results: Six main causes of overscoping have been identified in this study: (1) continuous requirements inflow; (2) no overview of software resource availability; (3) low development team involvement; (4) requirements not agreed; (5) requirements specification produced upfront; and (6) unclear vision of overall goal. In addition, the results include six main effects of overscoping, namely (1) many requirement changes; (2) quality issues; (3) delays; (4) customer expectations are not always met; (5) communication gaps; and (6) challenge to keep the SRS updated. Furthermore, the study points to three agile requirements engineering practices that may address overscoping, namely one continuous scope & release-planning flow; cross-functional and integrated development teams; and gradual & iterative detailing of requirements. Conclusion: The results provide an increased understanding of the scoping activity as a complex and continuous activity. The study provides an analysis of the causes, root causes, effects, and possible impact of agile requirements engineering practices to the issue of overscoping. The results presented in this paper can be used to identify potential factors to address in order to achieve a more realistic scope for projects.
Research Interests:
Large market-driven software companies continuously receive large numbers of requirements and change requests from multiple sources. The task of analyzing those requests against each other and against already analyzed or implemented... more
Large market-driven software companies continuously receive large numbers of requirements and change requests from multiple sources. The task of analyzing those requests against each other and against already analyzed or implemented functionality then recording similarities between them, also called the requirements consolidation task, may be challenging and time consuming. This paper presents a replicated experiment designed to further investigate the linguistic tool support for the requirements consolidation task. In this replication study, 45 subjects, working in pairs on the same set of requirements as in the original study, were assigned to use two methods for the requirements consolidation: (1) lexical similarity and (2) searching and filtering. The results show that the linguistic method used in this experiment is not more efficient in consolidating requirements than the searching and filtering method, which contradicts the findings of the original study. However, we confirm the previous results that the assisted method (lexical similarity) can deliver more correct links and miss fewer links than the manual method (searching and filtering).
Research Interests:
— About a hundred studies on traceability recovery have been published in software engineering fora. In roughly half of them, software artifacts developed by students have been used as input. To what extent student artifacts differ from... more
— About a hundred studies on traceability recovery have been published in software engineering fora. In roughly half of them, software artifacts developed by students have been used as input. To what extent student artifacts differ from industrial counterparts has not been fully explored in the literature. We conducted a survey among authors of studies on traceability recovery, including both academics and practitioners, to explore their perspectives on the matter. Our results indicate that a majority of authors consider software artifacts originating from student projects to be only partly representative to industrial artifacts. Moreover, only few respondents validated student artifacts for industrial representativeness. Furthermore, our respondents made suggestions for improving the description of artifact sets used in studies by adding contextual, domain-specific and artifact-centric information. Example suggestions include adding descriptions of processes used for artifact development, meaning of traceability links, and the structure of artifacts. Our findings call for further research on characterization and validation of software artifacts to support aggregation of results from empirical studies.
Research Interests:
In this paper, we present a model for estimating the final decision point for committing to the development of features that are under analysis for inclusion in the scope of a future release. The Basic Lost Opportunity Estimation Model... more
In this paper, we present a model for estimating the final decision point for committing to the development of features that are under analysis for inclusion in the scope of a future release. The Basic Lost Opportunity Estimation Model (BLOEM) is based on studies at a company that uses an agile-inspired software development model. The main objective of BLOEM is to support feature selection in a context where the business value estimates change as the requirements analysis progresses and can be represented as a function of time. With BLOEM, a set of possible management strategies can be assessed for individual features in order to determine a final decision point when either an implementation commitment decision or a rejection decision has to be made. Our initial validation, conducted on a set of 166 features, suggests that the model can be applied in a real-world context to control lost opportunity costs due to feature cancellation and BLOEM can therefore provide valuable input to the selection process. Limitations of BLOEM are discussed and issues for further research are presented.
Research Interests:
A key component in successfully managing software products is to properly, and in a timely manner, identify and secure competitive advantage by innovation via feature differentiation. Although open source software (OSS) is not a new idea,... more
A key component in successfully managing software products is to properly, and in a timely manner, identify and secure competitive advantage by innovation via feature differentiation. Although open source software (OSS) is not a new idea, several product development companies that operate in a market-driven context have started to use open source solutions as core software components in their products. Adopting open source core components implies a lower degree of control over software development and increased business risk associated with integrating differentiating contributions into the core release stream. Whether and how to adjust the current requirements management practices after the adoption of OSS components to fully benefit from the concept of open innovation has not yet been empirically explored. We outline experiences and challenges related to leveraging open innovation via engaging in OSS identified during 19 interviews with practitioners occupying different roles in the requirements management process at a large company followed by four validation interviews with other practitioners. We then propose a research agenda for requirements and decision management in the open innovation context and suggest which challenges in requirements engineering open innovation affects.
Research Interests:
The amount of data in large-scale software engineering contexts continues to grow and challenges efficiency of software engineering efforts. At the same time, information related to requirements plays a vital role in the success of... more
The amount of data in large-scale software engineering contexts continues to grow and challenges efficiency of software engineering efforts. At the same time, information related to requirements plays a vital role in the success of software products and projects. To face the current challenges in software engineering information management, software companies need to reconsider the current models of information. In this paper, we present a modeling framework for requirements artifacts dedicated to a large-scale market-driven requirements engineering context. The underlying meta-model is grounded in a clear industrial need for improved flexible models for storing requirements engineering information. The presented framework is created in collaboration with industry and initially evaluated by industry practitioners from three large companies. Participants of the evaluation positively evaluated the presented modeling framework as well as pointed out directions for further research and improvements.
Research Interests:
As standards and regulatory codes are issued by third party organizations and committees, the project organization can neither control the content of all standards that the projects should adhere to, nor negotiate or make changes to them... more
As standards and regulatory codes are issued by third party organizations and committees, the project organization can neither control the content of all standards that the projects should adhere to, nor negotiate or make changes to them that can make the project development easier. Moreover, large infrastructure projects require compliance with hundreds of standards of regulations coming from different agencies, with different styles and structures. A new approach is needed, one that results in well written, easily mined standard and codes. In this paper, we report on findings from an exhaustive literature survey that reveals that the area of supporting drafting of regulatory codes for the purpose of making them more data minable has not yet been explored.
Research Interests:
Determining requirements process efficiency, and measuring the corresponding monetary impacts, is a challenging but necessary aspect of project management. In this paper, we perform an independent analysis of scoping decisions from a... more
Determining requirements process efficiency, and measuring the corresponding monetary impacts, is a challenging but necessary aspect of project management. In this paper, we perform an independent analysis of scoping decisions from a large industrial project with the goal of providing visualizations that facilitate investigations of process efficiency , agility, and the effects of scoping decisions. The visualizations proposed in this paper can be used to analyze scoping dynamics and support process management decisions on a quantitative rather than a qualitative basis.
Research Interests:
Communication is essential for software development as its efficiency throughout the entire project life-cycle is a key factor in developing and releasing successful software products to the market. This paper reports on findings from an... more
Communication is essential for software development as its efficiency throughout the entire project life-cycle is a key factor in developing and releasing successful software products to the market. This paper reports on findings from an explanatory case study aiming at a deeper understanding of the causes and effects of communication gaps in a large-scale industrial set up. Based on an assumption of what causes gaps in communication of requirements and what effects such gaps have, a semi-structured interview study was performed with nine practitioners at a large market-driven software company. We found four main factors that affect the requirements communication, namely scale, temporal aspects, common views and decision structures. The results also show that communication gaps lead to failure to meet the customers' expectations, quality issues and wasted effort. An increased awareness of these factors is a help in identifying what to address to achieve a more efficient requirements management, and ultimately more efficient and successful software development. By closing the communication gaps the requirements may continue all the way through the project life-cycle and be more likely to result in software that meets the customers' expectations.
Research Interests:
An Empirical Study on the Importance of Quality Requirements in Industry
Research Interests:
—Creation and adoption of corporate policies requires significant commitment of scarce senior management resources. In the absence of processes and tools, convergence upon final policy and may not be achieved in a timely manner.... more
—Creation and adoption of corporate policies requires significant commitment of scarce senior management resources. In the absence of processes and tools, convergence upon final policy and may not be achieved in a timely manner. Significant similarities between policy and requirements documents suggest that requirements engineering techniques could be used to generate policy. However, neither evidence of feasibility of this approach nor theoretical investigation is present in the research literature. This paper reports upon our experience from an exploratory study where well-established requirements engineering methodologies were applied to generate corporate intellectual property policy. Interview, brain-storming and survey techniques were used to successfully apply structure and process to the task, generating a new corporate intellectual property policy that met or exceeded all stakeholder goals. The materials gathered during stakeholder surveys not only provided functional guidance for the policy itself, but also non-functional guidance with respect to the diversity of stakeholder opinions and the strength with which opinions were held. ALLOWED US TO ACT AS MEDIATORS This knowledge greatly facilitated the creation of draft policy: this insider knowledge increased our expectation of stakeholder acceptance and also facilitated subsequent negotiation efforts. The feasibility of applying RE techniques to crafting corporate policy has been demonstrated and the results show sufficient promise that further investigation is warranted.
Research Interests:
ABSTRACT Open innovation (OI) means that innovation is fostered by using both external and internal influences in the innovation process. In software engineering (SE), OI has existed for decades, while we currently see a faster and... more
ABSTRACT Open innovation (OI) means that innovation is fostered by using both external and internal influences in the innovation process. In software engineering (SE), OI has existed for decades, while we currently see a faster and broader move towards OI in SE. We therefore survey research on how OI takes place and contributes to innovation in SE. This study aims to synthesize the research knowledge on OI in the SE domain. We launched a systematic mapping study and conducted a thematic analysis of the results. Moreover, we analyzed the strength of the evidence in the light of a rigor and relevance assessment of the research. We identified 33 publications, divided into 9 themes related to OI. 17/33 studies fall in the high-rigor/high-relevance category, suggesting the results are highly industry relevant. The research indicates that start-ups have higher tendency to opt for OI compared to incumbents. The evidence also suggests that firms assimilating knowledge into their internal R&D activities, have higher likelihood of gaining financial advantages. We concluded that OI should be adopted as a complementary approach to facilitate internal innovation and not to substitute it. Further research is advised on situated OI strategies and the interplay between OI and agile practices.
ABSTRACT Open innovation is an emerging innovation paradigm that can greatly accelerate technical knowledge innovation in software companies. The increasing importance and density of software in today’s products and services puts... more
ABSTRACT Open innovation is an emerging innovation paradigm that can greatly accelerate technical knowledge innovation in software companies. The increasing importance and density of software in today’s products and services puts extensive pressure on excelling the discovery, description and execution of innovation. Despite that, software engineering literature lacks methods, tools and frameworks for full exploitation of technological advantages that open innovation can bring. This paper proposes a software engineering framework, designed to foster open innovation by designing and tailoring appropriate software engineering methods and tools. Furthermore, this paper discusses the methodological and process dimensions and outlines challenge areas that should be reviewed when transitioning to software engineering driven open innovation.
As our society becomes more and more dependent on IT systems, failures of these systems can harm more and more people and organizations both public and private. Diligently performing risk and hazard analysis helps to minimize the societal... more
As our society becomes more and more dependent on IT systems, failures of these systems can harm more and more people and organizations both public and private. Diligently performing risk and hazard analysis helps to minimize the societal harms of IT system failures. In this paper we present experiences gained by applying the System Theoretic Process Analysis (STPA) method for hazard analysis on a forward collision avoidance system. Our main objectives are to investigate effectiveness in terms of the number and quality of identified hazards, and time efficiency in terms of required efforts of the studied method. Based on the findings of this study STPA has proved to be an effective and efficient hazard analysis method for assessing the safety of a safety-critical system and it requires a moderate level of effort.
In the software industry, there is a strong shift from traditional phase-based development towards agile methods and practices. This paper reports on a case study aimed at investigating if, and how, agile Requirements Engineering (RE) can... more
In the software industry, there is a strong shift from traditional phase-based development towards agile methods and practices. This paper reports on a case study aimed at investigating if, and how, agile Requirements Engineering (RE) can remedy the challenges of traditional RE, and what new challenges agile RE may pose. The results from an initial case study with 9 practitioners
Research Interests:
Context. In many application domains, critical systems must comply with safety standards. This involves gathering safety evidence in the form of artefacts such as safety analyses, system specifications, and testing results. These... more
Context. In many application domains, critical systems must comply with safety standards. This involves gathering safety evidence in the form of artefacts such as safety analyses, system specifications, and testing results. These artefacts can evolve during a system's lifecycle, creating a need for change impact analysis to guarantee that system safety and compliance are not jeopardised. Objective. We aim to provide new insights into how safety evidence change impact analysis is addressed in practice. The knowledge about this activity is limited despite the extensive research that has been conducted on change impact analysis and on safety evidence management. Method. We conducted an industrial survey on the circumstances under which safety evidence change impact analysis is addressed, the tool support used, and the challenges faced. Results. We obtained 97 valid responses representing 16 application domains, 28 countries, and 47 safety standards. The respondents had most often performed safety evidence change impact analysis during system development, from system specifications, and fully manually. No commercial change impact analysis tool was reported as used for all artefact types and insufficient tool support was the most frequent challenge. Conclusion. The results suggest that the different artefact types used as safety evidence co-evolve. In addition, the evolution of safety cases should probably be better managed, the level of automation in safety evidence change impact analysis is low, and the state of the practice can benefit from over 20 improvement areas.
Creation and adoption of corporate policies re- quires significant commitment of scarce senior management resources. In the absence of processes and tools, convergence upon final policy and may not be achieved in a timely man- ner.... more
Creation and adoption of corporate policies re- quires significant commitment of scarce senior management resources. In the absence of processes and tools, convergence upon final policy and may not be achieved in a timely man- ner. Significant similarities between policy and requirements documents suggest that requirements engineering techniques could be used to generate policy. However, neither evidence of feasibility of
Determining requirements process efficiency, and measuring the corresponding monetary impacts, is a challenging but necessary aspect of project management. In this paper, we perform an independent analysis of scoping decisions from a... more
Determining requirements process efficiency, and measuring the corresponding monetary impacts, is a challenging but necessary aspect of project management. In this paper, we perform an independent analysis of scoping decisions from a large industrial project with the goal of providing visualizations that facilitate investigations of process efficiency, agility, and the effects of scoping decisions. The visualizations proposed in this paper
Abstract One of the goals of requirements engineering is to capture and document innovation in the form of new product requirements. These product requirements need to express new system functions or new qualities that are most desired by... more
Abstract One of the goals of requirements engineering is to capture and document innovation in the form of new product requirements. These product requirements need to express new system functions or new qualities that are most desired by customers while maintaining customer familiarity with existing products. This paper explores the contradiction between the customer desire for revolutionary advancement and their desire to maintain familiarity with existing systems. This customer inertia creates a bias toward incremental ( ...
We present a model for supporting scoping decisions that is based on an analysis of the ROI for a given feature. Employing a ROI threshold value for making scoping decisions, the utility of the model was investigated using data from a... more
We present a model for supporting scoping decisions that is based on an analysis of the ROI for a given feature. Employing a ROI threshold value for making scoping decisions, the utility of the model was investigated using data from a single large project and identified a group of outlying features responsible for a disproportionate wasted investment. These initial results
Research Interests:
... 1-10. [19] MS Feather, SL Cornford, JD Kiper, T. Menzies, “Experiences using Visualization Techniques to Present Requirements, Risks to Them, and Options for Risk Mitigation”, First International Workshop on Requirements Visualization... more
... 1-10. [19] MS Feather, SL Cornford, JD Kiper, T. Menzies, “Experiences using Visualization Techniques to Present Requirements, Risks to Them, and Options for Risk Mitigation”, First International Workshop on Requirements Visualization (REV 2006), St. ...
ABSTRACT A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the... more
ABSTRACT A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline of RE is lacking an official Requirements Engineering Body of Knowledge (REBoK). This working session brings together researchers and practitioners to elaborate the goals, requirements and constraints for a REBoK that shall serve as commonly agreed basis for developing a draft over the following months.
Abstract A key component in successfully managing software products is to properly, and in a timely manner, identify and secure competitive advantage by innovation via feature differentiation. Although open source software (OSS) is not a... more
Abstract A key component in successfully managing software products is to properly, and in a timely manner, identify and secure competitive advantage by innovation via feature differentiation. Although open source software (OSS) is not a new idea, several product development companies that operate in a market-driven context have started to use open source solutions as core software components in their products. Adopting open source core components implies a lower degree of control over software development and increased ...
ABSTRACT ContextCoping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in... more
ABSTRACT ContextCoping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in requirements obsolescence even before project completion.Objective Although the obsolete requirements phenomenon and the implications of not addressing them are known, there is a lack of empirical research dedicated to understanding the nature of obsolete software requirements and their role in requirements management.Method In this paper, we report results from an empirical investigation with 219 respondents aimed at investigating the phenomenon of obsolete software requirements.ResultsOur results contain, but are not limited to, defining the phenomenon of obsolete software requirements, investigating how they are handled in industry today and their potential impact.Conclusion We conclude that obsolete software requirements constitute a significant challenge for companies developing software intensive products, in particular in large projects, and that companies rarely have processes for handling obsolete software requirements. Further, our results call for future research in creating automated methods for obsolete software requirements identification and management, methods that could enable efficient obsolete software requirements management in large projects.
Abstract—We discuss the supervision of undergraduate students conducting their master's project (" examensarbete"). We base our reflections on both literature studies and insight into practical experiences, gained in an... more
Abstract—We discuss the supervision of undergraduate students conducting their master's project (" examensarbete"). We base our reflections on both literature studies and insight into practical experiences, gained in an interview with an experienced supervisor, and aim ...
Ulrike Abelein Fernanda Alencar Mauricio Alferez Raian Ali Muneera Bano Saeed Ahmadi Behnam Rik Bos Eya Ben Charrada Marian Daun Daniel J. Dean Alexander Delater Hanna Farah Alessio Ferrari Antonio Filieri Sepideh Ghanavati Ramya Gopalan... more
Ulrike Abelein Fernanda Alencar Mauricio Alferez Raian Ali Muneera Bano Saeed Ahmadi Behnam Rik Bos Eya Ben Charrada Marian Daun Daniel J. Dean Alexander Delater Hanna Farah Alessio Ferrari Antonio Filieri Sepideh Ghanavati Ramya Gopalan Miguel Goulao Eko Handoyo Robert Heinrich Andrea Herrmann Tom-Michael Hesse Nicolas Hoby Cédric Jeanneret Ravi Khadka Eric Knauss Anne Koziolek Dewi Mairiza Aaron Massey Raimundas Matulevicius Andreas Metzger Karolyne Oliveira Birgit Penzenstadler João Pimentel Alireza Pourshahid Rumyana ...
The Role of Data Use Agreements in Specifying Legally Compliant Software Requirements………………………………………………………………………………………….1 Jessica D. Young, Annie I. Antón, Laurie Williams, Paul Otto ... Governance and Accountability in the New Data... more
The Role of Data Use Agreements in Specifying Legally Compliant Software Requirements………………………………………………………………………………………….1 Jessica D. Young, Annie I. Antón, Laurie Williams, Paul Otto ... Governance and Accountability in the New Data Ecology……………………….......................5 Travis D. Breaux, Thomas A. Alspaugh ... Compliance Management with Measurement Frameworks……………………………………. 15 Andre Rifaut ... A Systematic Review of Goal-oriented Requirements Management ...
Time efficiency is crucial for decision making in large scale Market Driven Requirements Engineering. In order to identify what factors influence the decision lead time and outcome, we conducted a retrospective case study at a large... more
Time efficiency is crucial for decision making in large scale Market Driven Requirements Engineering. In order to identify what factors influence the decision lead time and outcome, we conducted a retrospective case study at a large product software manufacturer and statistically analyzed seven possible relationships among decision characteristics. A large requirements engineering decision log was used to statistically test all hypotheses and the results were validated using a survey among similar software ...
Time efficiency is crucial for decision making in large scale market driven software product line development. In order to identify what factors influence the decision lead time and outcome, we conducted a retrospective case study at a... more
Time efficiency is crucial for decision making in large scale market driven software product line development. In order to identify what factors influence the decision lead time and outcome, we conducted a retrospective case study at a large product software manufacturer and statistically analyzed seven possible relationships among decision characteristics. A large requirements engineering decision log was used to statistically test all hypotheses. The results show that the number of products affected by a decision has a positive ...