Maya Daneva
University of Twente, Services, Cybersecurity and Safety Group, Faculty Member
Little attention has been given so far to the process of security risk management at the early stages of system development. Security has been addressed by isolated security assurance practices, some of which consider risks and... more
Little attention has been given so far to the process of security risk management at the early stages of system development. Security has been addressed by isolated security assurance practices, some of which consider risks and mitigations but they do not provide an overview of the overall security state of the system being developed. This paper takes the position that
Research Interests:
Agile practices on requirements dependencies are a relatively unexplored topic in literature. Empirical studies on it are scarce. This research sets out to uncover concepts that practitioners in companies of various sizes across the globe... more
Agile practices on requirements dependencies are a
relatively unexplored topic in literature. Empirical studies on it
are scarce. This research sets out to uncover concepts that
practitioners in companies of various sizes across the globe and in
various industries, use for dealing with requirements
dependencies in their agile software projects. Concepts were
revealed through online focus group research, using an adapted
forum for discussion, and grounded theory to analyze the
responses.
Our study resulted in the following findings: (1) requirements
dependencies occur in agile projects and are important to these
projects’ success just as this is known for ‘traditional’ software
projects’; (2) requirements dependencies (i) were considered and
treated as part of risk management, (ii) were deemed a
responsibility of the individual team members, and (iii) mostly
did affect project planning; (3) continuous communication and
collaboration — two essential features of any agile method, were
found critical to mitigating the risks due to dependencies; (4) a
hybrid approach to architecture between agile and plan-driven
methods was perceived to yield maximum scalability and help
coping with dependencies; (5) ‘cross-cutting concerns’, a category
of dependencies, were not uniformly understood in an agile
context and require more research.
relatively unexplored topic in literature. Empirical studies on it
are scarce. This research sets out to uncover concepts that
practitioners in companies of various sizes across the globe and in
various industries, use for dealing with requirements
dependencies in their agile software projects. Concepts were
revealed through online focus group research, using an adapted
forum for discussion, and grounded theory to analyze the
responses.
Our study resulted in the following findings: (1) requirements
dependencies occur in agile projects and are important to these
projects’ success just as this is known for ‘traditional’ software
projects’; (2) requirements dependencies (i) were considered and
treated as part of risk management, (ii) were deemed a
responsibility of the individual team members, and (iii) mostly
did affect project planning; (3) continuous communication and
collaboration — two essential features of any agile method, were
found critical to mitigating the risks due to dependencies; (4) a
hybrid approach to architecture between agile and plan-driven
methods was perceived to yield maximum scalability and help
coping with dependencies; (5) ‘cross-cutting concerns’, a category
of dependencies, were not uniformly understood in an agile
context and require more research.
Research Interests:
Unlike traditional software development methods, agile methods are marked by extensive collaboration, i.e. face-to-face communication. Although claimed to be beneficial, the software development community as a whole is still unfamiliar... more
Unlike traditional software development methods, agile methods are marked by extensive collaboration,
i.e. face-to-face communication. Although claimed to be beneficial, the software development community
as a whole is still unfamiliar with the role of the requirements engineering practices in agile methods. The
term ‘‘agile requirements engineering’’ is used to define the ‘‘agile way’’ of planning, executing and reasoning
about requirements engineering activities. Moreover, not much is known about the challenges posed
by collaboration-oriented agile way of dealing with requirements engineering activities. Our goal is to
map the evidence available about requirements engineering practices adopted and challenges faced by
agile teams in order to understand how traditional requirements engineering issues are resolved using
agile requirements engineering. We conducted a systematic review of literature published between
2002 and June 2013 and identified 21 papers, that discuss agile requirements engineering. We formulated
and applied specific inclusion and exclusion criteria in two distinct rounds to determine the most relevant
studies for our research goal. The review identified 17 practices of agile requirements engineering, five
challenges traceable to traditional requirements engineering that were overcome by agile requirements
engineering, and eight challenges posed by the practice of agile requirements engineering. However,
our findings suggest that agile requirements engineering as a research context needs additional attention
and more empirical results are required to better understand the impact of agile requirements engineering
practices e.g. dealing with non-functional requirements and self-organising teams.
i.e. face-to-face communication. Although claimed to be beneficial, the software development community
as a whole is still unfamiliar with the role of the requirements engineering practices in agile methods. The
term ‘‘agile requirements engineering’’ is used to define the ‘‘agile way’’ of planning, executing and reasoning
about requirements engineering activities. Moreover, not much is known about the challenges posed
by collaboration-oriented agile way of dealing with requirements engineering activities. Our goal is to
map the evidence available about requirements engineering practices adopted and challenges faced by
agile teams in order to understand how traditional requirements engineering issues are resolved using
agile requirements engineering. We conducted a systematic review of literature published between
2002 and June 2013 and identified 21 papers, that discuss agile requirements engineering. We formulated
and applied specific inclusion and exclusion criteria in two distinct rounds to determine the most relevant
studies for our research goal. The review identified 17 practices of agile requirements engineering, five
challenges traceable to traditional requirements engineering that were overcome by agile requirements
engineering, and eight challenges posed by the practice of agile requirements engineering. However,
our findings suggest that agile requirements engineering as a research context needs additional attention
and more empirical results are required to better understand the impact of agile requirements engineering
practices e.g. dealing with non-functional requirements and self-organising teams.
Research Interests:
Contracts for delivering large software systems must address issues such as system quality, timelines, delivery cost and effort, and service- level agreements. A study with 20 software architects revealed how they coped with quality... more
Contracts for delivering large software
systems must address issues such as system
quality, timelines, delivery cost and effort,
and service- level agreements. A study with 20
software architects revealed how they coped
with quality requirements in this context.
systems must address issues such as system
quality, timelines, delivery cost and effort,
and service- level agreements. A study with 20
software architects revealed how they coped
with quality requirements in this context.
Research Interests:
General theories of software engineering must balance between providing full under-standing of a single case and providing partial understanding of many cases. In this paper we argue that for theories to be useful in practice, they should... more
General theories of software engineering must balance between providing full under-standing of a single case and providing partial understanding of many cases. In this paper we argue that for theories to be useful in practice, they should give sufficient understanding of a sufficiently large class of cases, without having to be universal or complete. We provide six strategies for developing such theories of the middle range.
In lab-to-lab strategies, theories of laboratory phenomena are developed and generalized to other laboratory phenomena. This is a characteristic strategy for basic science. In lab-to-field strategies, theories are developed of artifacts that first operate under idealized laboratory conditions, which are then scaled up until they can operate under uncontrolled field conditions. This is the characteristic strategy for the engineering sciences.
In case-based strategies, we generalize about components of real-world cases, that are supposed to exhibit less variation than the cases as a whole. In sample-based strategies, we generalize about the aggregate behavior of samples of cases, which can exhibit patterns not visible at the case level. We discuss three examples of sample-based strategies.
Throughout the paper, we use examples of theories and generalization strategies from software engineering to illustrate our analysis. The paper concludes with a discussion of related work and implications for empirical software engineering research.
In lab-to-lab strategies, theories of laboratory phenomena are developed and generalized to other laboratory phenomena. This is a characteristic strategy for basic science. In lab-to-field strategies, theories are developed of artifacts that first operate under idealized laboratory conditions, which are then scaled up until they can operate under uncontrolled field conditions. This is the characteristic strategy for the engineering sciences.
In case-based strategies, we generalize about components of real-world cases, that are supposed to exhibit less variation than the cases as a whole. In sample-based strategies, we generalize about the aggregate behavior of samples of cases, which can exhibit patterns not visible at the case level. We discuss three examples of sample-based strategies.
Throughout the paper, we use examples of theories and generalization strategies from software engineering to illustrate our analysis. The paper concludes with a discussion of related work and implications for empirical software engineering research.
Research Interests:
Enterprise modelling is an important premise for a successful business process (re) engineering (BPR) project (J. Brown, 1995). To facilitate this first step in any BPR initiative, the business process engineering community has developed... more
Enterprise modelling is an important premise for a successful business process (re) engineering (BPR) project (J. Brown, 1995). To facilitate this first step in any BPR initiative, the business process engineering community has developed different modelling methods and produced numerous tools implementing them.
Requirements Engineering (RE) not only demands a systematic approach for eliciting, operationalizing, and documenting requirements and for solving their conflicts, but RE also is a creative activity. It demands the stakeholders to create... more
Requirements Engineering (RE) not only demands a systematic approach for eliciting, operationalizing, and documenting requirements and for solving their conflicts, but RE also is a creative activity. It demands the stakeholders to create visions of future software systems and to imagine all their implications. Creativity enhancing techniques, which have been developed and used in other disciplines and areas of problem-solving, have the potential to be adapted and adopted in today's RE,
Abstract Consider the situation that you have a data model, a functional model and a process model of a system, perhaps made by different analysts at different times. Are these models consistent with each other? A relevant question in... more
Abstract Consider the situation that you have a data model, a functional model and a process model of a system, perhaps made by different analysts at different times. Are these models consistent with each other? A relevant question in practice-and therefore we think it should also be addressed in our courses. However, UML modelling textbooks don't discuss it, so we developed our own teaching materials. In this position paper we explain why and how.
Abstract Organizations adopting Enterprise Resource Planning (ERP) are also adopting standard ERP-vendor-specific process models for engineering their requirements. Making successfully a live process out of such a model is hard. Maturity... more
Abstract Organizations adopting Enterprise Resource Planning (ERP) are also adopting standard ERP-vendor-specific process models for engineering their requirements. Making successfully a live process out of such a model is hard. Maturity assessment frameworks can help ERP adopters identify and understand those practices which help their ERP processes succeed and those which do not. This paper deploys a Requirements Engineering maturity model to examine variations in instantiations of a standard ERP RE process.
The articles appearing in IEEE Software are the result of hard work by many people. We deeply appreciate the efforts of everyone who participated in our peer review process last year (1 January to 31 December 2006). Authors often tell us... more
The articles appearing in IEEE Software are the result of hard work by many people. We deeply appreciate the efforts of everyone who participated in our peer review process last year (1 January to 31 December 2006). Authors often tell us how much they value reviewers' comments and suggestions. Their expertise, care, and attention help maintain Software's quality. Readers who'd like to contribute to our community by reviewing papers this year can visit www. computer. org/software/reviewers. htm for more information.
One of the main characteristics of agile software development is the active and continuous participation and involvement of the clients throughout the project. According to agile proponents, this leads to building 'the right'product and... more
One of the main characteristics of agile software development is the active and continuous participation and involvement of the clients throughout the project. According to agile proponents, this leads to building 'the right'product and to satisfied clients. In this paper we present a comparative study of two Dutch software development companies in respect to client participation and its impact on the project. One of the companies is purely agile while the other is following a traditional software development approach.
Abstract Recently, the Requirements Engineering (RE) community has become increasingly aware of the importance of carrying out industry-relevant research. Researchers and practitioners should be able to evaluate the relevance of their... more
Abstract Recently, the Requirements Engineering (RE) community has become increasingly aware of the importance of carrying out industry-relevant research. Researchers and practitioners should be able to evaluate the relevance of their empirical research to increase the likely adoption of RE methods in software industry. It is in this perspective that we evaluate 24 experimental studies on comprehensibility of software requirements specifications to determine their practical value.
Numerous software requirements specification (SRS) approaches have been proposed in software engineering. However, there has been little empirical evaluation of the use of these approaches in specific contexts. This paper describes the... more
Numerous software requirements specification (SRS) approaches have been proposed in software engineering. However, there has been little empirical evaluation of the use of these approaches in specific contexts. This paper describes the results of a mapping study, a key instrument of the evidence-based paradigm, in an effort to understand what aspects of SRS are evaluated, in which context, and by using which research method.
ABSTRACT Requirements (re) prioritization is an essential mechanism of agile development approaches to maximize the value for the clients and to accommodate changing requirements. Yet, in the agile Requirements Engineering (RE)... more
ABSTRACT Requirements (re) prioritization is an essential mechanism of agile development approaches to maximize the value for the clients and to accommodate changing requirements. Yet, in the agile Requirements Engineering (RE) literature, very little is known about how agile (re) prioritization happens in practice. Conceptual models about this process are missing, which, in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time.
Abstract. Business value is a key concept in agile software development. This paper presents results of a case study on how business value and its creation is perceived in the context of agile projects. Our overall conclusion is that the... more
Abstract. Business value is a key concept in agile software development. This paper presents results of a case study on how business value and its creation is perceived in the context of agile projects. Our overall conclusion is that the project participants almost never use an explicit and structured approach to guide the value creation throughout the project. Still, the application of agile methods in the studied cases leads to satisfied clients.
Non-functional requirements (NFRs) of software systems are a well known source of uncertainty in effort estimation. Yet, quantitatively approaching NFR early in a project is hard. This paper makes a step towards reducing the impact of... more
Non-functional requirements (NFRs) of software systems are a well known source of uncertainty in effort estimation. Yet, quantitatively approaching NFR early in a project is hard. This paper makes a step towards reducing the impact of uncertainty due to NRF. It offers a solution that incorporates NFRs into the functional size quantification process. The merits of our solution are twofold: first, it lets us quantitatively assess the NFR modeling process early in the project, and second, it lets us generate test cases for NFR verification purposes.
Abstract Agile requirements engineering is driven by creating business value for the client and heavily involves the client in decision-making under uncertainty. Real option thinking seems to be suitable in supporting the client's... more
Abstract Agile requirements engineering is driven by creating business value for the client and heavily involves the client in decision-making under uncertainty. Real option thinking seems to be suitable in supporting the client's decision making process at inter-iteration time. This paper investigates the fit between real option thinking and agile requirements engineering.
Abstract—There is an increased awareness of the roles that enterprise architecture (EA) and enterprise systems (ES) play in today's organizations. EA and ES usage maturity models are used to assess how well companies are capable of... more
Abstract—There is an increased awareness of the roles that enterprise architecture (EA) and enterprise systems (ES) play in today's organizations. EA and ES usage maturity models are used to assess how well companies are capable of deploying these two concepts while striving to achieve strategic corporate goals. The existence of various architecture and ES usage models raises questions about how they both refer to each other, eg if a higher level of architecture maturity implies a higher ES usage level.
Background: Requirements Engineering (RE) researchers recognize that for RE methods to be adopted in industry, practitioners should be able to evaluate the relevance of a study to their practice. Kitchenham et al proposed a set of... more
Background: Requirements Engineering (RE) researchers recognize that for RE methods to be adopted in industry, practitioners should be able to evaluate the relevance of a study to their practice. Kitchenham et al proposed a set of perspective-based checklists, which demonstrated to be a useful instrument for this purpose. Specifically, the checklist from the practitioner's perspective seems to be a good candidate for evaluating the relevance of RE studies to RE practice.
Developing the business case (BC) for an inter-organizational network is a major challenge. Factors like competition and differences in semantics between actors influence the stakeholders' willingness to share information necessary for... more
Developing the business case (BC) for an inter-organizational network is a major challenge. Factors like competition and differences in semantics between actors influence the stakeholders' willingness to share information necessary for the BC development. In this paper we develop an exploratory framework showing the effect that coordination structure and project scope have on the development of a shared BC.
Abstract The paper reports on first attempts to define, apply and fully integrate some reuse measurement practices into the SAP requirements engineering activities. It addresses all the facets of the context for SAP requirements reuse... more
Abstract The paper reports on first attempts to define, apply and fully integrate some reuse measurement practices into the SAP requirements engineering activities. It addresses all the facets of the context for SAP requirements reuse measurement and indicates who reuse metrics data are collected for, where and when during the RE process reuse measurements are made, what counting standards are appropriate, and what action items can be taken based on the reuse measurements
Abstract The tendency for non-functional requirements (NFRs) to have a wide-ranging impact on a software system, and the strong interdependencies and tradeoffs that exist between NFRs an the software project, leave typical existing... more
Abstract The tendency for non-functional requirements (NFRs) to have a wide-ranging impact on a software system, and the strong interdependencies and tradeoffs that exist between NFRs an the software project, leave typical existing software modeling methods incapable of integrating them into the software engineering. In this paper, we propose a metamodel which explicitly models FRs, NFRs, their refinements and their interdependencies.
Abstract.[Context and Motivation]. In recent years a number of checklists for empirical research in software engineering have been published. So far, the checklists for experimental research differ from those of observational research.... more
Abstract.[Context and Motivation]. In recent years a number of checklists for empirical research in software engineering have been published. So far, the checklists for experimental research differ from those of observational research. This leaves the important commonalities between these kinds of research unexploited. Recently, a unified checklist has been published that identifies the commonalities and identifies the difference between these two types of research.
This paper compares concepts of maturity models in the areas of Enterprise Architecture and Enterprise Systems Usage. We investigate whether these concepts correlate, overlap and explain each other. The two maturity models are applied in... more
This paper compares concepts of maturity models in the areas of Enterprise Architecture and Enterprise Systems Usage. We investigate whether these concepts correlate, overlap and explain each other. The two maturity models are applied in a case study. We conclude that although it is possible to fully relate constructs from both kinds of models, having a mature architecture function in a company does not imply a high Enterprise Systems Usage maturity.
Abstract Non-functional requirements (NFRs) pose unique challenges in estimating the effort it would take to implement them. This is mainly because of their unique nature; NFRs are subjective, relative, interactive and tending to have a... more
Abstract Non-functional requirements (NFRs) pose unique challenges in estimating the effort it would take to implement them. This is mainly because of their unique nature; NFRs are subjective, relative, interactive and tending to have a broad impact on the system as a whole. Nevertheless, it is crucial, when making decisions about the scope of software by given resources and budget, to furnish a justifying and quantitative analysis based on both functional requirements (FRs) and NFRs.
Abstract This paper reports on an experiment that investigates the predictability of software project size from software product size. The predictability research problem is analyzed at the stage of early requirements by accounting the... more
Abstract This paper reports on an experiment that investigates the predictability of software project size from software product size. The predictability research problem is analyzed at the stage of early requirements by accounting the size of functional requirements as well as the size of non-functional requirements. The experiment was carried out with 55 graduate students in Computer Science from Concordia University in Canada.
Desde los años sesenta la Ingeniería del Software (IS) ha inspirado la evolución en la forma de desarrollar software. Se han afirmado muchas cosas sobre esta disciplina, por lo que tendemos a creer que otro conjunto de contribuciones... more
Desde los años sesenta la Ingeniería del Software (IS) ha inspirado la evolución en la forma de desarrollar software. Se han afirmado muchas cosas sobre esta disciplina, por lo que tendemos a creer que otro conjunto de contribuciones sobre aspectos que se pueden encontrar frecuentemente en revistas y conferencias no ofrecerían a los lectores una visión diferente de cuales son los desafíos más importantes de esta disciplina.
Abstract This article reports on an experimental evaluation of a unified checklist for case study and experimental research. The checklist aims at exhibiting the underlying, shared, structure of observational and experimental research,... more
Abstract This article reports on an experimental evaluation of a unified checklist for case study and experimental research. The checklist aims at exhibiting the underlying, shared, structure of observational and experimental research, and is based on several published checklist in software engineering and other disciplines. We asked a small sample of subjects to apply it to two papers, one reporting on a case study and one reporting on an experiment.
Collective efforts of requirements engineering (RE) practitioners, consultants and researchers have yielded a huge variety of solutions for improving requirements processes and artifacts. While it is generally known that the suitability... more
Collective efforts of requirements engineering (RE) practitioners, consultants and researchers have yielded a huge variety of solutions for improving requirements processes and artifacts. While it is generally known that the suitability and effectiveness of most of these solutions is contingent to the context in which they are applied, the body of empirical studies that investigate which RE technique is better for which context, is relatively small (Cheng & Attlee, 2007).
Abstract Continuous and client-centric requirements reprioritization forms the very core of today's agile approaches. In this paper, we report on results of a grounded theory study on agile requirements prioritization methods. The outcome... more
Abstract Continuous and client-centric requirements reprioritization forms the very core of today's agile approaches. In this paper, we report on results of a grounded theory study on agile requirements prioritization methods. The outcome is a conceptual model for understanding the inter-iteration prioritization process from client's perspective. The latter is derived from the authors' experiences and by using empirical data, published earlier by other authors.
Abstract This focus group study presents our first validation of practices for engineering the coordination requirements in cross-organizational Enterprise Resource Planning (ERP) projects. The study evaluates 13 practices addressing a... more
Abstract This focus group study presents our first validation of practices for engineering the coordination requirements in cross-organizational Enterprise Resource Planning (ERP) projects. The study evaluates 13 practices addressing a variety of coordination aspects crucial to ERP projects. These practices are results in previously published research publications by the first author. The practices are formulated in response to practitioners' needs at ERP adopting organizations.
Abstract: This paper makes a first attempt towards improving the testing process in ERP projects by using a metric-based approach [ABU06] based on functional size measurement. The paper reports on how this approach was adapted to a... more
Abstract: This paper makes a first attempt towards improving the testing process in ERP projects by using a metric-based approach [ABU06] based on functional size measurement. The paper reports on how this approach was adapted to a ERP-package-specific project context, how it was applied to five settings in a mid-sized project, and what was learnt of doing it.
[Context and Motivation] Based on published output in the premium RE conferences and journals, we observe a growing body of research using both quantitative and qualitative research methods to help understand which RE technique, process... more
[Context and Motivation] Based on published output in the premium RE conferences and journals, we observe a growing body of research using both quantitative and qualitative research methods to help understand which RE technique, process or tool work better in which context. Also, more and more empirical studies in RE aim at comparing and evaluating alternative techniques that are solutions to common problems.
Abstract Agile software projects are characterized by iterative and incremental development, accommodation of changes and active customer participation. The process is driven by creating business value for the client, assuming that the... more
Abstract Agile software projects are characterized by iterative and incremental development, accommodation of changes and active customer participation. The process is driven by creating business value for the client, assuming that the client (i) is aware of it, and (ii) is capable to estimate the business value, associated with the separate features of the system to be implemented.
Abstract Continuous customer-centric requirements reprioritization is essential in successfully performing agile software development. Yet, in the agile RE literature, very little is known about how agile reprioritization happens in... more
Abstract Continuous customer-centric requirements reprioritization is essential in successfully performing agile software development. Yet, in the agile RE literature, very little is known about how agile reprioritization happens in practice. Generic conceptual models about this process are missing, which in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time.
Abstract Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory... more
Abstract Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory cross-case study on agile prioritization and business value delivery processes in eight software organizations.
El objetivo del presente trabajo es mostrar algunas de las tecnologías de información que pueden utilizarse para el desarrollo de memorias organizacionales, describiendo sus características generales, conocimiento que puede almacenarse en... more
El objetivo del presente trabajo es mostrar algunas de las tecnologías de información que pueden utilizarse para el desarrollo de memorias organizacionales, describiendo sus características generales, conocimiento que puede almacenarse en la memoria organizacional con ayuda de estas tecnologías, y las ventajas y desventajas en su utilización.
This paper presents the results of a detailed literature review on enterprise resource planning (ERP) benefits, carried out according to the guidelines by Webster et al.(2002). The identified benefits are mapped onto previously identified... more
This paper presents the results of a detailed literature review on enterprise resource planning (ERP) benefits, carried out according to the guidelines by Webster et al.(2002). The identified benefits are mapped onto previously identified benefit categories. Based on this mapping a list of literature gaps is identified and a three-dimensional conceptual benefit framework is developed. It is build upon several benefit dimensions and the balanced scorecard approach.
The goal of the BUSITAL workshop series is to provide a forum in which leading researchers and practitioners from around the world can discuss and advance the state-of-the-art research and practice in business/IT alignment. The specific... more
The goal of the BUSITAL workshop series is to provide a forum in which leading researchers and practitioners from around the world can discuss and advance the state-of-the-art research and practice in business/IT alignment. The specific goal of BUSITAL'07 is to investigate how well established and emerging conceptual modeling methods, techniques, and tools fit in solutions to confront the challenge of maintaining mutual alignment between business needs and IT assets.
Abstract Business-IT alignment is pervasive today, as organizations strive to achieve competitive advantage. Like in other areas, eg, software development, maintenance and IT services, there are maturity models to assess such alignment.... more
Abstract Business-IT alignment is pervasive today, as organizations strive to achieve competitive advantage. Like in other areas, eg, software development, maintenance and IT services, there are maturity models to assess such alignment. Those models, however, do not specifically address the aspects needed for achieving alignment between business and IT in inter-enterprise settings.
Abstract. Getting business stakeholders' goals formulated clearly and project scope defined realistically increases the chance of success for any application development process. As a consequence, stakeholders at early project stages... more
Abstract. Getting business stakeholders' goals formulated clearly and project scope defined realistically increases the chance of success for any application development process. As a consequence, stakeholders at early project stages acquire as much as possible knowledge about the requirements, their risk estimates and their prioritization.
Non-functional requirements (NFRs) of software systems are an important source of uncertainty in effort estimation. Furthermore, quantitatively approaching NFR early in a project is difficult. This paper makes a step towards reducing the... more
Non-functional requirements (NFRs) of software systems are an important source of uncertainty in effort estimation. Furthermore, quantitatively approaching NFR early in a project is difficult. This paper makes a step towards reducing the impact of uncertainty due to NFRs. It offers a new generic classification of the NFRs, and a NFR size measurement method (NFSM) that incorporates NFRs into the functional size quantification process.
CIOs can judge the effectiveness of their business-IT alignment activities by assessing maturity of processes in domains relevant to alignment. Currently, assessment instruments that support this are being developed. This paper reports on... more
CIOs can judge the effectiveness of their business-IT alignment activities by assessing maturity of processes in domains relevant to alignment. Currently, assessment instruments that support this are being developed. This paper reports on a case study aimed at validating four process domains we deemed necessary for inclusion in an assessment instrument that focuses on business-IT alignment at the level of inter-organizational collaboration.
How business and software analysts explore, document, and negotiate requirements for enterprise systems is critical to the benefits their organizations will eventually derive. In this paper, we present a framework for analysis and... more
How business and software analysts explore, document, and negotiate requirements for enterprise systems is critical to the benefits their organizations will eventually derive. In this paper, we present a framework for analysis and redesign of networked business systems. It is based on libraries of patterns which are derived from existing Internet businesses.
Abstract In early phases of the software cycle, requirements prioritization necessarily relies on the specified requirements and on predictions of benefit and cost of individual requirements. This paper presents results of a systematic... more
Abstract In early phases of the software cycle, requirements prioritization necessarily relies on the specified requirements and on predictions of benefit and cost of individual requirements. This paper presents results of a systematic review of literature, which investigates how existing methods approach the problem of requirements prioritization based on benefit and cost. From this review, it derives a set of under-researched issues which warrant future efforts and sketches an agenda for future research in this area.
Abstract In this paper, we build on previous work inferring lessons learnt from five years of experience in using generic offthe-shelf requirements engineering (RE) processes in Enterprise Resource Planning (ERP) projects [7]. We identify... more
Abstract In this paper, we build on previous work inferring lessons learnt from five years of experience in using generic offthe-shelf requirements engineering (RE) processes in Enterprise Resource Planning (ERP) projects [7]. We identify and discuss six ways that the application of a generic RE process model can succeed or fail. The distinction between success and failure is not always immediately evident.
Abstract In order to meet commitments in software projects, a realistic assessment must be made of project scope. Such an assessment relies on the availability of knowledge on the user-defined project requirements and their effort... more
Abstract In order to meet commitments in software projects, a realistic assessment must be made of project scope. Such an assessment relies on the availability of knowledge on the user-defined project requirements and their effort estimates and priorities, as well as their risk. This knowledge enables analysts, managers and software engineers to identify the most significant requirements from the list of requirements initially defined by the user.
1. Background Enterprise Resource Planning (ERP) projects have specific context factors, such as reuse levels, interdependent functionality, and use of a vendorspecific implementation methodology, which impose risks known to cause various... more
1. Background Enterprise Resource Planning (ERP) projects have specific context factors, such as reuse levels, interdependent functionality, and use of a vendorspecific implementation methodology, which impose risks known to cause various degrees of project failure. We tackle this issue from a portfolio management perspective. Our solution rests on other authors' work [3] and our experience in ERP requirements engineering [2].
Requirements specifications (RS) play a crucial role in software development projects as these documents serve as a source of information for a variety of roles involved in downstream activities like architecture, design, and testing.... more
Requirements specifications (RS) play a crucial role in software development projects as these documents serve as a source of information for a variety of roles involved in downstream activities like architecture, design, and testing. However, this fact poses a challenge to a requirements engineer that is responsible to create these specifications: different information needs and expectations have to be addressed that are strongly dependent on the particular role that the document stakeholders have within a project.
Abstract Agile requirements engineering is the approach of choice for many software producers whose realities include highly uncertain requirements, use of new development technology, and clients willing to explore the ways in which an... more
Abstract Agile requirements engineering is the approach of choice for many software producers whose realities include highly uncertain requirements, use of new development technology, and clients willing to explore the ways in which an evolving product can help their business goals. From customer's perspective, the activity of continuous requirements reprioritization forms the very core of today's agile approaches. However, the freedom for clients to do so does not come for free.