Due to dynamic nature of current software development methods, changes in requirements are embraced and given proper consideration. However, this triggers the rank reversal problem which involves re-prioritizing requirements based on stakeholders’ feedback. It incurs significant cost because of time elapsed in large number of human interactions. To solve this issue, a Semi-Automated Framework for soFtware Requirements priOritizatioN (SAFFRON) is presented in this paper. For a particular requirement, SAFFRON predicts appropriate stakeholders’ ratings to reduce human interactions. Initially, item-item collaborative filtering is utilized to estimate similarity between new and previously elicited requirements. Using this similarity, stakeholders who are most likely to rate requirements are determined. Afterwards, collaborative filtering based on latent factor model is used to predict ratings of those stakeholders. The proposed approach is implemented and tested on RALIC dataset. The results illustrate consistent correlation, similar to state of the art approaches, with the ground truth. In addition, SAFFRON requires 13.5-27 less human interaction for reprioritizing requirements.
Because of intense collaborative needs, requirements engineering is a challenge in global software development. How do distributed teams manage the development of requirements in environments that require significant cross-site collaboration and coordination? In this paper, we report research that used social network analysis to explore collaboration and awareness among team members during requirements management in an industrial distributed software team. Using the lens of a requirements-centred social network to group team members who work on a particular requirement, we collected data to characterize requirements-centric collaborations in a project, and to examine aspects of awareness of requirements changes within these networks. Our findings indicate organic patterns of collaboration involving considerable cross-site interaction, in which communication of changes was the most predominant reason for interaction. Although we did not find evidence that distance affects developers' awareness of remote team members who work on the same requirements, distance affected how accessible the remote colleagues were. We discuss implications for knowledge sharing and coordination of work on a requirement in distributed teams, and propose directions for the design of collaboration tools that support awareness in distributed requirements management. The importance of candidate software requirements can vary by orders of magnitude, yet most software providers do not have accurate and efficient means for selecting among them. The paper describes a case study at Ericsson Radio Systems AB of two techniques for software requirements prioritizing as a means for determining the importance of candidate requirements, a pairwise comparison technique and a numeral assignment technique. The results from the case study indicate that the pairwise comparison technique is an efficient informative and accurate means for finding the candidate requirements importance. We therefore recommend the pairwise comparison technique for software requirements prioritizing. At Ericsson we have extended its use in other development projects. Projects often fail because they overlook stakeholders. Unfortunately, existing stakeholder analysis tools only capture stakeholders' information, relying on experts to manually identify them. StakeSource is a web-based tool that automates stakeholder analysis. It "crowdsources" the stakeholders themselves for recommendations about other stakeholders and aggregates their answers using social network analysis.  Managing software projects can often degrade into fighting fires lit by the embers of unrecognized and unmanaged risks. Stakeholders are a recognized source of significant software project risk, but few researchers have focused on providing a practical method for identifying specific project stakeholders. Furthermore, no methods provide guidance in identifying and managing project risks arising from those stakeholders. We developed the outcome-based stakeholder risk assessment model to provide this practical guidance. OBSRAM offers the project team a step-by-step approach to identifying stakeholders during requirements engineering, identifying stakeholder influences on the project, identifying the project's impact on stakeholders, and assessing the risks that their potential negative responses pose. We illustrate OBSRAM using a case study of a simulated airline-crew-scheduling system project that aims to reduce aircraft ground turnaround time to 30 minutes or less