Conference Paper

A Conceptual Model for Capturing Stakeholders' Wish List

To read the full-text of this research, you can request a copy directly from the author.


Requirements Engineering is a key activity in the development of software systems and is concerned with the identification of the goals of stakeholders and their elaboration into precise statements of desired services and behavior. Study shows that majority of the software development projects fail because of lack of understanding the requirements clearly and non-involvement of key stakeholders. For the successful software product to be developed it is important to identify relevant stakeholders and involve them during requirements elicitation process. Conflicts in requirements of different stakeholders are bound to happen. These conflicts have to be negotiated and balanced in order to develop a competitive software product. This paper proposes a conceptual model to identify and prioritize relevant stakeholders in a project, determining who and how important they are, provide a common understanding for stakeholders involved, together with the requirements, functions and systems of the product being designed.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the author.

... ( Ballejos and Montagna 2006;Ballejos and Montagna 2008a;Davison et al. 2006;Greer and Ruhe 2004;Kulkarni 2008;McManus 2004;Mitchell et al. 1997;Parent and Deephouse 2007;Poloudi 1997;Poloudi et al. 2004;and, Young et al. 2001). ...
... ( Arguello and Callan 2007;Couhglan and Macredie 2002;Coughlan et al. 2003;Glinz and Wieringa 2007;Kaiya et al. 2005;Oshiro et al. 2003;Pahl 2004;and;Sharp et al.1999) 8 Priority interests in the project ( Ballejos and Montagna 2006;Ballejos and Montagna 2008a;Davison et al. 2006;Greer and Ruhe 2004;Kulkarni 2008;Mitchell et al. 1997;Parent and Deephouse 2007;Poloudi 1997;Poloudi et al. 2004) 9 ...
This paper presents a systematic review of relevant published studies related to topics in Requirements Engineering, specifically, concerning stakeholder identification methods in requirements elicitation, dated from 1984 to 2011. Addressing four specific research questions, this systematic literature review shows the following evidence gathered from these studies: current status of stakeholder identification in software requirement elicitation, the best practices recommended for its performance, consequences of incorrect identification in requirements quality, and, aspects which need to be improved. Our findings suggest that the analyzed approaches still have serious limitations in terms of covering all aspects of stakeholder identification as an important part of requirements elicitation. However, through correctly identifying and understanding the stakeholders, it is possible to develop high quality software.
... Hence, it is essential to execute an adaptation assessment of the contributions of stakeholders and their interests in the project (Pacheco and Tovar, 2007). From the perspective of software system, a stakeholder is described as an individual, team or organization that is interested in or has concerns about the system (Kulkarni, 2008). The stakeholder theory offers a basis for the identification, classification and categorization of stakeholders and the understanding of their behaviour. ...
Requirements elicitation is the most critical phase in software requirements engineering. The process is resource intensive, as it concerns with a lot of dedicated stakeholders gathering purposefully to present and stipulate software requirements. The extent of effectiveness of the process is greatly influenced by the suitability of the stakeholders in the process of gathering the requirements. Previous studies indicate that improper stakeholder selection normally lead to unsuccessful requirements elicitation process. Such phenomena would later cause serious impacts to projects such as costly rework, overrun schedule and poor quality software. This study addresses this issue by proposing a model for selecting the suitable stakeholders during requirements elicitation process. The study adopts both the quantitative data collection and analysis. The data gathering was done through survey questionnaire among 300 project managers and analysts. The study employs the Structural Equation Modelling (SEM) to analyse the quantitative data. The results indicate that selecting stakeholders with appropriate characteristics such as stakeholders role, knowledge and communication skills have significant effects on the requirements elicitation phase. The results also reveal that requirements elicitation phase has significant influence on requirements quality. This model is useful for project managers to decide on appropriate stakeholders who are going to be chosen based on their characteristics during requirements elicitation phase.
... In order to assign values to service elements, one needs the specification of values relevant for each layer. Important for the business layer is what the stakeholders want (Kulkarni, 2008). When the stakeholder interest is identified, a set of strategic goals can be derived (Sikdar & Das, 2009). ...
Full-text available
This article defines a service as an architecture of processes, software and infrastructure elements for serving people. An architecture language therefore is a means to structure and analyze the values of service elements and the service as a whole. We provide a value-based perspective, which first includes a review of the concept of value in the context of service architectures for services. Here we conclude that multiple, even competing, values are at stake for different parts of a service. Second, the paper discusses a method for the valuation of a service using competing value constructs. We also demonstrate by a case how a formal architecture language can be used to calculate service values. Finally, the results are discussed and suggestions for further research are given.
... Analogously, concept of stakeholder benefit expectation can be used to describe the value that is provided by a required property. Kulkarni (2008) proposed a model concentrating on stakeholder concern perspective which highlights the following: ...
... Face-to-Face conversation used to elicit user's tacit knowledge and to illustrate software developer's knowledge is an iterative negotiation process (Ping et al., 2009). An expert to take requirement needs to solve the conflicts arise between two intersecting requirements (Kulkarni, 2008). The Goal-Based Requirements Analysis Method uses goal topography to structure and organize such requirements information as scenarios, goal obstacles, and constraints (Sajid et al., 2010). ...
... Stakeholder theory is an area of strategic management that defines a stakeholder as someone who affects or is affected by the actions of the organization [23], [24], [25], then the processes of the organization are reflected in the software process and these in turn, by the individuals according to Conway's law. Doer pattern allows clear identification of the key parts present when in the execution of the process, namely the doers of the software process and also the consumers along the process. ...
Full-text available
This article presents a set of patterns that can be found to perform best practices in software processes that are directly related to the problem of implementing the activities of the process, the roles involved, the knowledge generated and the inputs and outputs belonging to the process. In this work, a definition of the architecture is encouraged by using different recurrent configurations that strengthen the process and yield efficient results for the development of a software project. The patterns presented constitute a catalog, which serves as a vocabulary for communication among project participants [1], [2], and also can be implemented through software tools, thus facilitating patterns implementation [3]. Additionally, a tool that can be obtained under GPL (General Public license) is provided for this purpose.
Full-text available
[Context and Motivation] Before eliciting and gathering requirements for a software project, it is considered pivotal to know about concerned stakeholders. It becomes hard to elicit the actual system requirements without identifying relevant stakeholders, leading the software project to failure. Despite the paramount importance of stakeholder identification in requirement elicitation, it has been given less attention in the software engineering literature. [Method] For this purpose, we conducted a thorough Systematic Literature Review (SLR) on stakeholder identification (SI) and its methods in requirement elicitation. However, previously, a literature study on SI in the requirement elicitation was conducted. We found that no one has proposed any standard or baseline research method for stakeholder identification, stakeholder assessment, and stakeholder interaction up to date according to our knowledge. It provides an opportunity to update the current SLR on SI in requirements elicitation from 2011 till 2021 to search for a baseline methodology for the SI. For this purpose, we explored the existing literature research that involves the SI methods in requirements elicitation. [Principle Ideas/Results] Furthermore, we identify and capture seventeen research methodologies for SI, eight key stakeholders interaction methods, and ten stakeholders assessment methods in requirement elicitation. To further enhance the stakeholder identification process, we additionally identify pivotal information such as different potential stakeholder categories, stakeholder assessments methods, and stakeholder interaction methods. Also, based on the proposed SLR, we find out the existing gaps and new opportunities for SI methods in the requirement elicitation. [Contribution] These SI methodologies help requirements engineers and practitioners identify key stakeholders and efficiently improve the requirements quality. Moreover, this research study helps identify the effective practices used for the traditional and CrowdRE SI, recover consequences that can affect the effectiveness of SI, and recommend advisable SI practices to be employed in the future. This research study would help the software researchers and developers efficiently and accurately identify correct and concerned stakeholders to improve end-user satisfaction instead of considering it a self-evident task.
Full-text available
Clinical software is a fundamental tool for supporting healthcare systems because it improves the quality of patient care and automatizes the most frequently performed clinical tasks. Nevertheless, since health systems include various components, such as supplies, transportation, laboratories, and interoperability, eliciting the most critical requirements for understanding the problem that the clinical software must solve is quite a complex task. Indeed, the requirement elicitation process may directly determine the success or failure of the clinical software. In this article, we present the D&I framework, a methodology that uses dissemination and implementation strategies to recommend guidelines for the elicitation of clinical software requirements. The objective of this framework is to support software developers in the identification of key requirements with the goal of more holistically understanding the problem to be solved by the clinical software. We evaluated the D&I framework with a real case study related to a bed management system. We employed a usability instrument with 50 clinicians to evaluate tasks in software modules that represent clinical priorities defined by stakeholders. The results indicate that the perception of usability by end users is acceptable, suggesting that the evaluated tasks satisfy the established clinical priorities. The D&I framework provides a starting point for research and discussion about the contribution of dissemination and implementation strategies to the body of knowledge about requirement engineering.
Today, product development is a complex process: the designer continuously needs to consider new demands from different stakeholders and analyse how these demands can be fulfilled. Gathering and sharing stakeholder information is important, but is only beneficial if the information is used effectively. This is not a straightforward task. Information must be shared across design functions, and all involved need to develop a common understanding of the evolving design and the importance of particular stakeholders. This process relies to a large extent on the individual designer's intuition since there is lack of effective formal tools to support this. We argue in this paper the need for a holistic view, in order to manage all criteria, considering relevant perspectives and interests. To support this holistic view, we have developed a model that provides a common understanding for stakeholders involved, together with the requirements, functions and systems of the product being designed. This model will help facilitate the information sharing between members of extended design teams. Based on this, the model will support the decision-making process, and help the design team balance the interests of different stakeholders and the related functions. The model has been applied in an industrial case study.
A Study On Requirements Engineering: Understanding The Stakeholder's Desires And Needs MBA-Systems Students' Project, under the guidance of Mrs
  • Sulakshana Nirbhay