Die Qualität und Vollständigkeit von Anforderungen hängen erheblich von den einbezogenen Anforderungsquellen ab. Eine relevante Quelle außer Acht zu lassen, führt zu einem unvollständigen Verständnis der Anforderungen oder zu unvollständigen Anforderungen. Die Identifizierung von Anforderungsquellen ist ein iterativer und rekursiver Prozess, der stets neu überdacht werden muss.
Ein gemeinsames Verständnis (Prinzip 3 in LE 2) über den Kontext des zu entwickelnden Systems ist eine Voraussetzung dafür, dass die relevanten Anforderungsquellen identifiziert werden können. Der Bereich zwischen der Systemgrenze und der Kontextgrenze wird als (System-) Kontext bezeichnet (Prinzip 4in LE 2). Der (System-)Kontext wird benötigt, um die Art der zu entwickelnden Anforderungen zu verstehen und so die ursprünglichen Quellen für Anforderungen zu identifizieren.
Anforderungsquellen werden in drei Typen klassifiziert:
Stakeholder
Dokumente
Systeme
Die Stakeholder eines Systems (Definition siehe [Glin2020], siehe auch Prinzip 2 in LE 2) sind die Hauptquelle für Anforderungen. Zu den Stakeholdern eines Systems gehören [BiSp2003]:
Benutzer
Sponsoren
Entwickler
Behörden
Kunden
Die systematische Identifizierung von Stakeholdern sollte zu Beginn einer Entwicklung stattfinden, und die Ergebnisse sollten im Rahmen einer kontinuierlichen Aktivität verwaltet werden.
Bei allen Systemen mit einer Benutzerschnittstelle stellen die Endbenutzer des Systems eine Stakeholder-Gruppe dar, die für den Requirements Engineer von besonderem Interesse ist. Bei großen Zahlen sollten die Benutzer in Benutzergruppen zusammengefasst werden, um den Ermittlungsprozess zu erleichtern. Ein praktischer Weg, größere Benutzergruppen zu beschreiben, ist die Verwendung von Personas [Coop2004].
Potenzielle Quellen für die Identifizierung relevanter Stakeholder sind:
Checklisten mit typischen Stakeholder-Gruppen und -Rollen
Organisationsstrukturen
Geschäftsprozessdokumentation
Marktberichte
Anfängliche Stakeholder zur Identifizierung zusätzlicher Stakeholder
Stakeholder sollten in einer aktuellen Stakeholderliste mit (mindestens) den folgenden Informationen dokumentiert werden:
Name
Funktion (Rolle)
Zusätzliche persönliche und Kontaktdaten
Zeitliche und räumliche Verfügbarkeit während der Projektlaufzeit
Relevanz
Fachgebiet und Umfang an Fachwissen
Ziele und Interessen bezogen auf das Projekt
Quelle: Basiswissen Requirements Engineering 3.0
Schwierigkeiten mit Stakeholdern entstehen meist dann, wenn die Rechte und Pflichten eines Stakeholders unklar sind oder wenn die Bedürfnisse des Stakeholders unzureichend beachtet werden. Stakeholder-Relationship-Management [Bour2009] ist ein effektiver Weg, um Schwierigkeiten mit Stakeholdern entgegen zu wirken.
In den meisten Systemkontexten stehen weitere Quellen. Diese müssen für ein erfolgreiches neues System ebenfalls in Betracht gezogen werden, da die meisten Stakeholder nicht über das Offensichtliche sprechen: ihre „unterbewussten“ Anforderungen (LE 4.2).
Zusätzliche Quellen für Anforderungen sind unter anderem:
Bestehende und Altsysteme
Prozessdokumente
Rechtliche oder regulatorische Dokumente
Unternehmensspezifische Vorschriften
(Marketing-)Informationen über potenzielle zukünftige Benutzer
Eine weitere Anforderungsquelle kann durch die Betrachtung ähnlicher Situationen in völlig anderen Bereichen gefunden werden.