By Pham Manh (tifam@edu.hse.ru)

As the field of software engineering evolves, the interaction and coordination of different participants are very critical. The people involved in the current project, called the stakeholders, contribute greatly to the success of software production by participating in its requirements engineering and management. Different types of stakeholders involved in requirements gathering include End-users, Customers, Project Managers, Developers, Regulatory Bodies [1].

The use of the word “stakeholder” dates back to the pioneering work done at the Stanford Research Institute in the 1960s. The initial definition of a stakeholder was unclear and thus controversial in the literature. The definition was so unstable that even Freeman, the “Father of the Stakeholder Concept,” modified it over time and came up with a more complex definition, in which stakeholders were considered to be broad in scope and were subsequently organized into four categories as depicted in Figure 1.[2]

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”. Software development projects cannot live without stakeholders. The stakeholders have various views, desires, and needs that will have an impact on the course of the project. During requirements engineering, learning about and implementing these views helps ensure that the end product meets the objectives of the stakeholders, thereby increasing the level of satisfaction of the intended users as well as the probability for success of the project. [2]

It is these stakeholder requirements that guide the process of software development. These requirements are stated as the functionalities, features or other limitations that if provided by the software will meet the acceptability standards by the stakeholders. They are able to gather and prioritize these needs. As such, development teams can deliver a product that not only meets but most of the time, surpasses expectations from the stakeholders. Hence, stakeholder requirements can be viewed as reporting the relationship between the vague needs of the stakeholders with what the software has to offer.

All stakeholders involved must stay engaged and manage input within the given timeframe in the best possible way. Requirements Engineering, in this case at hand, has procedures to achieve such an end goal. Some of them are:

* Interviews and Surveys - Interviews and Surveys are especially helpful in interacting with end-users and other stakeholders who are unable to attend the workshops. These techniques allow developers to focus on a certain instance usage, problem area as well as certain preferences. Such interviews aim at helping more understanding about requirements that the stakeholders probably do not know they have and wish to explore particular concerns.[3]

* Prototyping and User Testing - Such procedures allow stakeholders to manipulate and assess the early stages of the working product and provide feedback regarding its features, effectiveness and efficiency. This way of doing things makes it possible to ensure that every product remains satisfactory to the stakeholders and hence changes can be implemented in regard to the needs of the stakeholders. In this way, development teams can conduct ‘reasonably’ accurate testing of the requirements and identify the future problems as well.[3]

Stakeholder engagement, thus emphasizing on its importance for the success of requirements engineering, is, however, quite challenging. Typical barriers are:

• Identifying the Relevant Stakeholders - Finding the relevant stakeholders is among the initial challenges in stakeholder engagement. In complicated projects, it is not uncommon to miss out on important stakeholders, including regulators, support staffs, or potential users, who can be crucial in determining the success of the product. It is critical to fail to elicit all relevant stakeholders in order to avoid incomplete and possibly biased requirements.
• Coping with Opposite Agenda - Three important words: opposing stakeholders’ agendas. As stated above, several stakeholders have divergent interests. Solutions to resolve such conflicts can be offered in engaging stakeholders, however, this can add further complexity in the process of decision-making. Development teams have to make efforts in order to deal with conflicting priorities so that the end product is consistent with the organization’s business strategy along with providing a high level of satisfaction to the customers without jeopardizing the technical possibilities.
• Maintaining Engagement Throughout the Project - Engagement of the stakeholders is not a single event; rather, it is a multiplicity of activities which must be undertaken within a given time frame. However, sustaining the interest and the involvement of the stakeholders over a long period can be quite difficult, in particular when the stakeholders get bored because of delays or no apparent advancements. Development teams should establish appropriate tactics for the active participation of stakeholders in the process, such as progress reporting, completion of milestones and obtaining feedback.
• Managing Response to Shifting Requirements - With the passage of time and the increase of new knowledge about the product in question from stakeholders or the dynamics in the market conditions, it is quite certain that these requirements will change. How to manage changing requirements without bringing the development activity into the halt is one of the the key issues of concern in requirements engineering. Involving the stakeholders in the designs with iterative development models like Agile allows teams to cater for the changes whilst avoiding more disturbance to routine development processes.

When it comes to products, requirements engineering processes have been one of the most important areas in which stakeholders have to be involved. Engaging the stakeholders at the beginning and continuously throughout the development phase means that there will never be any ambiguities, gaps or discrepancies in requirements from business as well as user standpoint. Stakeholder engagement provides an opportunity to present opposing views, mediate, define issues and encourage participation which, in the end, ensures the delivery of a product that is beneficial to all the parties.

Although evident, effective involvement of all stakeholders extends beyond ad hoc wishes and free resources. There is a need for planning, applying the right strategies, and allowing two-way communication channels to be open. It is necessary for teams to undertake proper stakeholder analysis, reconciliation and participation management with respect to the duration of the project. There are risks engaged but the upside of engaging stakeholders is excellent and that’s why it is a necessary evil in today’s business requirement engineering.

1. The Crucial Role of Stakeholders in Requirements Engineering and Management https://www.linkedin.com/pulse/crucial-role-stakeholders-requirements-engineering-vikash-manoranjan-hnacf
2. Reviewing the Role of Stakeholders in Requirement Engineering: A Stakeholder’s Theory Perspective https://scialert.net/fulltext/?doi=ajsr.2020.1.8
3. Developing engineering systems with stakeholder engagement https://dspace.lib.cranfield.ac.uk/items/dbfaaa2d-5165-4edf-b577-4bafc3b150a6
4. A requirements engineering and management process in concept phase of complex systems https://ieeexplore.ieee.org/abstract/document/7753130
5. What role do stakeholders play in requirements engineering and management? https://www.linkedin.com/advice/3/what-role-do-stakeholders-play-requirements-engineering-1tsee#:~:text=Stakeholders%20in%20requirements%20engineering%20define,successful%20development%20and%20client%20satisfaction.