Requirement Prioritization Decision Factors for Agile Development Environments

In an agile development environment, project planners continuously prioritize work tasks so requirements that provide the most value are delivered first. This strategy is based on Value Based Software Engineering principles that different requirements deliver different levels of value and diverse stakeholders view the importance of the value of various requirements differently and thus, will prioritize them differently. However, we found that there are several core values that stakeholders have more agreement in terms of relevancy and importance than others. By knowing these core values, project planners have increased insights as to which requirements should be prioritized higher, hence, hopefully increasing overall stakeholder satisfaction and reducing project risk

Adding Value to Software Requirements： An Empirical Study in the Chinese Software Industry

The rapid growth of the Chinese software industry has attracted attention from all over the world. Meanwhile, software requirements selection has a crucial impact on the final value of a software product and the satisfaction of stakeholders. This paper presents an empirical study, which focuses on the decision-making criteria for requirements selection in market-driven software development projects in international companies in China. The outcome shows that some criteria, such as business strategy, customer satisfaction, and software features, are more important than others when making decisions for requirements selection

Repetition between stakeholder (user) and system requirements

Stakeholder requirements (also known as user requirements) are defined at an early stage of a software project to describe the problem(s) to be solved. At a later stage, abstract solutions to those problems are prescribed in system requirements. The quality of these requirements has long been linked to the quality of the software system and its development or procurement process. However, little is known about the quality defect of redundancy between these two sets of requirements. Previous literature is anecdotal rather than exploratory, and so this paper empirically investigates its occurrence and consequences with a case study from a UK defense contractor. We report on a survey of sixteen consultants to understand their perception of the problem, and on an analysis of real-world software requirements documents using natural language processing techniques. We found that three quarters of the consultants had seen repetition in at least half of their projects. Additionally, we found that on average, a third of the requirement pairs’ (comprised of a system and its related stakeholder requirement) description fields were repeated such that one requirement in the pair added only trivial information. That is, solutions were described twice while their respective problems were not described, which ultimately lead to suboptimal decisions later in the development process, as well as reduced motivation to read the requirements set. Furthermore, the requirement fields considered to be secondary to the primary “description” field, such as the “rationale” or “fit criterion” fields, had considerably more repetition within UR–SysR pairs. Finally, given that the UR–SysR repetition phenomena received most of its discussion in the literature over a decade ago, it is interesting that the survey participants did not consider its occurrence to have declined since then. We provide recommendations on preventing the defect, and describe the freely available tool developed to automatically detect its occurrence and alleviate its consequences

The hidden pitfalls of Kanban in software development

ABSTRACT: Objectives of the Study: The objective of this thesis is to explore the hidden pitfalls of Kanban in software development. The aim is to discover the reasons behind the pitfalls and actions that nourish Kanban's failure. Academic background and methodology: Software development industry has been shifting towards more iterative, responsive and people-oriented development methods, which present the values of lean and agile thinking. Being characterized as the antidote for bureaucracy, the shift towards agile development methodologies has been one of the most significant factors affecting the software industry. Kanban as an agile change management framework has been perceived as the fairy godmother of software development making the reasons behind struggling Kanban projects particularly interesting. Thesis interviews five agile experts in the software development and studies their experiences of unsuccessful Kanban implementations. Emphasis is given to similar experiences and perceptions on how Kanban fails to redeem its value proposition. Findings: The primary finding of the study is that an organization that is unable to change its mindset to support Kanban is a pitfall affecting the whole project, inevitably causing Kanban to fail. This is a challenge that all agile methods have in common. Agile can flourish only when agile values are being appreciated. The secondary finding is that many software teams claiming to be using Kanban have implemented only a shallow imitation of the real method thus creating a superficial implementation, which prevents achieving Kanban induced benefits. Thus, creating a superficial implementation, which prevents achieving Kanban induced benefits. Furthermore, the erroneous human interpretation of what Kanban really is and how to apply it correctly is a key factor contributing to the emerge of the pitfalls. Keywords: Kanban, software development, pitfall, agile, change management, framewor

Impact estimation: IT priority decisions

Given resource constraints, prioritization is a fundamental process within systems engineering to decide what to implement. However, there is little guidance about this process and existing IT prioritization methods have several problems, including failing to adequately cater for stakeholder value. In response to these issues, this research proposes an extension to an existing prioritization method, Impact Estimation (IE) to create Value Impact Estimation (VIE). VIE extends IE to cater for multiple stakeholder viewpoints and to move towards better capture of explicit stakeholder value. The use of metrics offers VIE the means of expressing stakeholder value that relates directly to real world data and so is informative to stakeholders and decision makers. Having been derived from prioritization factors found in the literature, stakeholder value has been developed into a multi-dimensional, composite concept, associated with other fundamental system concepts: objectives, requirements, designs, increment plans, increment deliverables and system contexts. VIE supports the prioritization process by showing where the stakeholder value resides for the proposed system changes. The prioritization method was proven to work by exposing it to three live projects, which served as case studies to this research. The use of the extended prioritization method was seen as very beneficial. Based on the three case studies, it is possible to say that the method produces two major benefits: the calculation of the stakeholder value to cost ratios (a form of ROI) and the system understanding gained through creating the VIE table

Social Network monitoring

Aquest Treball Final de Grau implementa una eina per monitoritzar els comentaris i mencions que es fan sobre les fotografies que publiquem en la compte d'Instagram. Durant el procés de monitorització s'obtenen diverses dades i metadades associades als recursos monitoritzats (comentaris i mencions). Per tal d'obtindre major suport i fiabilitat, hem fet ús de l'API oficial d'Instagram (Facebook), la Graph API. Aquesta API està en constant evolució i va incorporant noves funcionalitats. L'arquitectura del sistema implementat permetrà que aquestes es puguin incorporar de manera fàcil, així com poder modificar les dades i metadades que s'obtenen durant el procés de monitorització. Així doncs, el nostre sistema és fàcil de mantenir i ampliar.Monitoring consists on continuously checking the status of a system due to ensure the reliability, security or, simply, giving information to the user. This is a process that requires many resources, both software and hardware. Depending on the information received by the system user, the user may decide one or another course of action. Assuming the fact of monitoring various social networks, how could an efficient software architecture be used and allow these social networks monitoring? Based on this premise, this TFG tries to give a response to this fact