Stakeholders, Users, and Outside Systems

A stakeholder is a person or group that can affect the system or is affected by it. A user is a person who uses the system. Every user is a stakeholder: using the system is one way a person’s interests are tied to it. Not every stakeholder is a user, though. Some stakeholders never sign in but still care about the outcome.

Stakeholders tell us whose interests we must consider. Users tell us, more specifically, who will operate the software. Asking “who is a stakeholder” gets us the full list of people to talk to. Asking “who is a user” narrows that list to the people whose hands will actually be on HopPress.

An editor is a user: they sign in and interact with HopPress while reviewing posts, and are affected by how well it supports that work. An editor-in-chief who sets publication policy, by contrast, may be a stakeholder without ever using HopPress: they care about the outcome without operating the software.

We describe people as roles rather than names. “Author” identifies a set of goals and allowed actions. The same person might act as an author while writing a post and as an editor while reviewing someone else’s work.

Roles around HopPress

HopPress has four human user roles in this initial design.

A reader wants to find and open published posts. A reader does not need access to drafts or editorial controls.

An author (perhaps a communications staff member in a school or department) wants to sign in, create and edit their own drafts, submit a draft for review, and see whether it was published or returned. The words “their own” matter because an author should not automatically be able to edit another author’s work.

An editor (perhaps a communications editor in the central office) wants to find submitted posts, review them, publish them, or return them for revision. Authors prepare the content, while editors decide what becomes public.

An administrator assigns author, editor, and administrator roles. The administrator decides which actions a person is allowed to perform. This is different from editing or publishing posts.

The university communications director and leaders of participating schools are also stakeholders. They may care about cost, publication policy, reputation, or legal obligations even if they rarely sign in. Their concerns can impose requirements on HopPress. For example, a publication policy may require editorial approval before a post becomes public, and a legal obligation may require HopPress to retain a record of that decision.

Outside systems HopPress depends on

Stakeholders are people. But HopPress also exchanges information with systems that are neither: they have no interest in the outcome, and no one signs in to them. A university may already provide shared services such as an identity provider and email delivery. Those services may belong to the university’s broader IT environment, but they are external to HopPress because HopPress uses them rather than implementing them itself.

When someone signs in, HopPress directs the person to the university’s identity provider (IdP). The IdP handles sign-in and tells HopPress which university account was authenticated. HopPress uses that identity and its own role assignments to decide what the person may do.

If HopPress sends notifications, it may use a university email service in the same way. HopPress would ask the email service to deliver a message after an editor publishes or returns a post, even though both systems may be operated by the same university.

Naming an outside system raises questions that we may need to answer later. What information does HopPress send? What answer does it expect? What should happen if the outside system refuses the request or cannot answer? We do not need to design every failure now, but we should not forget that the interaction exists.

Where requirements come from

Identifying the stakeholders and users tells us whom to involve. We gather requirements by talking with those stakeholders and learning what they need, what causes them trouble, and what a successful result looks like.

Interviews are one way to do this. They help us learn people’s goals, terminology, pain points, and disagreements. We can observe communications staff using the current publishing tools, review editorial calendars and spreadsheets that track drafts, read publication policies and content guidelines, and examine support requests about the current process. We can also look at the workarounds staff have created when the existing tools do not support their work. These sources can reveal publishing rules and practical needs that people may not state directly.

For the publishing workflow, I would ask an author to show me how they create, edit, save, and submit a draft, what information they need while doing that work, and how they learn what happens next. I would ask an editor how they find submitted drafts, what information they need to review them, how they record a decision, and what happens after they publish or return a draft. I would ask an administrator how roles are assigned and changed. I would also inspect the current role policy and several posts in different states.

That work of finding, clarifying, and understanding requirements is called requirement elicitation.