OVER-REQUIREMENT IN SOFTWARE DEVELOPMENT: AN EMPIRICAL INVESTIGATION OF THE \u27IKEA\u27 EFFECT

One of the major risks in software development projects is the phenomenon of Over-Requirement, also known as over-specification and gold-plating, where a product or a service is specified beyond the actual requirements of the customer or the market. We argue that Over-Requirement is partially due to the emotional involvement of developers with specified features, an involvement associated with the IKEA or the I-designed-it-myself effect, which implies that people come to overvalue their creations when successfully designed or constructed by them. To investigate this argument, we conducted an experiment in the context of software development in which over 200 undergraduate students participated. The experiment required participants to complete a specification task and measured the change in perceived valuation of a specified nice-to-have feature, by measuring it before and after its specification was completed. The experiment results confirmed the existence of the IKEA effect and its influence on Over-Requirement. The results also imply that the IKEA effect in software development is multifaceted where the level of specification difficulty, whether objective difficulty (in terms of constrained specification duration or unconstrained specification freedom) or subjective difficulty (as reported by participants), affects the magnitude of the IKEA effect

On the nature, origins and outcomes of Over Featuring in the new product development process

Developing new products and services beyond what is required by the needs of users, market demand and the resources of companies ranks among the top 10 risks leading to new product development (NPD) failures. This study defines and refers to this multifaceted phenomenon as ‘Over Featuring’ (OVF) to group different forms of excessive product development, from scope creep to overspecification and feature creep. The classification and theoretical development of the various forms of OVF is proposed, also origins and adverse outcomes, such as feature fatigue, are explored. Stage-Gate and Agile approaches are discussed in the light of the OVF phenomenon

Agility is responsiveness to change: An essential definition

There is some ambiguity of what agile means in both research and practice. Authors have suggested a diversity of different definitions, through which it is difficult to interpret what agile really is. The concept, however, exists in its implementation through agile practices. In this vision paper, we argue that adopting an agile approach boils down to being more responsive to change. To support this claim, we relate agile principles, practices, the agile manifesto, and our own experiences to this core definition. We envision that agile transformations would be, and are, much easier using this definition and contextualizing its implications

Improving Scrum User Stories and Product Backlog Using Work System Snapshots

Lack of domain knowledge is often considered a reason for improper elicitation and specification of requirements of a software system. The work system method helps analysts understand the business situation to be supported by the software system. This research investigates the effects of preparing a work system snapshot, a key artifact of the work system method, on the quality of initial requirements specifications represented within the Scrum methodology. Those specifications take the form of a product backlog, a set of user stories to be addressed). The findings from a controlled experiment conducted with 165 students in a software engineering course indicate that the preparation of work system snapshot results in a significant reduction in invalid user stories and increase in valid user stories in the product backlog

The Planning Fallacy as an Explanation for Over-Requirement in Software Development

Over-Requirement occurs in software development projects when a software product is specified beyond the actual needs. This study shows empirically that Over-Requirement happens partially due to the Planning Fallacy, i.e., the tendency of people to underestimate the time needed to complete a task. Underestimating the time needed to develop a software feature during project planning, we argue, may lead to including within the project scope more required and unrequired features than can be completed by the project deadline. To investigate this argument, we conducted an experiment in which participants were asked to estimate the time it would take to develop various software features in a software development project and then, given the project\u27s duration, to recommend which of the features to include within scope. The results confirmed that the Planning Fallacy occurs in the context of software development and influences the Over-Requirement phenomenon

Better Use Case Diagrams by Using Work System Snapshots

Research to date shows significant variability in the success of applying the common technique of use case diagramming for identifying information system scope in terms of use cases performed by actors interacting with an information system or performed automatically by the information system. The current research tests a) the benefits of using a work system snapshot, a basic analytical tool from the work system method, before producing use case diagrams, and b) the additional benefits of enhancing use case diagramming constructs to distinguish between automated activities, activities supported by the information system, and relevant manual activities. Teams of student subjects in an experiment produced substantially better use case diagrams - containing far more use cases and qualitatively better use cases than did the teams in control group - when provided with a work system snapshot that summarized a test scenario in terms of work system concept

Detection of early warning signals for overruns in IS projects: linguistic analysis of business case language

Many Information Systems (IS) projects fail to be completed within budget and on schedule. A contributing factor is the so-called planning fallacy in which people tend to underestimate the resources required to complete a project. In this paper, we propose that signals of the planning fallacy can be detected in a project’s business case. We investigated whether language usage in business cases can serve as an early warning signal for overruns in IS projects. Drawing on two theoretical perspectives–t

Developing software beyond customer needs and plans: An exploratory study of its forms and individual-level drivers

Excessive software development is the tendency to develop new software above and beyond the requirements of the market and/or planned specifications. It is a widespread phenomenon involving both risks and flexibility advantages. As it represents a challenging dilemma for software developers, it is important to study its human origins. Drawing on the tripartite model of individual attitudes, this study investigates the influence of developers’s cognitive (intuitive and rational thinking styles), affective (emotional attachment) and behavioural (reliance on past experiences) traits on two forms of excess, beyond needs and beyond plans. Using survey data on 307 software developers, this study shows that different manifestations of excess are associated with distinct traits of software developers. Emotional attachment drives beyond needs excess. A positive (negative) association is found between relying on past experiences and beyond needs excess (beyond plans excess). An intuitive cognitive style fosters the inclusion of extra features in the new product scope, whereas a rational style might lead to developing one-size-fits-all software that targets the needs of a broad user base. These findings contribute to research on the development of digital new products and production technologies by offering a comprehensive yet fine-grained picture of excessive software development’s nature and drivers

Issues in public information systems development: The impact of regionalised organisational structure

This thesis was submitted for the degree of Doctor of Philosophy and awarded by Brunel UniversityThis thesis highlights the critical impact the effects of regionalised organisational structure and external political pressures have on the development of public sector information systems. Through the extension of a socio-technical systems (STS) model which encompasses these effects, a tool is provided for their investigation and evaluation in past and present information system (IS) developments. The foundations for this model were derived through an in-depth study of a large scale, national public IS development. Despite a large volume of research into the development and implementation of information systems, a high incidence of failure of such projects is still observed. With information systems now commonly integrated into many facets of an organisation’s business processes the costs and consequences of such failures can be far reaching. Given the additional scope and scale of many national public sector projects such consequences can be profound. While public sector IS failure has been studied in the literature, its focus is observed to be primarily that of an examination of e-government systems, neglecting the back-end (non-public facing) support systems. The focus of such studies is predominantly on the public’s interface and interaction with these systems together with their adoption and acceptance by the public. This view is a valid contribution but it does not inform the literature on the full range of unique problems that can be encountered across a complete IS development lifecycle within the public sector. Seeking to investigate these matters further, a collaboration was formed with a UK public body to facilitate the examination of the issues affecting the development and implementation of a national IS project. Onsite observations, interviews and document sampling were used across the development cycle to gather information from the perspectives of the stakeholders involved. The analysis of the data collected from this exercise highlighted a number of factors that were observed to have a significant effect on the project’s ultimate failure. Examination of this analysis from an STS perspective allowed for the extension of an existing STS model. It was extended to encompass the significant adverse effects that an organisational regionalised structure and external political pressure placed on the development of public information systems