A Study of the Impact of Requirements Volatility on Software Project Performance

Software development is considered to be a dynamic process where demands for changes seem to be inevitable. Modifications to software are prompted by all kinds of changes including changes to the requirements. This type of changes gives rise to an intrinsic volatility, which has several impacts on the software development lifecycle. This paper describes our findings of an extensive survey based empirical study of requirement volatility (RV) and its impact on software project performance. In particular, findings reveal that requirement volatility has a significant impact on schedule overrun and cost overrun in software projects. Our investigation also examined factors that contribute to the extent of requirement volatility and found that variables such as frequent communications between users and developers and usage of a definable methodology in requirements analysis and modeling have impact on the stability of requirements

Looking for Reasons behind Success in Dealing with Requirements Change

During development, requirements of software systems are subject to change. Unfortunately, managing changing requirements can take a lot of time and effort. Yet some companies show a better management of changes in requirements than others. Why? What is it that makes some projects deal with changing requirements better than others? We pursue the long term goal of understanding the mechanisms used to successfully deal with change in requirements. In this paper we gather knowledge about the state-of-the-art and the state-of-practice. We studied eight software development projects in four different companies --large and small, inclined toward structured and toward agile principles of development--, interviewing their project managers and analyzing their answers. Our findings include a list of practical (rather than theoretical) factors affecting the ability to cope with small changes in requirements. Results suggest a central role of size as a factor determining the flexibility showed either by the organization or by the software development team. We report the research method used and validate our results via expert interviews, who could relate to our findings

Reconciling Synthesis and Decomposition: A Composite Approach to Capability Identification

Stakeholders' expectations and technology constantly evolve during the lengthy development cycles of a large-scale computer based system. Consequently, the traditional approach of baselining requirements results in an unsatisfactory system because it is ill-equipped to accommodate such change. In contrast, systems constructed on the basis of Capabilities are more change-tolerant; Capabilities are functional abstractions that are neither as amorphous as user needs nor as rigid as system requirements. Alternatively, Capabilities are aggregates that capture desired functionality from the users' needs, and are designed to exhibit desirable software engineering characteristics of high cohesion, low coupling and optimum abstraction levels. To formulate these functional abstractions we develop and investigate two algorithms for Capability identification: Synthesis and Decomposition. The synthesis algorithm aggregates detailed rudimentary elements of the system to form Capabilities. In contrast, the decomposition algorithm determines Capabilities by recursively partitioning the overall mission of the system into more detailed entities. Empirical analysis on a small computer based library system reveals that neither approach is sufficient by itself. However, a composite algorithm based on a complementary approach reconciling the two polar perspectives results in a more feasible set of Capabilities. In particular, the composite algorithm formulates Capabilities using the cohesion and coupling measures as defined by the decomposition algorithm and the abstraction level as determined by the synthesis algorithm.Comment: This paper appears in the 14th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS); 10 pages, 9 figure

Information System Development Team Collaboration Antecedents

Despite information system development companies have invested substantial resources to support the success of information system development (ISD) projects, the failure rate is still high. Extant studies indicated that the constant changes from socio-technical environments are the main causes of the low success rate. This study argues that team collaboration is a key factor to effectively cope with unexpected disruptions that would have negative effect on overall software product success. This study proposes a research model exploring factors that influence the development of team collaboration. These factors include the team commitment, transactive memory systems (TMS), and collective mind. In addition, the study suggests that the collective mind has an intermediate effect on the team commitment, TMS, and team collaboration. This study takes the information development teams of various companies in Taiwan as its subjects

Using card sorting technique to classify requirements change

Requirements Volatility is considered to be a major source of risk to the management of large and complex software projects. The ability to characterise the nature and origins of requirements change during software development is important and can lead organisations towards more effective management of changing requirements. This paper focuses on a study to establish how practitioners classify requirements change requests. We used the Card Sorting method to identify categories of change requests that software developers use in practice. Card sorting is a knowledge elicitation method that is commonly used for capturing information about different ways of representing domain knowledge. This study has allowed us to get valuable insights into the way practitioners classify change requests and to understand their perspectives on classification. This classification is a valuable source of information in prioritizing change requests and assessing their impact. Our findings from the card sorting exercise further reveal that the criteria used for categorization are related to the role the practitioner plays in the software development team and the nature and extent of their responsibilities. © 2004 IEEE

Analysis of requirements volatility during software development life cycle

Investigating the factors that drive requirements change is an important prerequisite for understanding the nature of requirements volatility. This increased understanding will improve the process of requirements change management. This paper mainly focuses on change analysis to identify and characterize the causes of requirements volatility. We apply a causal analysis method on change request data to develop a taxonomy of change. This taxonomy allows us to identify and trace the problems, reasons and sources of changes. Adopting an industrial case study approach, our findings reveal that the main causes of requirements volatility were changes in customer needs (or market demands), developers' increased understanding of the products, and changes in the organization policy. During the development process, we also examined the extent of requirements volatility and discovered that the rate of volatility was high at the time of requirements specification completion and while functional specification reviews were conducted

Managing conflicts among non-functional requirements

Abstractâ Non-functional requirements (NFRs) tend to interfere, conflict, and contradict with one other. Unlike functional requirements, this inevitable conflict arises as a result of inherent contradiction among various types of NFRs. A number of techniques to deal with this conflict have been developed. Majority of them focus on categorizing, documenting, or listing the potential conflicts among NFRs. Several models that represent the positive or negative relationships among NFRs have also been published in literature. However, the interpretation of NFRs may vary depending on numerous factors, such as the context of the system being developed and stakeholder involvement. Consequently, the relationships among them are not always obvious. This paper investigates the gaps in the existing research literature about the conflicts among NFRs and proposes a framework to manage this type of conflict

Universality of Egoless Behavior of Software Engineering Students

Software organizations have relied on process and technology initiatives to compete in a highly globalized world. Unfortunately, that has led to little or no success. We propose that the organizations start working on people initiatives, such as inspiring egoless behavior among software developers. This paper proposes a multi-stage approach to develop egoless behavior and discusses the universality of the egoless behavior by studying cohorts from three different countries, i.e., Japan, India, and Canada. The three stages in the approach are self-assessment, peer validation, and action plan development. The paper covers the first stage of self-assssment using an instrument based on Lamont Adams’ Ten commandments (factors) of egoless programming – seven of the factors are general, whereas three are related to coding behavior. We found traces of universality in the egoless behavior among the three cohorts such as there was no difference in egoless behaviours between Indian and Canadian cohorts and both Indian and Japanese cohorts had difficulties in behaving in egoless manner in coding activities than in general activities