Stakeholders Defined

This post regarding stakeholders is again inspired by and contains excerpts from the book Software Systems Architecture: Working with Stakeholders using Viewpoints and Perspectives.

Software systems are not just used, they have to be built and tested, operated, repaired and of course paid for. Each of these activities involves a number of people, each with their own requirements and interests. The people are collectively referred to as stakeholders. Understanding the role of each stakeholder is fundamental to understanding the role of the architect in the development process.

The IEEE Standard 1471 on architecture description defines a stakeholder as a person, group, or entity with an interest of concern about the realization of a system's architecture.

I personally have a checklist I like to run through when a new project involving my development team is initiated. I like to make sure that all the necessary teams, such as support or infrastructure, are correctly engaged prior to implementation. From the perspective of a software architect, Nick Rozanski and Eoin Woods succinctly classify these stakeholders according to their roles and concerns as below.

 

Stakeholder	Role
Acquirers	Oversee the procurement of the system or product. In my experience, these stakeholders are often referred to as 'the business' and are usually the most important stakeholders, providing or authorizing funding. Their goals are usually value for money and efficient expenditure of resources during delivery and operation.
Assessors	Oversee the system's conformance to standards and legal regulation.
Communicators	Explain the system to other stakeholders via documentation and training materials. Analysts communicate the requirements to the developers whilst technical authors create manuals for the users and administrators.
Developers	Construct and deploy the system from specifications or lead the teams that do this.
Maintainers	Manage the evolution of the system once it is operational Their main concerns focus on documentation, instrumentation or change control. In my experience this is often the responsibility of the development team.
Suppliers	Build and supply the hardware and infrastructure on which the system will run.
Support	Provide support to users for the product or system when it is running.
System Administrators	Run the system once it is deployed. They focus on concerns such as monitoring, business continuity and disaster recovery and scalability.
Testers	Test the system to ensure that is suitable for use. Testers act as the conscience of the development team, systematically testing the system in order to establish whether it it is suitable for deployment and use. Unlike developers, testers do not have a sense of ownership of the implementation and with their specialist knowledge and experience means they can perform a more thorough and objective job of evaluating the system than other stakeholders.
Users	Define the system's functionality and ultimately make use of it.

Most development projects should include representatives from most if not all of these stakeholder groups though their importance varies from project to project. I totally agree with authors when they state that not considering a view from each class of stakeholder will lead to problems in the future.