Stakeholder Identification in the Requirements Engineering Process

Adequate, timely and effective consultation of relevant stakeholders is of paramount importance in the requirements engineering process. However, the thorny issue of making sure that all relevant stakeholders are consulted has received less attention than other areas which depend on it, such as scenario-based requirements, involving users in development, negotiating between different viewpoints and so on. The literature suggests examples of stakeholders, and categories of stakeholder, but does not provide help in identifying stakeholders for a specific system. In this paper, we discuss current work in stakeholder identification, propose an approach to identifying relevant stakeholders for a specific system, and propose future directions for the work. 1. What is a ÔstakeholderÕ? There is a large body of literature in the strategic management area which discusses organisations in terms of a stakeholder model. Stakeholder analysis, it is claimed, can be used to analyse an organisationÕs performance and determine its future strategic direction. An oft-quoted definition of ÔstakeholderÕ, taken from a key reference in this literature is: ÔA stakeholder in an organisation is (by definition) any group or individual who can affect or is affected by the achievement of the organisationÕs objectives.Õ [10] A much broader definition, which has also been attributed to Freeman, is that a stakeholder is Ôanything influencing or influenced byÕ the firm, but it has been claimed that this definition is problematic because it leads to the identification of a very broad set of stakeholders. It is important to distinguish between influencers and stakeholders because while some potential stakeholders may indeed be both stakeholders and influencers, some who have a real stake in an enterprise may have no influence, e.g. a job applicant, while some influencers may have no stake, e.g. the media [8]. Information systems (IS) researchers have also taken up the idea of stakeholders: ÔWe define stakeholders as these participants <in the development process> together with any other individuals, groups or organisations whose actions can influence or be influenced by the development and use of the system whether directly or indirectly.Õ [22] In software engineering, stakeholders have been defined as: ÔThe people and organisations affected by the applicationÕ [3] ÔSystem stakeholders are people or organisations who will be affected by the system and who have a direct or indirect influence on the system requirementsÕ [16] ÔStakeholders are people who have a stake or interest in the projectÕ [4] A more explicit refinement of this definition is: ÔÉ anyone whose jobs will be altered, who supplies or gains information from it, or whose power or influence within the organisation will increase or decrease.Õ [7] They go on to say that ÔIt will frequently be the case that the formal ÔclientÕ who orders the system falls very low on the list of those affected. Be very wary of changes which take power, influence or control from some stakeholders without returning something tangible in its place.Õ [7] When faced with the practical problem of how to identify the set of stakeholders relevant to a specific project, these definitions are not particularly helpful. The main concern is that, although such definitions are usually accompanied by example groups of stakeholders, they are vague and may lead to consideration of inappropriate or incomplete groups of stakeholders. Categories of stakeholder include end-users, managers and others involved in the organisational processes influenced by the system, engineers responsible for system development and maintenance, customers of the Sharp, Finkelstein & Galal 11/12/99 2 organisation who will use the system to provide a service, external bodies such as regulators, domain experts, and so on. They will each have different goals, and will try to satisfy their own without recourse to others [16]. Cotterell and Hughes [4] suggest that stakeholders might be in one of three categories: internal to the project team; external to the project team, but internal to the organisation; and external to both the project team and the organisation. Newman and Lamming [20] suggest a different division: into those who will use the system directly or indirectly, and those who will be involved in developing the system. This distinction is also taken up with respect to the development of knowledge-based systems [22]. The set of stakeholders in the knowledge acquisition process and the set of stakeholders in the use of a knowledge-based system, are not necessarily identical; they are likely to vary in membership, and for those members in common, the type and level of stake they have is likely to vary. The IS literature suggests a different division again, into ÔhubsÕ or ÔsponsorsÕ and ÔspokesÕ or ÔadaptorsÕ, where the former are those initiating and sustaining the system, while the latter are those participating [21]. Macaulay [19] identifies four categories of stakeholder in any computer system: 1. Those responsible for design and development; 2. Those with a financial interest, responsible for its sale or purchase; 3. Those responsible for introduction and maintenance; 4. Those who have an interest in its use. But again, she offers no guidelines for identifying specific stakeholders for a given system. So far, we have not distinguished between individuals or groups and roles. As with other situations, the mapping between stakeholders and individuals or groups is not oneto-one. It is therefore more appropriate to think of stakeholders as roles rather than as specific people. In subsequent discussion, we shall use ÔstakeholderÕ to mean Ôstakeholder roleÕ. 2. Identifying stakeholders There has been little focus on the participants of the requirements engineering (RE) process, for example in terms of how to trace participants in the RE process and how to identify stakeholders [13]. All of the references cited above emphasise the importance of identifying stakeholders, and although they provide examples, or broad guidance for identifying them, none describes a model or a concrete approach for identifying stakeholders for a specific project. This deficiency has been noted in the management literature, and in the IS literature [21], where the approaches have been criticised for either assuming that stakeholders are ÔobviousÕ, or for providing broad categories which are too generic to be of practical use. Expert identification for knowledge-based systems development has similarities with stakeholder identification in RE, although here too there has been an assumption that experts are readily identifiable [22]. Pouloudi and Whitley [21] suggest four principles of stakeholder identification, and describe an approach which is based on these principles, and which they used to identify stakeholders in the drug use management domain. Lyytinen and Hirschheim [17] also provides some guidance for stakeholder identification for IS, while acknowledging that Ôthe identification of the set of all stakeholders is far from trivialÕ. Methods for requirements engineering, e.g. KAOS [5], do not directly support stakeholder identification; it seems to be assumed that it is straightforward. The task of identifying actors for use case development [15] has similarities with stakeholder identification, but is targeted only at a fraction of system stakeholders. Stakeholders are related to each other and interact with each other [22,11,17]. Interactions between them include: exchanging information, products, or instructions, or providing supporting tasks. Information about the stakeholders and the nature of their relationships and interactions needs to be identified and recorded. Dimensions of importance are: relationships between stakeholders, the relationship of each stakeholder to the system, and the priority to be given to each stakeholderÕs view. This information is needed to manage, interpret, balance and process stakeholder input. Reconciling different stakeholder views is beyond this paper, but is considered in [12]. 3. An approach to identifying stakeholders for requirements engineering Here, we propose an approach to discovering all relevant stakeholders of a specific system that we believe is domain-independent, effective and pragmatic. We draw on the literature cited above, and on aspects of ethical decision-making in software systems [18]. Our starting point is a set of stakeholders that we refer to as ÔbaselineÕ stakeholders. From these, we can recognise ÔsupplierÕ stakeholders and ÔclientÕ stakeholders: the former provides information or supporting tasks to the baseline, and the latter processes or inspects the products of the baseline. Other stakeholders that we call ÔsatelliteÕs interact with the baseline in a variety of ways. ÔInteractionÕ may involve communicating, reading a set of rules or guidelines, searching for information and so on. Our approach focuses on interactions between stakeholders rather than relationships between the system and the stakeholder, Sharp, Finkelstein & Galal 11/12/99 3 because they are easier to follow. Figure 1 illustrates the main elements of stakeholder identification. Figure 1. The main elements of stakeholder identification addressed by our approach 3.1 Baseline stakeholders We have identified four groups of baseline stakeholder: users, developers, legislators and decision-makers. We have dubbed these ÔbaselineÕ because the web of stakeholders and their relationships can be identified from them. The nature of each group is explored below. 3.1.1 Users. The term ÔuserÕ has many interpretations. For example, Holtzblatt and Jones [14] include in their definition of ÔusersÕ those who manage direct users, those who receive products from the system, those who test the system, those who make the purchasing decision, and those who use competitive products. Eason [9] identifies three categories of user: primary, secondary and te