Abstract: The involvement of stakeholders in requirement engineering (RE) varies widely and it is majorly a function of the requirement activities involved. The role of Stakeholders’ is considered very important in RE but literatures hardly discuss in details how the two entities relate to each other. Hence, the requirement engineers are finding it difficult to balance the interests of various stakeholders towards creating a sustainable and ethical value. Aiming at improving on how to work with stakeholders in RE, this study carried out a systematic literature review of 104 RE articles as related to stakeholders’ theory and employed open coding to categorize various requirement traditions resulting into identification of four major activities - elicitation, communication, validation and modeling. Outlining various approaches in relation to stakeholders, this study guides professionals in taking explicit decisions regarding stakeholder’s role in software requirement. Three essential topics in stakeholder theory that can improve studies in software requirements when stakeholders are involved are discussed and recommendations on the choice of stakeholders in software requirements from the stakeholder theory perspective are offered.
INTRODUCTION
Stakeholder’s involvement in business processes is important since business is not only abut profits but also about improving the state of the world and driving stakeholders values1. Hence, many authors in the field of software development and decision-making have clearly highlighted the role of stakeholders and their significance2. However, since the quality of any software also depends on the level of stakeholders cooperation3,4, it becomes more important for large enterprises to balance the interests of various stakeholders in RE. Therefore, organizations do group stakeholders purposely to manage the stakeholder’s interests, needs and viewpoints5.
This study aimed at reviewing various options (implicit or explicit) available to requirement engineers (RE) when dealing with stakeholders. The stakeholders theory is employed because the theory’s perspective comprises of an expansive collection of learning that delineates several ways of dealing with stakeholders6. It is about the firm knowing what to do and how to achieve the set goal7. Subsequently, the authors carried out a systematic review of RE studies and discover three different traditions that in togetherness, determine ways of relating with stakeholders in RE.
STAKEHOLDER THEORY VS. SOFTWARE REQUIREMENT
Following its unique suggestion by authors, stakeholder theory experienced quick development in the 1990s with a considerable measure of research progressing and its reception by analysts in the hierarchical field8. Freeman and Reed9 was credited by Sadiq and Jain5, Noma-Osaghae et al.7 and Okesola et al.8 with the way he advanced stakeholder theory in the context of strategic administration. They argued that business organizations should take stakeholders interests as an important criteria when taking strategic decisions.
The use of the word “stakeholder” originated from the spearheading work done at Stanford Research Institute8,10 in the 1960s. The term is an extreme one, it implies distinctive things to various individuals and attracts hatred from a wide assortment of researchers and professionals6. The definition of a stakeholder, the purpose, the character of the organization and the role of managers are very unclear and thereby contested in literature. The definition has been unstable to the extent that even Freeman the “Father of the stakeholder concept”9 changed this definition over time and gave a sophisticated definition where stakeholders are considered to be of a wide range and are subsequently organizes into four categories11 as depicted in Fig. 1.
| Fig. 1: | Category of stakeholders |
However the original purpose of the term was to define other people, groups and organizations. Hence, stakeholders are “those groups who are vital to the survival and success of the corporation”6.
There is a close connection and exchange of ideas between stakeholder theorists and software requirement8. The theorist analyze the enterprise as a gathering of inner and outside such as investors, workers, clients, providers, lenders and neighboring groups10. Whereas, stakeholder theory focuses on the technical rather than the theoretical thereby failing to respond to the needs of the theorist12. Hence, descriptive stakeholder theory is particularly concerned about how managers and stakeholders actually behave and view their actions and roles.
Meanwhile, stakeholder theory was originally developed to resolve several issues including the problem of ethics and capitalism, managerial mind set and more importantly, problem of value creation9. The theory submits that human beings are complex and matters get complicated when stakeholder relationships are involved. Interactions between various stakeholders in software requirement is therefore major and should be encouraged5,10,12.
Major issues in stakeholder theory: One of the focal issues in the advancement of stakeholder theory has been the confusion behind its tendency, purpose and reason13. In this segment, this study takes a glimpse at significant issues in stakeholder hypothesis since the issues will advise on how Software Requirement studies differ in the simultaneous consideration of multiple stakeholders9. Going by the advancement in stakeholder theory, this study identified three of such issues as instrumental stakeholder theory, normative stakeholder theory and descriptive/empirical stakeholder theory14, upon which stakeholder theory genre may generally be described. These issues become the three distinctive approaches of accessing stakeholders and a good starting point when reviewing stakeholder’s roles in software requirements15.
Instrumental stakeholder theory: A vital issue that secludes stakeholder theory is the issue why partners are viewed as critical15. Instrumental stakeholder theory is the one that pays attention to stakeholders by considering the interest of multiple stakeholders as well as the expected returns from the organization16. The hypothesis, in conjunction with accessible descriptive/empirical information is used to identify the connections between stakeholder administration and the accomplishment of customary corporate targets13. It is justified by Freeman10 on a normative grounds for its specific ability to satisfy the moral rights of individuals.
Moral stakeholder theory is particular about stakeholders “not because this would serve the organization that takes them into account but because it is regarded as ‘the right thing to do”5,9,11,12,17,18. If software requirement are equally seen from this viewpoint, then the articles may have unequivocal inspiration why stakeholders are considered mandatory since adopting instrumental stakeholder theory has considerable implication on decision making. Notwithstanding, some studies19-21 from the software requirements perspective argued that there is no motivation for stakeholders to be considered as so important in decision making.
Normative stakeholder theory: Normative stakeholder theory deals with managers or stakeholders and how they behave towards the rest of stakeholders within the group. The theory comes with so many underlying problems21 as focusing and making trade-offs alongside focusing on avoiding trade-offs are major divisions in stakeholder theory. This is because focusing poses questions to stakeholders to answer while trade-offs even discourages the act22.
Software requirement articles rarely explain their focus on supporting a trade-off between the interests of various stakeholders or opting for new solutions where the interest of the stakeholders is aligned, thereby preventing the stance of trade-offs15. Avoiding exchange offs has significant ramifications such as picking the proper strategy, planning the procedure and picking the correct objective factors for basic leadership/decision making as well as significant influence on academic management20.
Descriptive/empirical stakeholder theory: Descriptive/ empirical analysis how firms behave towards stakeholders13. Several studies6,8,18,23 on stakeholder theory have identified a wide gap between what focal organizations recognizes as their stakeholders’ interest and what the stakeholders themselves analyzed as their interest. However, it is important to identify the right interest when implementing decisions to avoid unforeseen circumstances where user requirements keep changing even when system development has started3,24.
Descriptive model of software projects is concerned about how a project reacts to circumstances and conforms to the needs of the stakeholder. Although the model is primarily aimed at eliminating any form of errors in software requirement25, it can serve several purposes including process improvement and RE relationship training in both education and engineering sector22.
This study systematically reviewed all articles that specifically mentioned “requirement engineering” AND “stakeholder” in order to expose various areas where RE relates with stakeholders. The following broad indexes and digital libraries were auto-searched: IEEE computer society digital library, Citeseer, ACM, Springer Link, EBSCO, Web of Science, Science Direct and Scopus. However, searches in this study is confined to Scopus and Science direct since from the preliminary search results, all studies found in other databases were also indexed in Scopus when the following complex search that resulted to 73 articles was applied:
| • | (TITLE ("requirement engineering" AND "stakeholder”) OR KEY ("requirement engineering" AND "stakeholder”) AND ABS ("requirement engineering" AND "stakeholder")) AND (LIMIT-TO ( SUBJAREA , "COMP”) OR LIMIT-TO ( SUBJAREA, "ENGI”)) and (LIMIT-TO (LANGUAGE, "English")) AND (EXCLUDE ( SUBJAREA, "MATH”) OR EXCLUDE (SUBJAREA, "BUSI”) OR EXCLUDE (SUBJAREA, "DECI”) OR EXCLUDE (SUBJAREA, "SOCI") OR EXCLUDE (SUBJAREA , "ECON") OR EXCLUDE (SUBJAREA, "ENVI") OR EXCLUDE (SUBJAREA, "MATE") OR EXCLUDE (SUBJAREA, "MEDI")) |
Study selection: The complex search already ensures that the keywords, titles and abstracts of the articles considered for this exercise contain the study search strings-“requirement engineering” and “stakeholder”. A two-man team of researchers was formed to review these selected 73 articles for possible exclusion considering the following criteria:
| • | Paper is not a full flesh research submission |
| • | Topics are not particularly related to RE but more of Information systems or computer sciences |
| • | Article is silent on the subject matter and does not address a specific requirement activity |
On validation by another two-man team where discrepancies were discussed and agreed, this process excluded seven articles most of which are just abstract extensions or mere PowerPoint presentations. However, when studies that are not descriptive or those that fail to discussed hypothetical application of RE activities such as literature reviews were excluded, only 104 articles remained and subsequently subjected to data extraction process.
Data extraction process: Data extraction was independently performed on the selected 104 articles by each research team and their notes were compared with each other towards discussing and addressing the noted discrepancies. The following information were extracted from each of the articles:
| • | The core requirement activities addressed which are categorized as Elicitation, Modeling, Communication or Validation |
| • | The study type which could be quantitative, qualitative or mix (ture) of both. A paper is said to be mix when it employed both in-depth interviews to identify likely solutions and their assessment criteria and closed questionnaires to score them |
| • | Whether the researcher centered the study on his own knowledge alone (expert-based), embraced the stakeholders participation (participative) for instance in identifying the goals and alternative solutions |
| • | The goal of the study which is ether conceptual, empirical or mixed. While empirical studies use real data for illustration, conceptual papers only give a general description of a method or procedure without necessarily apply it to a real world case |
| • | The specific, generic or mixed results obtained from the study. Generic results is focused on further research or extension of models whereas, specific results only describe actions of a particular case. Mixed studies present both generic recommendations and general advice to the managers22 |
The specific stakeholder theory the study referred to.
Software requirements activities as related to stakeholders’ capabilities: As much as the relevance of stakeholders in software requirement cannot be over emphasized, the extent of their importance always remains implicit24. Hence, the following questions often arise22:
| • | Q1: Are stakeholders important because they are information providers? If yes, which kind? |
| • | Q2: Are they important because of their role in software implementation? |
| • | Q3: Is information gathering possible when stakeholders are directly involved in software requirement? |
The RE activities are numerous. Notwithstanding, the analysis here captures how the above questions are addressed by articles in various subfields. Following grounded theory as postulated by Glaser and Strauss26 and bearing in mind that stakeholders are involved in every RE activity, open coding was used to categorize various activities and identified four major activities as follows.
Elicitation: The largest tradition where stakeholders relate with RE is elicitation and it is the first stage of RE process27. Elicitation is also referred to as requirement capturing and its approach could be direct or indirect. It remains the process used to understand problems and its application domain as well as determining problems and needs of users in constructing systems that resolves the problems and addresses customers’ needs.
As illustrated on Table 1, majority of papers here have a general goal and did not apply any specific method to the real world. About16 of 40 papers in this tradition are conceptual contributors and made no reference to empirical data while 12 articles are mixed and the other 12 are mere empirical contributors. Similarly, most papers in elicitation tradition are qualitative as only 8 are quantitative and 13 are both since they mostly engaged both interviews and questionnaire as research tools.
Applications in this tradition are more of participatory than expert but in ratio 5:3, respectively. Although the researchers developed the solutions on their own, they do inquire from the stakeholders about the problems at hand for better understanding. These participatory applications consider stakeholders as a major interest group on the outcome of the model or sources of uncertainties that presents a major challenge for the method to address. A large number of the papers either described the implementation procedure, result processing or potential impacts of the proposed action. However, 14 papers offered mixed recommendations and only 5 are specific.
Modeling: Modeling is the construction of abstract descriptions that are amenable to interpretation and therefore; considered fundamental to RE28. It is another way where software requirement relates with stakeholders as the activities are used to represent a whole range of products in the RE process29.
| Table 1: | Characterized requirement activities | |||||
| Requirement activity | No. |
Goal | Expert/Participatory | Study type | Result | Ref to theory |
| Elicitation | 40 |
16 conceptual, 12 mix, 12 empirical | 15 expert, 25 participatory | 8 quantitative, 13 mix,19 qualitative | 21 generic 14 mix, 5 specific | 3 |
| Communication | 19 |
6 conceptual, 5 mix, 8 empirical | 6 expert, 13 participatory | 3 quantitative, 7 mix, 9 qualitative | 10 generic 6 mix,3 specific | 6 |
| Validation | 37 |
12 conceptual, 14 mix, 11 empirical | 12 expert, 25 participatory | 7 quantitative, 10 mix, 20 qualitative | 19 generic 17 mix,1 specific | 2 |
| Modeling | 8 |
3 conceptual, 3 mix, 2 empirical | 2 expert, 06 participatory | 2 quantitative, 3 mix,3 qualitative | 3 generic 5 mix, 0 specific | 1 |
| Total | 104 |
37 conceptual, 34 mix, 33 empirical | 35 expert, 69 participatory | 20 quantitative, 33 mix, 51 qualitative | 53 generic 42 mix, 9 specific | 9 |
Studies on modeling focus on quantitative, qualitative and or both aspects of the problems with almost same number (2, 3 or 3, respectively) as depicted on Table 1. This is because applications in this practice are majorly from the fields such as banking, RE and e-communication where much data are available to relate with. Similarly, 3 of the 8 papers started with empirical data and another three are conceptual contributions while the remaining two made use of data to test their models or algorithms. Only one quarters of the papers on modeling are expert based since three quarters consider stakeholders as a criteria to assess alternative solutions. Conclusively, none of the papers offer specific solution as 5 of the 8 are mixed and only three offer generic advice for practice.
Communication: The RE is not only about discovering and specifying requirements but also a process of facilitating effective communication of requirements among different stakeholders. Hence, communication is a crucial RE process that deals with ways different stakeholder’s viewpoint are being communicated in relation to their needs30.
Most studies in requirement communication are qualitative and participatory as only three of 19 papers exclusively use quantitative data and 6 are participative. However, some of these papers made use of generic framework, illustrated or tested with artificial data. Still on Table 1, 6 are conceptual contributors focusing on the method and make no specific reference to empirical data. Another five used test data to assess proposed methods or models aiming at adapting or extending already existing methods for novelty. The remaining 8 started from empirical data, with some describing the extent to which results were implemented and the others giving good accounts on improvements in the problem that prompted the research.
Again, just a few publications in this requirement activity provide some details on processes involved in problem formulation, approaches to stakeholder’s involvement and recommendation generated. Over 50% gave generic recommendations and only 6, representing approximately 30% offer mixed advice.
Validation: This is another important way where software requirement/RE relates with stakeholders. Validation is an act of looking for completeness and level of feasibility of a particular product or service to ascertain the correct stakeholder’s requirements are met26. Table 1 suggested that over two-third of the studies on validation were conducted in participative mode as only 12 out of 37 assume that not all needed knowledge is available. They majorly assume that the researchers have good knowledge of the problem sufficient enough to translate it into mathematical relations of alternatives.
About 12 papers on validation are conceptual in goal while 11 started from the empirical data. Fourteen are mixed of both conceptual and empirical as they test approaches against real data. Hence only one study presents specific solutions, 19 outline results for generic cases on the chosen models/methods and 17 are mixtures of both. Twenty of them use qualitative data exclusively and other 10 focus on quantitative data analysis. Only 7 made use of the two for solution identification and result assessment. Ten studies here gave explicit description of how clients were involved and recommendations implemented. There are other 10 studies, though gave an in-depth evaluation report of an implemented case, they are silent on implementation. These 25 of 37 articles on validation all follow intensive participative processes as stakeholders are actively involved in the identification of research goal.
The role of stakeholders in software requirements can affect organization’s objectives, actions or policies and stakeholders can have different responsibilities and considerations within such organization. This trend is reflected in the management literature, where much advancement has been made in what is known as stakeholders’ theory. Systematic literature review in this study recognizes elicitation, communication, validation and modeling as the major requirement activities amongst others. The progressions of these activities over time are as illustrated in Fig. 2 with elicitation being the largest (going by the total number of articles).
The selection of requirement elicitation techniques is based on the company practice or personal experience and the process is targeted at gaining knowledge about user's needs31. However, Requirements elicitation and documentation are complex activities and therefore difficult to manage, it is not only the requirements themselves but also the people involved32. Hence, management of stakeholders is a main obstacle encountered when eliciting stakeholders needs5,27.
Requirements traceability ensures continuous alignment between stakeholder requirements and various outputs of system development process33. However, modeling provides unique opportunities to precisely capture stakeholder requirements and analyze the outcome of the prototype towards improving the quality of software production26. While documentation enhances requirement readability, analysis and validation5,34, requirement communication enhances discussions between the client stakeholder and the requirement engineers particularly at the validation stage. Validation is a confirmation that a product, service or framework addresses the issues of the stakeholders but its success is measured by the ability of stakeholders to understand the information presented33.
| Fig. 2: | Progression of requirement activities |
CONCLUSION AND RECOMMENDATION
This study analyzed major roles played by stakeholders in RE as related to stakeholders’ theory and presents the progression of requirement activities over time where elicitation is consistently positioned highest. Having identified the core requirement activities where stakeholders are related, this study discovered that majority of researches on RE are done in a participative mode and cover a range of topic, they consider stakeholders views in identifying the project goals and where necessary offer alternative solutions to achieving them. Hence, this study gives a better understanding of the stakeholder theory concept and makes readers more sensitive about the role of stakeholders in software requirement and how this role could change management practice. The study will raise knowledge awareness amongst requirement engineers as for instance, professionals aiming at involving stakeholders in elicitation and validation will have to learn how to capture qualitative data.
However, literatures hardly consider the implication of stakeholder’s involvement and are mostly silent on how stakeholders are being selected. Since stakeholders involvement may be unnecessary where identification of their goals and views are straightforward, the authors agree with other scholars that future studies on RE should be more on the choice of stakeholder’s and the associated implications.