Stakeholder Analysis Example for Software Projects

Many people search for a "stakeholder analysis example" when they want more than just a definition. They want a concrete sense of what a stakeholder analysis looks like in a software project and how it should sensibly fit into a requirements specification. That is exactly what this article is for: it gives specialist departments and project leads who are writing a requirements specification for the first time practical guidance they can use straight away for tenders and internal alignment.

Stakeholders are all the people or groups affected by the planned software, who contribute requirements, make decisions or will later work with the finished solution. The focus here is not on methodology theory, but on a practical working basis for software projects that are being planned from scratch, replaced or extended. We are not repeating the full structure of a requirements specification here; instead, where appropriate, we refer you to this requirements specification template.

Why a requirements specification is worthwhile before requesting quotes

A requirements specification creates a shared basis before you approach several providers. Objectives, constraints and expectations are set out in writing. That makes quotes easier to compare, because not every provider is interpreting the same task differently. This clarity saves a great deal of back-and-forth, especially if you want to introduce new software, replace an existing solution, expand a current application or add interfaces.

An early stakeholder analysis is particularly helpful here. It makes visible where management, specialist departments and IT have different expectations. Differences like these are normal. If they are identified early, they can be clarified before you request quotes, instead of leading to changes or misunderstandings later in the project.

Another important point: a requirements specification does not have to be a technical blueprint. It describes the business perspective:

• what is needed
• why it is needed
• how fulfilment will be recognised

This includes not only the desired functions, but also processes, roles, data sources and dependencies on existing systems. Only then does it become clear how the future solution will fit into your day-to-day work.

If you are looking for the full structure, this requirements specification template will help. For the next step after writing it, the article on choosing a provider is also useful.

Step by step: objectives, stakeholders, processes and requirements

Do not start with functions; start with the objectives. First, note down what is to be achieved from a business perspective, what should improve in operations and what specific problems exist today. Typical examples are breaks between Excel, email and specialist systems, duplicate data entry, a lack of transparency about processing status or unclear responsibilities. These are exactly the points that belong in the requirements specification, because later they explain why certain requirements matter. If you are looking for a complete outline for this, it is also worth looking at this requirements specification example as a guide.

The first actual working step is then the stakeholder analysis. Gather all the groups involved and note down three things for each group:

• what connection it has to the future software
• what interests and expectations it brings
• what possible reservations or risks are visible

A concise stakeholder analysis example for a software project might look like this: for a municipal web platform used to manage a sewer network, the building authority is often the business driver. Administrative staff use the application every day and need straightforward data capture and maintenance. External service providers supply condition data or documentation. IT focuses on operations, access and integration into existing systems. Management expects reports as a basis for planning and decision-making. Similar constellations can also be found in other software projects and areas of application.

From this overview, you derive the roles in the requirements specification. This is not about job titles, but about tasks within the process: who records data? Who checks it? Who approves measures? Who needs reports? Who manages users and permissions? Only when these roles are clearly separated can requirements be formulated precisely.

The next step is to describe the current process. This does not need to be a long block of text. Often, a few steps are enough: where does information arise, how is it passed on, where is it transferred manually, and at which points do questions or delays occur? The important thing is to locate problems within the process instead of immediately ordering functions. That makes it clearer what solution is actually needed and which wishes merely describe symptoms.

Only then should you formulate functional requirements as short, clear value statements. The term user story refers here to a brief description from the perspective of a role, together with the desired outcome. Examples include:

• recording conditions
• planning measures
• assigning documents to cases
• mapping approvals
• exporting reports
• tracking deadlines

If these requirements are later to become an implementation plan, the functional specification example shows how the next step develops from them. For an initial assessment, you can also estimate your project roughly with the cost calculator or have it structured via a project check.

Who should be involved and how to organise the process

Creating a requirements specification typically involves several perspectives. The client or management sets objectives and priorities. Specialist departments describe processes, problems and day-to-day requirements. IT adds which systems already exist, which data sources need to be taken into account and what constraints apply to operations and access.

For public-sector clients or agencies, there are often additional stakeholders involved, such as procurement or project leads. They help ensure that the documents remain complete, understandable and well structured. If you are still unsure before making an enquiry what should go into the documents, the article on the structure of the enquiry will help.

It is sensible to appoint one person as the responsible editor. They standardise terminology, avoid duplication and collect open questions in one place.

In practice, the process often works like this:

• gather requirements in short workshops or interviews
• bring the results together centrally
• have the drafts reviewed by those involved
• mark differences openly and prioritise them

Different interests are not a problem; they are normal. That is exactly what the stakeholder analysis is for: it makes differing expectations visible and translates them into prioritised requirements.

This early alignment also makes it easier to compare quotes later, because fewer fundamental questions remain unresolved. If you then want to choose the right provider, the next article to read is the one on selection.

Requirements specification and functional specification: who writes what?

The requirements specification describes, from the client's perspective, what is to be achieved. The functional specification describes, from the contractor's perspective, how those requirements can be implemented. This distinction is important when requesting quotes: providers can only respond reliably if the business expectations are described clearly, completely and in a way that can be followed.

For that reason, a requirements specification should generally not include technical decisions, architecture or specific implementation proposals, unless these are explicitly defined as constraints. At this stage, the focus is on objectives, benefits, roles, processes and requirements.

Questions from a provider are not a sign of a poor requirements specification. They often serve to sharpen terminology, make dependencies visible or clarify priorities.

The next step can then be an implementation plan describing the solution approach, dependencies and quality assurance. What that looks like is shown in the article on the functional specification as the next step.