A product management challenge: Creating software product value through requirements selection

Barney, Sebastian; Aurum, Aybüke; Wohlin, Claes

doi:10.1016/j.sysarc.2007.12.004

Cited by 102 publications

(99 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…There are two possible explanation for this outcome; either the participants believe that the various aspects should be more equal in importance, or when presented with a list of important things, there is a desire to make everything more equal. This result has also been seen in previous studies [33], [2], but there is at least one exception [3].…”

Section: Discussionsupporting

confidence: 89%

Balancing software product investments

Barney

Wohlin

Aurum

2009

2009 3rd International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

Abstract-The long-term sustainability of a software product depends on more than developing features. Priorities are placed on aspects that support the development of software, like software product quality (eg. ISO 9126), project constraints -time and cost, and even the development of intellectual capital (IC). A greater focus on any one aspect takes priority from another, but as each aspects delivers a different type of value managers have trouble comparing and balancing these aspects. This paper presents a method to help determine the balance between key priorities in the software development process. The method is applied to a new case study, that also combines with results from previous studies. The results show it is possible to compare features, quality, time, cost and IC in a comprehensive way, with the case study showing that participants perceive a change from a shorter-term product perspective to a longer-term organisation beneficial to the business.

show abstract

Section: Discussionsupporting

confidence: 89%

Balancing software product investments

Barney

Wohlin

Aurum

2009

2009 3rd International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

show abstract

“…Moreover, in 19 of the 49 papers the findings can be generalised, and in a further 26 papers the findings can be partially generalised. One reason for the large number of partially generalisable results is that most of the studies use [5] Barney, Aurum, and Wohlin, "A product management challenge: Creating software product value through requirements selection" p38 [24] Fricker, Gorschek, and Glinz, "Goal-oriented requirements communication in new product development" p39 [2] Akker et al, "Software Product Release Planning through Optimization and What-If Analysis" p40 [33] Herrmann and Daneva, "Requirements prioritization based on benefit and cost prediction: An agenda for future research" p41 [60] Mohamed and Wahba, "Value estimation for software product management" p42 [70] Regnell, Berntsson-Svensson, and Olsson, "Supporting Road-Mapping of Quality Requirements" p43 [8] Berntsson Svensson, Gorschek, and Regnell, "Quality requirements in practice: An interview study in requirements engineering for embedded systems" p44 [86] Wilby, "Roadmap transformation: from obstacle to catalyst" p45 [ Can the findings of the study be generalised?…”

Section: General Characteristicamentioning

confidence: 99%

“…19 26 4 qualitative research methodologies that do not focus on generalising the results [5]. However, many of the results can still be generalised given that the research participants are selected carefully and the research field and result are described in detail [58].…”

Section: General Characteristicamentioning

confidence: 99%

Uni-REPM: a framework for requirements engineering process assessment

et al. 2013

View full text Add to dashboard Cite

PostprintThis is the accepted version of a paper published in Requirements Engineering. This paper has been peer-reviewed but does not include the final publisher proof-corrections or journal pagination.Citation for the original published paper (version of record):Svahnberg, M., Gorschek, T., Nguyen, T., Nguyen, M. (2015) Uni-REPM: a framework for requirements engineering process assessment. (will be inserted by the editor) Uni-REPM -a Framework for Requirements Engineering Process AssessmentMikael Svahnberg · Tony Gorschek · Thi Than Loan Nguyen · Mai Nguyen the date of receipt and acceptance should be inserted later Abstract Context. It has been shown that potential business benefits could be achieved by assessing and improving the requirements engineering (RE) process. However, process assessment models such as CMMI and ISO9000 only cover RE shallowly. Tailored models such as REGPG and REPM, on the other hand, do not cover market-driven requirements engineering. Other attempts, such as MDREPM covers market-driven requirements engineering, but correspondlingly neglects bespoke requirements engineering. Moreover, the area itself has evolved so practices that once were cutting edge are now commonplace. Objectives. In this article we develop and evaluate a unified requirements engineering process maturity model (Uni-REPM) that can be used in a market-driven as well as a bespoke context. This model is based on REPM, but has evolved to reflect contemporary requirements engineering practices. Methods. Uni-REPM is primarily created based on a systematic literature review of market-driven requirements engineering practices and a literature review of bespoke practices. Conclusions. Based on the results, Uni-REPM is formulated. The objective of Uni-REPM is twofold. Firstly, it is expected to be applicable for assessing the maturity of RE processes in various scenarios where an organization would use different development approaches. Secondly, it instructs practitioners about which RE practices to perform and their expected benefits. As an assessment instrument, Uni-REPM provides a simple and low cost solution for practitioners to identify the status of their RE process. As a guidance tool, Uni-REPM lessens the gap between theoretical and practical worlds by transferring the available RE technologies from research to industry practice.

show abstract

“…Our technical person will do the transfer of technology while they support the maintenance. The critical success factor for Software Company is to respond quickly to changing requirements while maintaining but they have the expertise [20]. The outsourcing company more knew the policy, security and workflow.…”

Section: B the Weakness Analysis From People Perspectivementioning

confidence: 99%

The Important Role of People, Process and Technology during Software Project Requirement

Haron¹,

Sahibuddin²,

Harun³

et al. 2013

IJMLC

View full text Add to dashboard Cite

Abstract-The need of organisation is to enhance the services through Malaysian Public Sector system application. This paper described the role of people, process and technology during software project requirement in Malaysian Public Sector. We have done the survey to the IT Manager in Malaysian Public Sector. The Public Sector IT Manager contributed their working experienced and knowledge for the survey. The purpose of the survey is to determine the RE practice that implemented during software project requirement. We also determine the role for people, process and technology during the software project requirement. The result shows that 79.7 percent of IT Manager in Malaysia Public Sector has roles in software project requirement such as project leader, project manager and team leader. Some of them have to be a consultant to other agency or organization. They play their roles in business rules, business process indirectly.Index Terms-Requirement engineering, requirement engineering process, SWOT analysis, software project success factor. I. INTRODUCTIONThe software project success factor (SPSF) involved during software project development is People, Process, and Technology. Why we need to remind the important of these components? The IT Personnel more often believe they can predict the user needs. They also think that they understand the business well, better than the user, and try to force their ideas on the users [1] . Wherever, the stakeholder always blame that they know what they want through the experience of they manage the business process.Meanwhile, these groups of people did not realize that sometime the technology has the constraint to fulfill their needs. Analysis may often be carried by IT Personnel without involving people skills and the domain knowledge to understand a client's need. There are; misunderstanding, misalignment and miscommunication will arise during the analysis and negotiation process. This paper is divided into six sections. The first section comprises this introduction. The second section presents some software project related work. The third section provides a brief of research method. In fourth section, we presented the finding. In fifth section, we described experimental study that was implemented in Malaysian Public Sector. Finally, the sixth section, we present some conclusion. II. RELATED WORKThe experience on software project development to IT Personnel is increase but still they have not learned enough to ensure that our software development projects are successful. People who involved in setting up the application system have been struggling with how to come up with a highly credible site, and included some comments with regards to sites credibility [5]. The failed projects reviewed were mostly huge and the failure factors were not just management factors but also included technical factors [2]. The technical factor such as software and hardware is to support ICT infrastructure in the organization. Another factor to be considered is IT Personnel that involve in requirement...

show abstract

A product management challenge: Creating software product value through requirements selection

Cited by 102 publications

References 12 publications

Balancing software product investments

Balancing software product investments

Uni-REPM: a framework for requirements engineering process assessment

The Important Role of People, Process and Technology during Software Project Requirement

Contact Info

Product

Resources

About