In order to develop software, the software's requirements must be known. One of the purposes of requirements engineering is to gather and validate these requirements. However, these steps are only possible in collaboration with the software's relevant stakeholders. As a result, the requirements engineering process typically starts with a stakeholder analysis, in other words, the identification of all relevant stakeholders and their relationships to one another.
The International Requirements Engineering Board (IREB) defines stakeholders in Requirements Engineering Fundamentals as "[...] a person or organization that has (direct or indirect) influence on the requirements of the system under consideration." The examples that meet this definition are typically always the same: end users, management, as well as legal entities and laws etc. However, software developers are often disregarded as stakeholders in the system. In the following, we provide some reasons as to why software developers should not only be recognized and regarded as requirements implementers, but also as stakeholders in the requirements process.
Technical background
Certainly the most obvious reason that the developer is a stakeholder is the fact that they have a direct influence on the software's properties and status. This includes, on the one hand, technical expertise, which limits the system's implementation at a technical level. Developers can only implement business requirements within the scope of their own technical capabilities. In addition to skills, this also includes the individual preferences of the respective developers with regard to programming languages, frameworks, libraries, etc. Furthermore, these developer decisions can have an influence on later requirements. As result, an early architecture decision can influence how, or even whether a later requirement can be implemented.
Below are two less obvious reasons for why developers should be considered stakeholders. Though, to be precise, I'm referring to meta-stakeholders instead of stakeholders. I use the term meta-stakeholder to refer to a person or organization that (directly or indirectly) influences or is affected by the requirements process. Consequently, in contrast to stakeholders, this is not about requirements with respect to the system, but about meta-requirements with respect to gathering and, in particular, documenting requirements for the system.
Degree of formality
Specifications often differ greatly in how technical they are. The spectrum ranges from concise and purely technical requirements formulated on post-its to page-long documents in formal languages. Sometimes so-called "pseudo code" is used, in other words, system instructions that are already programmatic but formulated in natural language rather than in a programming language.
How technical and how detailed a requirement should be formulated also depends on the respective developer, who will ultimately be the one working with the specification and implementing it. For example, inexperienced developers often need a more technical specification in order to implement it appropriately. Experienced developers, on the other hand, often insist that only the business requirements should be specified. They insist on having the task of implementing programming steps.
Technical background knowledge
Another reason for considering the developer when formulating the specification is the developer's technical background. For practical reasons, a specification can never be complete, especially when the software is being developed for technically complex processes. The amount of implicit assumptions and background information that must be taken into account is too large.
Some developers will already know this specific information, others will not. In this case, it is not so much a question of experience as a developer, but rather a question of how long the developer in question has been working in a particular industry or what specialist background they bring with them, such as that acquired through previous jobs.
If a developer is to create software based on a specification, the specification must contain (at least to a large extent) the information they need to do this. This means that the required level of technical detail can also depend on the respective developer.
This article has argued that software developers should be understood not only as implementers of a system's requirements, but as stakeholders as well. With differences in terms of both experience and technical and professional backgrounds, they also bring requirements to the system and the requirements process. For this reason, they should also be regarded as stakeholders.
Want to learn more about how our in|sure software can help your company meet the challenges of digitalization? Then please get in touch with our expert Karsten Schmitt, head of Business Development.
