By Topic

Software Product Management (IWSPM), 2009 Third International Workshop on

Date 1-1 Sept. 2009

Filter Results

Displaying Results 1 - 8 of 8
  • The Agile Requirements Refinery: Applying SCRUM Principles to Software Product Management

    Publication Year: 2009 , Page(s): 1 - 10
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1269 KB) |  | HTML iconHTML  

    Although agile software development methods such as SCRUM and DSDM are gaining popularity, the consequences of applying agile principles to software product management have received little attention until now. In this paper, this gap is filled by the introduction of a method for the application of SCRUM principles to software product management. For this purpose, the 'agile requirements refinery' is presented, an extension to the SCRUM process that enables product managers to cope with large requirements in an agile development environment. A real-life case study is presented to illustrate how agile methods can be applied to software product management. The experiences of the case study company are provided as a set of lessons learned that will help others to apply agile principles to their software product management process. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Innovative Features Selection using Real Options Theory

    Publication Year: 2009 , Page(s): 11 - 14
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (226 KB) |  | HTML iconHTML  

    Innovation enables product differentiation and supports market growth. However, determining the value of an innovative feature is a difficult task due to the number of risks and uncertainties involved. This paper proposes the use of real options theory to support software product managers to decide whether to make an investment in an innovative feature or not. This approach creates a richer decision space, allowing for more informed decision- making, leading to greater return on potential. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Finance as a Stakeholder in Product Management

    Publication Year: 2009 , Page(s): 15 - 22
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (201 KB) |  | HTML iconHTML  

    The traditional literature of software product management focuses on sales, marketing and executive management as key internal stakeholders for the product manager. However in public companies and private companies positioning for a public offering, the importance of reported accounting revenue can cause the finance office to become a significant additional stakeholder. The concerns of finance can cause significant impacts on the offering, apart from those driven by market needs and other stakeholders. The struggle to balance these competing interests is particularly acute for B2B software offerings during the market entry phase, offerings that include a significant service component and offerings delivered under a software-as-a-service (SaaS) arrangement. This paper will describe some of the common concerns of the finance office, describe the impacts to the offering they create, and offer suggestions to the product manager on how to address those concerns. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Investigating Upstream versus Downstream Decision-Making in Software Product Management

    Publication Year: 2009 , Page(s): 23 - 26
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (412 KB) |  | HTML iconHTML  

    Decision outcomes and their lead times are critical in product management, as the market success of a product may strongly depend on the both the decisions themselves and their timing in relation to the market and competitors. This paper presents an investigation of one particular industrial case study data set by comparing upstream scoping decisions with downstream change decision. The results in this case indicate that changes are more likely to be accepted during upstream decision-making compared to downstream. We also found that the most common value for upstream decision lead-time is three days, while only one day for downstream. The results trigger a general discussion on factors that may impact or explain decision lead-time. Assumptions and questions for further investigation in the context of product management decision-making are proposed. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Software Product Line Engineering with Personas

    Publication Year: 2009 , Page(s): 27 - 30
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (266 KB) |  | HTML iconHTML  

    In this paper, a user-centered and mass-customized design process is proposed that unifies Personas and Software Product Line Engineering (SPLE). The key to this proposal is the relationship between persona-weighted feature matrices and product-feature matrices. We propose a development method that (1) creates personas before the product portfolio scoping stage, and (2) adds extra personas during the application engineering stage. Applicable domains are discussed, and methods for evaluating the approach are reported. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Towards a Unified Framework for Contextual Variability in Requirements

    Publication Year: 2009 , Page(s): 31 - 34
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (214 KB) |  | HTML iconHTML  

    Context is a significant factor in deciding the set of requirements relevant to a system (i.e., software product construction), the alternatives the system can adopt to satisfy these requirements, and the quality assessment of each alternative. By context we mean the conditions in the operating environment of an system that influences how the system should behave in different situations. However, the relationship between context and requirements can be challenging to capture and analyze. Presently this area of requirements engineering is largely under-researched. In this position paper, we discuss several ways by which context can be related to requirements and subsequently used for product derivation. We outline an approach that facilitates better understanding and use of contextual information in requirements. Our approach integrates three requirements engineering approaches - goal modeling, feature modeling, and problem frames - and is aimed at facilitating treatment of contextual variability in requirements. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A Study on the Importance of Order in Requirements Prioritisation

    Publication Year: 2009 , Page(s): 35 - 41
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (102 KB) |  | HTML iconHTML  

    A key principle when performing research studies is that of randomisation, in order to counter any effects that the ordering of tasks, elements, subjects, etc. may have on the dependent variables. When performing requirements prioritisation, it is not always possible (e.g., because of how prioritisation methods are constructed) or even desirable to randomise all requirements before prioritising them. It is thus important to know the effect that the initial order of the requirements will have on their final priorities, and this is studied in this article. The results indicate that the initial order of elements does not significantly influence the resulting priorities of the most and least important requirements, but that it does indeed influence the results when looking at all of the requirements. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Lightweight Elicitation and Analysis of Software Product Quality Goals: A Multiple Industrial Case Study

    Publication Year: 2009 , Page(s): 42 - 52
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (258 KB) |  | HTML iconHTML  

    We developed and used a method that gathers relevant stakeholders to elicit, prioritize, and elaborate the quality goals of a software product. It is designed to be lightweight and easy to learn compared to methods for a more comprehensive analysis of non-functional requirements. The method and the resulting quality goals are meant especially for improving the software product management process. We used it in four software product companies, and report lessons learned and evaluation of the method based on practitioners' comments. We found it better to set the goals first for the product in general before discussing a specific release project. In addition to identifying goals that needed improvement, the practitioners considered identifying already achieved goals relevant, but they were neg- lected unless explicitly considered. Using ISO 9126 as a checklist after brainstorming did not add many goals. Prioritization was challenging due to numerous relevant perspectives. Conceiving measures for impor- tant goals seemed to concretize them. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.