Funktionale und nicht-funktionale Anforderungen: SEO

Die funktionalen und nicht-funktionalen Anforderungen sind die Haupt- oder nicht-funktionalen
Funktionen, die ein Programm erfüllen muss, und sie dienen auch dazu, den Kunden über die
Funktionalitäten zu informieren, die das Programm erfüllen wird. Diese Funktionen sind hier im
SEO-System aufgeführt.
Funktionale Anforderungen
 Verbesserung der Positionierung gegenüber konkurrierenden Unternehmen
 Aktualisierung der Website
 Generierung von Website-Schlüsselwörtern
 Mögliche URLs generieren
 Analyse des technischen Inhalts der Website (Vorhandensein von Tags und JavaScript oder
Flash).
 Berechnung der Absprungrate zur Ermittlung der Website-Popularität
 Berechnung der Anzahl der Schlüsselwörter pro Seite

Nicht-funktionale Anforderungen
 Das System muss über eine benutzerfreundliche Schnittstelle (Interface) verfügen.
 Die Ziele des Unternehmens kennen
 Wartung der Website (Software)
 Analyse der Ladezeit der Hauptseiten (Performance)
 Verwendung einer Datenbank zur Unterstützung der eingegebenen Informationen (Software)

FUNKTIONSANFORDERUNGEN
Name Datenbank
Typ Anforderung
Priorität Hoch
Beschreibung Jedes Mal, wenn ein neues Konto erstellt wird, müssen die
Daten jedes Benutzers in der Datenbank (Sean in der
Speichereinheit des PCs oder Servers) gespeichert werden.
Eingang Vom Benutzer eingegebene Daten
Prozess Benutzerdaten speichern
Ausgänge Registrierung der Daten
Tabelle 1: Funktionale Anforderungen - Datenbank

Name Schnittstelle zur Datenerfassung

Typ Anforderung
 Priorität Hoch
Beschreibung Das System wird über eine benutzerfreundliche und intuitive
Schnittstelle verfügen, über die der Benutzer die
Registrierungsdaten leicht ausfüllen kann.
Eingang Informationen für den Benutzer
Prozess Schnittstelle zur Registrierung
Ausgänge Registrierte Daten
Tabelle 2: Funktionale Anforderungen - Datenprotokollierungsschnittstelle

Name Anpassungsfähiges System

Typ Anforderung
Priorität Hoch
Beschreibung Das System muss sich an jedes Gerät (Computer,
Mobiltelefon, Tablet) anpassen können.
Eingang Inhaltlicher Leiter
Prozess Anpassung an das Host-Gerät
Ausgänge Verwendung des Inhaltsmanagers auf dem Host-Gerät
Tabelle 3: Funktionale Anforderungen - Adaptives System
Name Interface-Vorlage
Typ Anforderung
Priorität Hoch
Beschreibung Das System wird über eine Vorlage verfügen, die es dem
Benutzer ermöglicht, Änderungen vorzunehmen und sie nach
seinen Wünschen anzupassen.
Eingang Systemvorlage
Prozess Modellvorlage pro Benutzer
Ausgänge Anpassung der Vorlage an den Geschmack des Benutzers
Tabelle 4: Funktionale Anforderungen - Schnittstellenvorlage
 Name Browser-Kompatibilität
Typ Anforderung
Priorität Hoch
Beschreibung Das System muss mit den aktuellen Internet-Browsern
(Internet Explorer, Mozilla Firefox, Google Chrome)
kompatibel sein.
Eingang Datenverwalter
Prozess Browser-Kompatibilität
Ausgänge Betrachtung im Browser
Tabelle 5: Funktionale Anforderungen - Browser-Kompatibilität

NICHT-FUNKTIONALE ANFORDERUNGEN

Name Angriffe auf die Sicherheit

Typ Anforderung
Priorität Hoch
Beschreibung Das System muss in der Lage sein, Angriffe wie SQL-
Injektionen, xss-Angriffe, Middleware, CSRF-Angriffe und
Formularvalidierung zu verhindern.
Eingang SQL-Injection-Angriffe, xss-Angriffe, Middleware, CSRF-
Angriffe, Formularvalidierung.
Prozess Angriff erkennen
Ausgänge Angriff stoppen
Tabelle 6: Nicht-funktionale Anforderungen - Sicherheitsangriffe
 Name Betriebsfähigkeit
Typ Anforderung
Priorität Hoch
Beschreibung Das Inhaltsverwaltungssystem sollte für Benutzer, die keine
Kenntnisse in der Webentwicklung haben, einfach zu
bedienen sein.
Eingang Idee der Website
Prozess Gestaltung und Konfiguration der Website durch den Nutzer
Ausgänge Vom Nutzer ausgefüllte Website
Tabelle 7: Nichtfunktionale Anforderungen - Operationalität

Name Zugang zum Konto

Typ Anforderung
gPriorität Hoch
Beschreibung Der Zugang zu den Konten muss über Passwörter mit
mindestens 6 Ziffern erfolgen.
Eingang Beginn des Abschnitts
Prozess Passwort anfordern
Ausgänge Abschnitt starten
Tabelle 8: Nicht-funktionale Anforderungen - Zugang zu Konten
Name Betrachten mit Browsern
Typ Anforderung
Priorität Hoch
Beschreibung Das System muss in aktuellen Browsern (Internet Explorer,
Mozilla Firefox, Google Chrome) angezeigt werden können.
Eingang Webprojekt in Arbeit
Prozess Browser-Anpassung
Ausgänge Visualisieren Sie das aktuelle Projekt
Tabelle 9: Nicht-funktionale Anforderungen - Browser-Ansicht
Name Uhrzeit auf dem Display
 Typ Anforderung
Priorität Medien
Beschreibung Es sollte nicht länger als 6 Sekunden dauern, bis das System
die geänderten Inhalte im Inhaltsmanager anzeigt.
Eingang Web-Projekt
Prozess Inhalt ändern
Ausgänge Änderungen am Content Management System
Tabelle 10: Nicht-funktionale Anforderungen - Zeit auf dem Display
Name Benutzerfreundlichkeit
Typ Anforderung
Priorität Hoch
Beschreibung Das System muss Fehlermeldungen anzeigen, die es dem
Benutzer ermöglichen, die Art des Fehlers zu identifizieren.
Eingang Problem, das sich dem Benutzer in einem Teil des Projekts
stellt.
Prozess Analyse des Problems
Ausgänge Feststellen, um welche Art von Problem es sich handelt, und
Anzeige auf dem Bildschirm
Tabelle 11: Nicht-funktionale Anforderungen - Benutzerfreundlichkeit
Name Einschränkung der Vorlage
Typ Anforderung
Priorität Medien
Beschreibung Das System verfügt nur über eine Basisvorlage, die vom
Benutzer geändert werden kann.
Eingang Grundlegende Vorlage
Prozess Ändern Sie die Grundvorlage des Content Managers
Ausgänge Maßgeschneiderte Vorlage
Tabelle 12: Nicht-funktionale Anforderungen - Einschränkung der Templates
Funktionale und nicht-funktionale Anforderungen, Beispiele und Tipps
Die Softwareentwicklung gehört zu den Tätigkeiten, bei denen wir für alles Namen und Kategorien
haben. Und ich meine alles. Manchmal ist dies überflüssig und nutzlos, aber manchmal gibt es
Konzepte, die sehr gut zu kennen und zu differenzieren sind. Ein Beispiel hierfür ist der Unterschied
zwischen funktionalen Anforderungen (FR) und nicht-funktionalen Anforderungen (NFR). Und da
die Anforderungen an Softwaresysteme (unter anderem) auf diese Weise klassifiziert werden, sollten
die folgenden Techniken für eine korrekte Identifizierung in Betracht gezogen werden.

Funktionale Anforderungen

Funktionale Anforderungen sind Aussagen über die Dienste, die das System bereitstellen wird, und
zwar in der Art und Weise, wie es auf bestimmte Eingaben reagieren wird. Wenn wir von Eingaben
sprechen, meinen wir nicht unbedingt nur Benutzereingaben. Dabei kann es sich um Interaktionen
mit anderen Systemen, automatische Reaktionen oder vordefinierte Prozesse handeln. In einigen
Fällen wird in den funktionalen Anforderungen von Systemen auch ausdrücklich angegeben, was
das System nicht tun darf. Es ist wichtig, daran zu denken, dass eine FR auch eine negative Aussage
sein kann. Solange das Ergebnis seines Verhaltens eine funktionale Antwort an den Benutzer oder
an ein anderes System ist, ist es korrekt. Außerdem ist es nicht nur richtig, sondern auch notwendig,
sie zu definieren. Und das bringt uns zum nächsten Punkt.

Viele Probleme im Software-Engineering (gemeint ist der Entwicklungsprozess selbst) beginnen mit
ungenauen Anforderungsspezifikationen. Es ist ganz natürlich, dass ein Business Analyst (oder wer
auch immer die Systemanforderungen definiert und dokumentiert) einige Annahmen als
allgemeines Wissen oder bestimmte Verhaltensweisen als selbstverständlich voraussetzt. Aber
bedenken Sie, dass es für einen Systementwickler auch ganz natürlich ist, eine mehrdeutige
Anforderung so einfach wie möglich zu interpretieren, um ihre Umsetzung zu vereinfachen. Ein
deutliches Beispiel für diese Probleme findet sich in den gemeinsamen Funktionen im
Zusammenhang mit der Benutzererfahrung:
 Benutzergeschichte: Als Benutzer möchte ich, dass die Anwendung einfach zu bedienen ist, so
dass ich nicht viel Zeit aufwenden muss, um die Bedienung zu erlernen.
 Was bedeutet es, "benutzerfreundlich" zu sein?
 Einfach für wen?
 Wie wird sie gemessen?
 Wie kann man das verfolgen?
 Wie wird es getestet? Nach welchen Kriterien?
Dies ist nicht gegen die Entwickler gerichtet, sondern eher gegen das menschliche Verhalten. Wenn
Sie etwas annehmen, nehmen andere vielleicht etwas anderes an, und das ist in Ordnung. Der
Analyst ist jedoch für die Dokumentation verantwortlich, so dass es seine Aufgabe sein sollte, dafür
zu sorgen, dass es keine Verständnislücken oder Grauzonen gibt. Aus diesem Grund sind Pre-
Planning- und Storytelling-Sitzungen sehr wichtig, um sicherzustellen, dass das gesamte Team
hinsichtlich der Anforderungen, des Geschäftsziels und der Art und Weise ihrer Umsetzung auf
derselben Seite steht. Um auf das vorherige Beispiel zurückzukommen, könnten wir die
Anforderung in mehrere neue Anforderungen aufteilen, die einfacher zu verstehen, zu entwickeln,
zu testen, zu verfolgen und zu liefern sind. Eine davon könnte sein:
 Benutzergeschichte: Als Benutzer möchte ich, dass bei der ersten Anmeldung eine Anleitung
angezeigt wird, damit ich sehen kann, wofür die einzelnen Optionen auf dem Startbildschirm
verwendet werden.
 Sie wissen, was Sie zeigen müssen: ein Tutorial.
 Sie wissen, was Sie ankreuzen müssen, was jede Option auf dem Startbildschirm erklärt.
 Sie wissen, wann es angezeigt werden muss, nämlich bei der ersten Anmeldung des Benutzers
(Sie können später erklären, ob das Tutorial übersprungen werden kann, zu anderen Zeiten
angezeigt werden kann, aus einem bestimmten Bereich des Menüs aufgerufen werden kann
usw.).
Um auf FR zurückzukommen: Grundsätzlich sollte die Spezifikation der funktionalen
Anforderungen an ein System vollständig und konsistent sein. Vollständig bedeutet, dass alle vom
Benutzer und/oder einem anderen System angeforderten Dienste definiert sind. Konsistenz
bedeutet, dass die Anforderungen keine widersprüchliche Definition haben.
Nicht-funktionale Anforderungen

Es handelt sich um Anforderungen, die sich nicht direkt auf die vom System bereitgestellten
spezifischen Funktionen (Benutzereigenschaften) beziehen, sondern auf die Eigenschaften des
Systems: Leistung, Sicherheit, Verfügbarkeit.Einfacher ausgedrückt, es geht nicht darum, "was" das
System tut, sondern "wie" es es tut. Alternativ dazu definieren sie Systembeschränkungen wie die
Kapazität von Eingabe-/Ausgabegeräten und die Darstellung von Daten, die in der
Systemschnittstelle verwendet werden.
Nicht-funktionale Anforderungen ergeben sich aus den Bedürfnissen der Benutzer, aufgrund von
Haushaltszwängen, Organisationsrichtlinien, der Notwendigkeit der Interoperabilität mit anderen
Software- oder Hardwaresystemen oder externen Faktoren wie Sicherheitsvorschriften,
Datenschutzrichtlinien usw.

Es gibt verschiedene Arten von Anforderungen, die je nach ihrer Bedeutung klassifiziert werden.
 Anforderungen an das Produkt. Sie spezifizieren das Verhalten des Produkts, z. B.
Leistungsanforderungen an die Ausführungsgeschwindigkeit des Systems und die benötigte
Speichermenge, Zuverlässigkeitsanforderungen, die die Fehlerquote des Systems als akzeptabel
festlegen, sowie Anforderungen an die Übertragbarkeit und die Benutzerfreundlichkeit.
 Organisatorische Anforderungen. Sie leiten sich aus den bestehenden Richtlinien und Verfahren
der Kundenorganisation und der Organisation des Entwicklers ab: Standards für die zu
verwendenden Prozesse, Implementierungsanforderungen wie Programmiersprachen oder die
zu verwendende Entwurfsmethode und Lieferanforderungen, die festlegen, wann das Produkt
und seine Dokumentation geliefert werden.
 Externer Bedarf. Sie ergeben sich aus Faktoren, die außerhalb des Systems und seines
Entwicklungsprozesses liegen. Dazu gehören Interoperabilitätsanforderungen, die festlegen, wie
das System mit anderen Systemen in der Organisation interagiert, rechtliche Anforderungen,
die befolgt werden müssen, um sicherzustellen, dass das System gesetzeskonform arbeitet, und
ethische Anforderungen. Letztere werden dem System auferlegt, um sicherzustellen, dass es
vom Benutzer akzeptiert wird.
In der Praxis ist es manchmal schwierig, solche Anforderungen quantitativ zu spezifizieren. Es ist
den Kunden nicht immer möglich, ihre Ziele in quantitative Anforderungen zu übersetzen. Für
einige von ihnen, wie z. B. die Instandhaltung, ist es möglicherweise nicht möglich, überhaupt
Metriken zu verwenden; die Kosten für eine objektive Überprüfung nichtfunktionaler quantitativer
Anforderungen können sehr hoch sein. Und deshalb ist es auch sehr wichtig, sie sehr sorgfältig zu
dokumentieren. Ein Analyst kann mit Unterstützung des Entwicklungsteams und des Testteams
messbare Kriterien definieren, um zu wissen, wann eine Anforderung erfolgreich als "erledigt"
markiert werden kann.
Wie bei den funktionalen Anforderungen ist eine Verallgemeinerung nie eine gute Sache, aber in
diesem Fall ist sie sogar noch wichtiger. Warum? Denn das Ergebnis der Entwicklung nicht-
funktionaler Anforderungen ist für den Endnutzer möglicherweise nicht eindeutig.
 Schlechtes Beispiel für RNF: Das System muss sicher sein.
 Wie sicher ist "sicher"?
 In welchen Situationen?
 Gibt es eine Norm, die erfüllt werden muss?
 In welchen Abschnitten?
 Was soll geschehen, wenn das System nicht so schnell wie erforderlich funktioniert?

In solchen Fällen kann die Umsetzung einer nicht definierten nichtfunktionalen Anforderung
problematisch, kostspielig und zeitaufwändig sein. Auch weil ein NFR in den meisten Fällen nicht
etwas ist, an dem das Team isoliert für einen bestimmten Zeitraum arbeitet. Die RNF kann während
des gesamten Projekts (und sogar vor Beginn oder nach der Lieferung, in der Wartungsphase)
behandelt werden. Auch hier könnte das obige Beispiel in mehrere Anforderungen unterteilt
werden, die sich leichter verfolgen und umsetzen lassen.
 Gutes Beispiel für RNF: Die gesamte externe Kommunikation zwischen den Datenservern, der
Anwendung und dem System-Client muss mit dem RSA-Algorithmus verschlüsselt werden.
 Sie wissen, welche Art von Kommunikation verschlüsselt werden muss.
 Sie wissen, welchen Algorithmus Sie verwenden und validieren müssen.

Funktionale und nicht-funktionale Anforderungen müssen im Anforderungsdokument

unterschieden werden, unabhängig davon, ob es sich um ein FVS, ein Produktportfolio oder ein
anderes Artefakt handelt, das verwendet wird. In der Praxis kann dies schwierig sein. Wenn eine
nicht-funktionale Anforderung getrennt von den funktionalen Anforderungen angegeben wird, ist es
manchmal schwierig, die Beziehung zwischen ihnen zu erkennen. Wenn RNFs mit funktionalen
Anforderungen deklariert werden, ist es schwierig, funktionale und nicht-funktionale Bedingungen
zu trennen und Anforderungen zu identifizieren, die sich auf das System als Ganzes beziehen. Je
nach Art des Systems oder der Anwendung muss ein angemessenes Gleichgewicht gefunden werden.
Wenn Sie z.B. mit einem Product Backlog arbeiten, könnten Sie separate User Stories für RNFs
haben, aber einen Link zu ihnen in den RFs hinzufügen, die von ihnen beeinflusst werden können.
Dies ist eine gängige Option in den meisten der heute verwendeten Banknotenverfolgungssysteme.

In jedem Fall sollten sowohl RFs als auch NFRs immer dokumentiert werden, auch wenn es
schwierig ist, die Beziehung zwischen ihnen in den Artefakten herzustellen. Dies wird dem Team
helfen, Hin- und Herdiskussionen zu reduzieren, Zeit zu sparen und vor allem unnötige Probleme
mit dem Kunden zu vermeiden.
Funktionale Anforderungen: Beispiele

Die funktionalen Anforderungen eines Systems sind diejenigen, die eine Aktivität beschreiben, die
das System ausführen muss, mit anderen Worten, das bestimmte Verhalten oder die Funktion
eines Systems oder einer Software, wenn bestimmte Bedingungen erfüllt sind.

Dazu gehören in der Regel Funktionen, die von bestimmten Bildschirmen ausgeführt werden,
Beschreibungen der vom System auszuführenden Arbeitsabläufe und andere geschäftliche,
Compliance-, Sicherheits- oder andere Anforderungen.
In diesem Artikel stellen wir Beispiele für funktionale Anforderungen vor, die sich auf
Geschäftsfunktionen, auf die in die Systembildschirme einzugebenden Daten (grafische
Schnittstelle), auf die Zugangskontrolle oder auf die Erstellung von Berichten, die von den
Aufsichtsbehörden verlangt werden, beziehen, sowie auf andere.

PMOInformatica präsentiert: 40 Beispiele für funktionale Anforderungen an ein System.

Wie funktionale Anforderungen beschrieben und klassifiziert werden

Diefunktionalen Anforderungen an Software werden in der Regel in derAnforderungs-

Traceability-Matrix und in derSoftware-Anforderungsspezifikation festgehalten, wobei letztere
die Operationen und Aktivitäten dokumentiert, die das System ausführen können muss.
Mögliche funktionale Anforderungen an ein System sind:
 Beschreibungen der in das System einzugebenden Daten.
 Beschreibungen der auf den einzelnen Bildschirmen auszuführenden Vorgänge.
 Beschreibung der vom System durchgeführten Arbeitsabläufe.
 Beschreibung der Systemberichte und anderer Ausgaben.
 Festlegung, wer Daten in das System eingeben darf.
 Wie das System den geltenden sektoralen oder allgemeinen Vorschriften und Normen
entspricht.

Wie andere Arten von Softwareanforderungen, z. B.nicht-funktionale Anforderungen, können

auch funktionale Anforderungen nach ihrem Zweck klassifiziert werden, z. B.
Geschäftsanforderungen, Anforderungen, die sich aus regulatorischen Aspekten ergeben,
Sicherheitsanforderungen und andere.
Im Folgenden finden Sie Beispiele fürfunktionale Anforderungen, die nach verschiedenen
Bereichen geordnet sind:
Beispiele für Anforderungen an funktionale Prozesse oder Geschäftsbereiche
 Das System sendet eine E-Mail, wenn eine der folgenden Transaktionen registriert wird:
Kundenauftrag, Versand der Ware an den Kunden, Ausstellung der Rechnung an den Kunden und
Registrierung der Zahlung durch den Kunden.
 Die Registrierung von Bestellungen mit unvollständigen Pflichtangaben wird zugelassen, die
später durch Änderung der Bestellung ergänzt werden können. Die Auftragsdaten müssen
vollständig sein, bevor der Auftrag genehmigt werden kann.
 Wenn ein Auftrag genehmigt wird, geht der Antrag zum nächsten Schritt des im System
konfigurierten Genehmigungsworkflows über.
 Das System muss autorisierten Benutzern die Eingabe vonProjektplänen und Zeitplänen
ermöglichen.
 Mit dem System könnenProjektpläne und Zeitpläne genehmigt, geändert oder aktualisiert
werden.
 Das System ermöglicht die automatische Versendung von Bestell-Lieferscheinen direkt an
das Lager.
 Jedem Auftrag wird eine eindeutige Kennung zugewiesen, mit der er bei allen
nachfolgenden Vorgängen identifiziert werden kann.
 Bei der Eingabe von Abrufen wird jeder Abruf mit einem Kundenauftrag verknüpft.
 Die Fakturierung von Kundenaufträgen erfolgt stapelweise mit Hilfe eines Bildschirms für
noch nicht fakturierte Aufträge, der die noch nicht fakturierten Aufträge anzeigt. Sobald die
Aufträge in Rechnung gestellt wurden, werden sie in dieser Liste nicht mehr angezeigt.
 Das System ermöglicht auch die Erfassung manueller Rechnungen, die nicht mit Aufträgen
verknüpft sind, diese müssen jedoch vor der Buchung von der Gruppe der Manager genehmigt
werden.
 Der Einkaufsprozess im System umfasst die folgenden Schritte und Transaktionen:
Bedarfserfassung, Erstellung der Anfrage und Ausstellung der Bestellung.
 Die Bestandteile der Anfrage sind die gleichen wie die der zugehörigen Bestellanforderung
und die der Bestellung. Das System muss die Erstellung von Anfragen und Teilbestellungen
ermöglichen.
 Die Buchung von Transaktionen für Verkaufsrechnungen und Eingangsrechnungen kann so
konfiguriert werden, dass sie automatisch bei der Buchung oder manuell in Stapeln (Batch-
Prozess) erfolgt.
 Die Software muss in der Lage sein, die folgenden Finanzberichte auszugeben: Bilanz,
Gewinn- und Verlustrechnung, Kapitalflussrechnung. Darüber hinaus muss sie ein Hauptbuch und
ein analytisches Buch führen können.
 Bestellungen, die die im konfigurierten Auftragsfreigabefluss festgelegten Beträge
überschreiten, müssen die in diesem Genehmigungsfluss festgelegten Genehmigungen
durchlaufen.

Beispiele für funktionale GUI-Anforderungen

 Die Lösung validiert automatisch den Kunden, der einer Bestellung zugeordnet ist, mit dem
Kontaktmanagementsystem.
 In das Feld Betrag können nur numerische Werte mit zwei Dezimalstellen eingegeben
werden.
 Das Feld für das Transaktionsdatum akzeptiert nur Daten, die vor dem heutigen Tag liegen
(aktueller Tag).
 In das Namensfeld können nur alphabetische Zeichen eingegeben werden.
 In das Adressfeld können alphabetische, numerische und Sonderzeichen eingegeben
werden.
 Das Länderfeld wird aus einer Auswahlliste bestehen. Das mit einer Adresse verbundene
Land muss zuvor im System registriert worden sein.
 Das Feld Staat, Provinz oder Departement enthält eine Auswahlliste. Den Nutzern werden
nur die Staaten angezeigt, die mit dem zuvor ausgewählten Land verbunden sind. Das
auszuwählende Departement oder die Provinz muss in der entsprechenden Funktionalität
registriert sein.
 Das Feld Positionsmaterial auf dem Bestellanforderungsbild ist eine Vorauswahlliste, die nur
die im Materialstamm registrierten Materialien anzeigt.
 In das Feld für das Buchungsdatum können nur Daten eingegeben werden, die einer im
System offenen Buchungsperiode entsprechen.
 Der Zahlungsregistrierungsbildschirm kann die Daten auf dem Bildschirm auf dem Drucker
ausgeben.
 Der Name, die Gesamtgröße, der verfügbare Speicherplatz und das Format eines an den
USB-Anschluss des Computers angeschlossenen USB-Sticks oder Flash-Laufwerks werden
angezeigt.

Beispiele für rechtliche oder regulatorische Funktionsanforderungen

 Das System muss den Zugang kontrollieren und nur befugten Benutzern Zugang gewähren.
 Die Datenbank wird mit Prüfpfaden eingerichtet.
 Bei Tabellenkalkulationen werden die Daten durch elektronische Signaturen gesichert.
 Das System ermöglicht die Erstellung und Herausgabe des XX-Regulierungsberichts
gemäß den in den geltenden Vorschriften und Gesetzen festgelegten Anforderungen.
 Die Verkaufs- und Einkaufsbücher werden in dem von den zuständigen Steuerbehörden
festgelegten Format ausgestellt.
Beispiele für Sicherheitsanforderungen

Das System muss den Zugang kontrollieren und nur befugten Benutzern Zugang gewähren. Die
Benutzer müssen sich mit einem Benutzernamen und einem Passwort am System anmelden.
 Das System sendet eine Warnung an den Systemadministrator, wenn eines der folgenden
Ereignisse eintritt: Registrierung eines neuen Kontos, Anmeldung eines Kunden, 2 oder mehr
Fehlversuche bei der Eingabe des Benutzerpassworts und Änderung des Benutzerpassworts.
 Mitglieder der Benutzergruppe Analytiker können Anfragen eingeben, aber nicht
genehmigen oder löschen.
 Mitglieder der Benutzergruppe Manager können Bewerbungen eingeben und genehmigen,
aber nicht löschen.
 Mitglieder der Benutzergruppe "Administrator" können keine Bewerbungen eingeben oder
genehmigen, aber sie können sie löschen.
 Der Austausch von Daten über das Internet durch die Software erfolgt über das
verschlüsselte https-Protokoll.

Beispiele für externe Schnittstellenanforderungen (Hardware und Software)

 Die Software kann unter den Betriebssystemen Windows, Linux und OSX verwendet
werden.
 Die Anwendung muss nutzbar sein, ohne dass außer einem Webbrowser zusätzliche
Software installiert werden muss.
 Die Anwendung muss mit den Webbrowsern Chrome, Firefox und Internet Explorer nutzbar
sein.

Über funktionale Anforderungen

Funktionale Anforderungen sollten so formuliert werden, dass der Leser die Funktionsweise des
Systems auch ohne besondere technische Kenntnisse verstehen kann.
Wichtig ist, dass ein Standard für die Formulierung von Anforderungen festgelegt wird und dass
dieser in allen Dokumenten eingehalten wird.
Ebenso müssen funktionale Anforderungen nicht unbedingt in Form von schriftlichen
Beschreibungen definiert werden, sondern können auch in Form von Diagrammen oder
Prozessabläufen festgelegt werden, die in die funktionale Spezifikation der zu entwickelnden
Software oder des Systems aufgenommen werden.
Um funktionale Softwareanforderungen zu ermitteln und zu dokumentieren, werden zwei Schritte
unternommen: Zunächst werdenTechniken zur Anforderungserhebung angewandt, wie z. B.
Beobachtung, Befragung, Beobachtung und andere.
Das Ergebnis der Anforderungserhebung wird im Software-Anforderungsdokument dokumentiert.
Im Folgenden stellen wir Ihnen eine Vorlage zur Verfügung:
>Software-Anforderungsdokument

Nach der Erhebung werdenTechniken der Anforderungsanalyse angewandt, um die in der

Erhebung erhaltenen Informationen zu überprüfen und die funktionale Spezifikation auszuarbeiten.
Einige dieser Techniken sind funktionale Zerlegung, Prozessmodellierung, Anwendungsfälle und
andere.
Referenzen

Eriksson, U. Funktionale vs. nicht funktionale Anforderungen. Veröffentlicht in ReqTest.

Eriksson, U. Der Unterschied zwischen funktionalen und nicht-funktionalen

Anforderungen. . Veröffentlicht in ReqTest.

Ofni-Systeme. Funktionale Anforderungen

ReqView. Beispiele für Dokumentation

Nicht-funktionale Anforderungen: Beispiele

Wir präsentieren den dritten Teil der Serie über nicht-funktionale Anforderungen mit einigen
Beispielen, die Sie bei der Definition dieser Anforderungen unterstützen.

Nicht-funktionale Anforderungen stellen allgemeine Merkmale und Einschränkungen der zu

entwickelnden Anwendung oder des Systems dar.

Sie sind oft schwer zu definieren, da ihre Konformität oder Nichtkonformität frei interpretiert werden
kann, so dass es ratsam ist, ihre Definition mit messbaren Akzeptanzkriterien zu versehen.

Zu den vorgestellten Beispielen für nicht-funktionale Anforderungen gehören solche, die sich auf
Attribute wie Effizienz, Sicherheit, Zuverlässigkeit und Benutzerfreundlichkeit des Systems
beziehen. Wir stellen auch Beispiele für nicht-funktionale organisatorische und externe
Anforderungen vor.

Was sind nicht-funktionale Anforderungen und wie werden sie klassifiziert?

Wenn Sie weitere Informationen zum Konzept der nicht-funktionalen Anforderungen suchen,
empfehlen wir Ihnen den ersten Teil dieser SerieNicht-funktionale Anforderungen: Warum sie
wichtig sind

Auf einer ersten Ebene können nicht-funktionale Anforderungen in Produkt-, Organisations- und
externe Anforderungen unterteilt werden, wie wir Ihnen im Artikel über dieKlassifizierung von
nicht-funktionalen Anforderungen gezeigt haben.

Auf einer zweiten Ebene können die Produktanforderungen in Anforderungen an

Benutzerfreundlichkeit, Effizienz, Zuverlässigkeit und Sicherheit unterteilt werden. Die
organisatorischen Anforderungen lassen sich wiederum in umweltbezogene, organisatorische und
entwicklungsbezogene Anforderungen unterteilen. Externe Anforderungen können auch in
regulatorische, ethische und gesetzliche Anforderungen unterteilt werden.

Wenn die Phasen der Anforderungserhebung und -analyse abgeschlossen sind, können die nicht-
funktionalen Anforderungen in einem Software-Anforderungsdokument festgehalten werden.
Nachstehend finden Sie eine Vorlage:

Einige Beispiele für nicht-funktionale Anforderungen

Wie wir in dem Artikel über dieKlassifizierung nichtfunktionaler Anforderungen gezeigt haben,
können sie auf einer ersten Ebene in Produkt-, Organisations- und externe Anforderungen
unterteilt werden.

Auf einer zweiten Ebene können die Produktanforderungen in Anforderungen an

Benutzerfreundlichkeit, Effizienz, Zuverlässigkeit und Sicherheit unterteilt werden. Die
organisatorischen Anforderungen lassen sich wiederum in umweltbezogene, organisatorische und
entwicklungsbezogene Anforderungen unterteilen. Externe Anforderungen können auch in
regulatorische, ethische und gesetzliche Anforderungen unterteilt werden.

Im Folgenden sind Beispiele für nichtfunktionale Anforderungen aufgeführt, die nach diesen
verschiedenen Bereichen geordnet sind.

Beispiele für nicht-funktionale Produktanforderungen

Wirkungsgrad

 Das System muss in der Lage sein, N Transaktionen pro Sekunde zu verarbeiten. Dies wird
mit Hilfe desSoapUI-Tools gemessen, das für das Testen von Webservice-Software eingesetzt
wird.
 Alle Systemfunktionen und Geschäftstransaktionen müssen in weniger als 5 Sekunden auf
den Benutzer reagieren.
 Das System muss in der Lage sein, mit bis zu 100.000 Nutzern mit gleichzeitigen Sitzungen
zu arbeiten.
 Geänderte Daten in der Datenbank müssen für alle zugreifenden Benutzer in weniger als 2
Sekunden aktualisiert werden.

Logische Sicherheit und Datensicherheit

Die Systemzugriffsberechtigungen können nur vom Datenzugriffsadministrator geändert werden.

 Das neue System sollte unter Anwendung vonProgrammiermustern und Empfehlungen
entwickelt werden, die die Datensicherheit erhöhen.
 Alle Systeme sollten alle 24 Stunden eine Sicherungskopie erhalten. Backups sollten an
einem sicheren Ort in einem anderen Gebäude als dem, in dem sich das System befindet,
aufbewahrt werden.
 Die gesamte externe Kommunikation zwischen Datenserver, Anwendung und System-Client
muss mit dem RSA-Algorithmus verschlüsselt werden.
 Wenn ein Sicherheitsangriff oder eine Systemverletzung festgestellt wird, kann das System
nicht weiterarbeiten, bis es von einem Sicherheitsadministrator entsperrt wird.

Industrielle Sicherheit

 Das System darf nicht weiter betrieben werden, wenn die Außentemperatur unter 4 Grad
Celsius liegt.
 Das System darf im Falle eines Brandes nicht weiter betrieben werden. (z.B.. Ein Aufzug).

Benutzerfreundlichkeit

 Die Einarbeitungszeit für einen Benutzer sollte weniger als 4 Stunden betragen.
 Die Benutzerfehlerquote muss weniger als 1 % der gesamten im System ausgeführten
Transaktionen betragen.
 Das System muss über gut strukturierte Benutzerhandbücher verfügen.
 Das System muss Fehlermeldungen ausgeben, die informativ und auf den Endbenutzer
ausgerichtet sind.
 Das System muss über ein Online-Hilfemodul verfügen.
 Die Webanwendung muss"responsiv" gestaltet sein, damit sie auf mehreren PCs, Tablet-
PCs und Smartphones korrekt angezeigt wird.
 Das System muss über gut gestaltete grafische Schnittstellen verfügen.

Verlässlichkeit

 Das System muss zu 99,99 % der Zeit verfügbar sein, wenn ein Benutzer versucht, darauf
zuzugreifen.
 Die Zeit für das Starten oder Wiedereinschalten des Systems darf 5 Minuten nicht
überschreiten.
 Die Ausfallrate des Systems darf 0,5 % der Gesamtbetriebszeit nicht überschreiten.
 Die durchschnittliche Störungsdauer darf 15 Minuten nicht überschreiten.
 Die Ausfallwahrscheinlichkeit des Systems darf 0,05 nicht überschreiten.

Weitere Beispiele für Produktanforderungen

 Das System wird für die Plattformen PC und Macintosh entwickelt.

 Die Anwendung muss mit allen Versionen von Windows kompatibel sein, beginnend mit
Windows 95.
 Die Anwendung muss weniger als 500 MB RAM verbrauchen.
 Die Anwendung darf nicht mehr als 2 GB Speicherplatz beanspruchen.
 Die neue Anwendung muss Alphabetschriften in Englisch, lateinischen Sprachen (Spanisch,
Französisch, Portugiesisch, Italienisch), Arabisch und Chinesisch verarbeiten.
 Die Benutzeroberfläche wird nur für Webbrowser mit HTML5 und JavaScript implementiert.

Beispiele für nicht-funktionale organisatorische Anforderungen

 Das anzuwendende Softwareentwicklungsverfahren muss explizit definiert werden (in

Verfahrenshandbüchern) und den ISO 9000-Normen entsprechen.
 Die Software-Entwicklungsmethodik istBehaviour Driven Development (BDD) mit
Unterstützung von Cucumber.
 Das System muss mit den Werkzeugen von CASE XYZ entwickelt werden.
 Der Entwicklungsprozess wird mit Hilfe eineswebbasierten Tools zur Verwaltung des
Softwareentwicklungsprozesses gesteuert.
 Für das zu entwickelnde System sollte ein Notfallwiederherstellungsplan festgelegt werden.
 Alle zwei Wochen sollten Managementberichte erstellt werden, aus denen hervorgeht,
welcher Aufwand für die einzelnen Komponenten des neuen Systems betrieben wurde.
 Die Software-Tests werden mit einemSoftware-Testmanagement-Tool verwaltet.
 Die Softwaretests werden mitSelenium und Rubyals Werkzeug und Skriptsprache für die
Softwaretestautomatisierung durchgeführt.

Beispiele für externe nicht-funktionale Anforderungen

 Medizinische Datensysteme: Das neue System und seine Datenpflegeverfahren müssen

den Gesetzen und Vorschriften zum Schutz medizinischer Daten entsprechen.
 Das neue System wird den Regeln der General Public License (GNU) folgen, d.h. es wird
frei und quelloffen sein, d.h. jeder kann die Software ändern, es gibt keine Patente und keine
Garantien.
 Die zu entwickelnden Websites müssen dem Gesetz zur Gleichbehandlung von Menschen
mit Behinderungen entsprechen.
 Das System wird seinen Betreibern keine anderen persönlichen Daten der Kunden als
Namen und Referenznummern offenlegen.

Nicht-funktionale Anforderungen und funktionale Anforderungen

Nicht-funktionale Anforderungen werden in der Regel allgemein und ohne Bezug auf ein Modul,
eine Transaktion oder ein Merkmal des Systems formuliert, da sie sonst zufunktionalen
Anforderungen werden würden.

Zum Beispiel:

Das System muss sicherstellen, dass die Daten vor unbefugtem Zugriff geschützt sind

Es ist ratsam, die Definitionen der nicht-funktionalen Anforderungen mit messbaren

Akzeptanzkriterien zu versehen.
Nicht-funktionale Anforderungen können wiederum zu funktionalen Anforderungen führen, wie im
obigen Beispiel zu sehen ist:

Das System muss ein Verfahren zur Benutzerautorisierung umfassen, bei dem sich die Benutzer
mit einem Benutzernamen und einem Passwort identifizieren müssen. Nur die auf diese Weise
autorisierten Benutzer können auf die Daten im System zugreifen.

Auf diese Weise geschrieben, wird die Anforderung funktional.

Allerdings lassen sich nicht alle nicht-funktionalen Anforderungen in funktionale Anforderungen

umwandeln, weshalb es sehr wichtig ist, Akzeptanzkriterien zu definieren.

Beispiele für die Definition funktionaler Anforderungen

>Funktionale Anforderungen an ein Vertriebssystem

>Beispiele für funktionale Anforderungen

10 Arten von nicht-funktionalen Tests
Beim nicht-funktionalen Testen liegt der Schwerpunkt auf der Validierung eines Systems oder einer
Anwendung anhand dernicht-funktionalen Anforderungen, d. h. der Funktionsweise des
Systems und nicht anhand bestimmter Verhaltensweisen.

Nicht-funktionale Merkmale eines Systems oder einer Anwendung werden oft auf variablen Skalen
quantifiziert, wie z. B. die Antwortzeiten bei Leistungstests.

Das ISTQB weist darauf hin, dass die Unterlassung von nichtfunktionalen Tests zu potenziell
katastrophalen Qualitätsproblemen nach der Produktionsfreigabe führen kann. Diese Art von Tests
ist jedoch kostspielig, so dass die Risiken vor der Bindung von Projektressourcen bewertet werden
sollten.

In diesem Artikel stellen wir Ihnen 10 Arten von nicht-funktionalen Tests vor, insbesondere
Usability-, Sicherheits-, Last-, Stress-, Volume-, Konfigurations-, Performance-, Skalierbarkeits-,
Recovery- und Wartbarkeitstests.

10 Arten von nicht-funktionalen Tests

Im Folgenden finden Sie eine nicht erschöpfende Liste von 10 Arten von nicht-funktionalen Tests,
die Sie in IhrenSoftwaretestplan aufnehmen können.

1. - Belastungstests

Bei Lasttests werden die Anforderungen an eine Softwareanwendung simuliert und das Ergebnis
gemessen. Diese Tests werden sowohl bei erwarteter Nachfrage als auch bei Überlastung
(Nachfragespitzen) durchgeführt.
Zur Durchführung dieser Tests ist die Verwendung vonLastsimulations-Tools wieSoapUI
erforderlich.

Lasttests helfen bei der Ermittlung der maximalen Betriebskapazität einer Anwendung sowie bei
der Identifizierung von Engpässen und Ursachen für eine mögliche Leistungsverschlechterung.

Wenn die Testlast die erwarteten Parameter übersteigt, werden diese Tests als Stresstests
bezeichnet.

2. - Stresstest

Dabei handelt es sich um Belastungstests, die bei Anforderungen durchgeführt werden, die über
der Betriebskapazität liegen, oft bis zur Bruchgrenze.

DieseArt von Softwaretests dient dazu, die Stabilität eines Systems oder einer Anwendung zu
ermitteln, wobei besonderes Augenmerk auf die Verfügbarkeit und die Fehlerbehandlung bei
Überlast gelegt wird.

Wie bei den Lasttests werdenTools benötigt, um die Nachfrage zu simulieren. SoapUI ist ein
solches Tool, mit dem Sie Anfragen für Webanwendungsserver simulieren können.

Hier ist einSopaUI Tutorial.

Durch Stresstests lassen sich u. a. Schwachstellen und Grenzen für die sichere Nutzung der
Anwendung ermitteln, die Entwurfsspezifikationen bestätigen und die Art und Weise, in der das
System versagt, feststellen.

3. - Volumenprüfungen

Beim Volumentest wird die Leistung der Anwendung mit bestimmten Datenmengen überprüft.

Wenn Sie zum Beispiel das Verhalten einer Anwendung mit einer bestimmten Datenbankgröße
sehen wollen, erweitern Sie die Datenbankgröße auf diese Parameter und führen dann Abfragen,
Prozesse oder Funktionalitäten der Anwendung aus, um ihre Leistung zu messen.

Der Testgegenstand ist nicht auf Datenbanken beschränkt, sondern kann beispielsweise auch
dazu verwendet werden, die Leistung einer Schnittstelle zu messen, wenn die Schnittstellendatei
(eine Textdatei, xml usw.) eine bestimmte Größe überschreitet.

Ziel ist es, festzustellen, ob die Anwendung bei einem bestimmten Datenvolumen normal
funktioniert, wo die Grenzen des Datenvolumens für den Betrieb liegen, und Fehlerbedingungen zu
ermitteln.

4. - Konfigurationstests
Anstatt die Leistung einer Anwendung aus der Lastperspektive zu testen, werden
Konfigurationstests verwendet, um zu überprüfen, welche Auswirkungen bestimmte
Konfigurationsänderungen auf die Leistung haben.

Ein typisches Beispiel für diese Situation ist das Experimentieren mit verschiedenen
Lastausgleichsmethoden, um zu sehen, wie die Anwendung auf ähnliche Überlastungen reagiert.

Ein weiteres Beispiel ist die Überprüfung, ob das System in verschiedenen Versionen oder
Konfigurationen von Hardware- und Software-Umgebungen, wie z. B. verschiedenen Internet-
Browsern, Browser-Versionen usw., ordnungsgemäß funktionieren kann.

5. - Gebrauchstauglichkeitsprüfung

Beim Usability-Testing konzentrieren sich dieSoftware-Tester auf die Überprüfung der

Benutzerfreundlichkeit einer Anwendung.

Zu den auf ihre Benutzerfreundlichkeit bewerteten Funktionen gehören:

Einfache Erlernbarkeit: Wie einfach ist es für die Benutzer, grundlegende Funktionen bei der
ersten Verwendung der Anwendung auszuführen.
 Effizienz:Wie schnell können erfahrene Benutzer ihre Aufgaben erledigen.
 Einprägsamkeit: Wie leicht lässt sich die Anwendung einprägen, d. h. kann sich ein
Benutzer, der die Anwendung längere Zeit nicht benutzt hat, an genügend Informationen erinnern,
um sie beim nächsten Mal effektiv zu nutzen, oder muss er von vorn anfangen zu lernen?
 Fehler: Wie viele dem Entwurf zurechenbare Fehler der Benutzer macht, wie
schwerwiegend sie sind und wie leicht sie zu beheben sind.
 Zufriedenheit: Wie gerne (oder ungern) der Nutzer das System benutzt.

6. - Sicherheitsprüfung

Sie besteht darin, die Sicherheitsattribute oder -merkmale des Systems zu testen, ob es ein
sicheres System ist oder nicht, ob es durchbrochen werden kann, ob es eine Zugangskontrolle
durch Benutzerkonten gibt und ob diese Zugänge durchbrochen werden können.

Sicherheitstests dienen auch dazu, zu überprüfen, ob das Softwareentwicklungsteambei der

Programmierung die empfohlenen Sicherheitspraktiken befolgt hat.

Zu den Sicherheitsmerkmalen eines Systems gehören Vertraulichkeit, Integrität, Authentifizierung,

Autorisierung und Verfügbarkeit.

7. - Ausdauertests

Bei Dauertests wird ein System oder eine Anwendung über einen bestimmten Zeitraum hinweg
einer bestimmten Belastung ausgesetzt, um festzustellen, wie es sich nach längerem Gebrauch
verhält.

Ein Computersystem kann sich in den ersten Stunden normal verhalten, aber nach einiger Zeit
verursachen Probleme wie Speicherlecks häufig Ausfälle.

Diese Fehler in der Softwareentwicklung können im Rahmen normaler Funktionstests nicht erkannt
werden, daher ist es wünschenswert, Stresstests in dieSoftwaretests einzubeziehen.

8. - Prüfung der Skalierbarkeit

Bei den Skalierungstests wird die Fähigkeit einer Anwendung zur Skalierung ihrer nichtfunktionalen
Merkmale überprüft, wie z. B. die von ihr unterstützte Last, die Anzahl der Transaktionen, das
Datenvolumen und andere.

Bei derEntwicklung von Skalierbarkeitstests ist es ratsam, diese in inkrementellen Blöcken

durchzuführen, da es schwierig ist, die tatsächliche Belastung einer Anwendung nach ihrer
Bereitstellung in der Produktion vorherzusagen.
Testen in inkrementellen Blöcken bedeutet zum Beispiel, dass zunächst bei geringer, dann bei
mittlerer und schließlich bei hoher Belastung getestet wird. Auf diese Weise lässt sich feststellen,
dass die Umsetzung auch skaliert und Probleme auf verschiedenen Ebenen auftauchen.

Damit die Ergebnisse zuverlässig sind, müssen dieTestumgebungen und ihre Konfiguration
konstant gehalten werden.

9. - Abhilfetests

Wiederherstellungstests werden durchgeführt, um zu überprüfen, wie schnell und wie gut sich eine
Anwendung nach einem Hardware- oder Softwarefehler erholt.

Daher muss bei Wiederherstellungstests der Ausfall erzwungen und dann überprüft werden, ob die
Wiederherstellung ordnungsgemäß erfolgt.

Ziehen Sie beispielsweise bei einer laufenden Anwendung das Netzwerkkabel ab oder
unterbrechen Sie bei einermobilen Anwendung die Verbindung zum Wi-Fi-Netz oder zum
Betreiber und stellen Sie die Verbindung anschließend wieder her.

10. - Prüfung der Wartbarkeit

Sie bestehen im Wesentlichen darin, zu bewerten, wie einfach es ist, ein System oder eine
Anwendung zu warten. Das bedeutet, wie einfach es ist, diese Änderungen zu analysieren, zu
ändern und zu testen.

Um diesen Test durchzuführen, muss die Art und Weise, wie die Anwendung implementiert ist,
nach guten Software-Engineering-Verfahren bewertet werden. Das heißt, dass die empfohlenen
Software-Engineering-Muster befolgt werden und dass keine Anti-Muster versehentlich eingeführt
werden, d. h. dass keineüblichen Programmierfehler gemacht werden.

Somerville unterteilt die nicht-funktionalen Anforderungen in drei große Typen:

Produktanforderungen, organisatorische Anforderungen und externe Anforderungen.

Nicht-funktionale Produktanforderungen

Er bezieht sich in der Regel auf Grenzen oder Beschränkungen für das Verhalten des Systems
und setzt damit Grenzen und Beschränkungen für die Möglichkeiten der Softwareentwickler
(Softwarearchitekten) und Softwareingenieure.

Einige dieser Anforderungen lassen sich leicht quantifizieren, z. B. Leistung und Zuverlässigkeit,
andere hingegen sind schwieriger, z. B. Benutzerfreundlichkeit und Anpassungsfähigkeit.

Die Produktanforderungen lassen sich in (Sommerville) einteilen:

 Anforderungen an die Benutzerfreundlichkeit:Die Benutzerfreundlichkeit ist definiert als
der Aufwand, den ein Benutzer betreiben muss, um eine Anwendungssoftware zu erlernen, zu
benutzen, Daten einzugeben und die Ergebnisse zu interpretieren. In letzter Zeit ist die
Benutzerfreundlichkeit sehr wichtig geworden, vor allem angesichts der Nachfrage
nachSoftwareentwicklung für Mobiltelefone und Tablets.

 Effizienzanforderungen:Bezogen auf die Leistung in Bezug auf Reaktionszeit, Anzahl der

Operationen pro Sekunde und andere Messwerte sowie auf den Verbrauch von Speicher,
Prozessor, Festplattenplatz oder Netzwerkressourcen.

Ein nützliches Tool zum Testen der Effizienz eines Systems ist SoapUI, das Last- oder Stresstests
von Webservices ermöglicht. Hier finden Sie einige Artikel zu diesem Thema:

 Anforderungen an die Zuverlässigkeit: Umfasst mehrere Attribute

o Verfügbarkeit: Bereitschaftdes Systems, einen korrekten Dienst zu erbringen.
o Zuverlässigkeit: Kontinuität der vom System erbrachten Dienstleistung.
o Arbeitssicherheit: Keine katastrophalen Folgen für den Benutzer oder die Umwelt.
o Integrität: Abwesenheit von unangemessenen Änderungen am System.
o Wartbarkeit: Möglichkeit, Änderungen oder Reparaturen an einem Prozess
vorzunehmen, ohne die Kontinuität des Betriebs zu beeinträchtigen.

 Sicherheitsanforderungen:Funktionale oder nicht-funktionale Fähigkeiten, die ein System

haben muss, um Attribute im Bereich der informationstechnischen Sicherheit, der Datensicherheit,
der logischen Sicherheit, der Informationszugangskontrolle (Zugangsbeschränkungen), der
Informationsauthentizität, des Datenschutzes und anderer Aspekte zu erfüllen.

Die Berücksichtigung der Produktanforderungen ist für eine kontinuierliche Anwendungsintegration

und die Entwicklung schneller, aber nachhaltiger Änderungen von entscheidender Bedeutung.

Dieses neue Paradigma ist notwendig, umneue Informationstechnologien und

Softwareanwendungen wie Mobilität, Internet der Dinge, fortgeschrittene Datenanalyse (Big
Data), Entwicklung von Systemen in die Cloud und skalierbare Informationstechnologie zu
implementieren.
Nicht-funktionale organisatorische Anforderungen

Sie leiten sich aus organisatorischen Richtlinien und Verfahren wie Prozessstandards oder
Implementierungsanforderungen ab.

Sie können u. a. Softwareentwicklungsmethoden, Programmier- (Kodierungs-) Standards und

Softwareentwicklungsunterstützungswerkzeuge (z. B. CASE-Tools), die (gemäß den
Organisationsrichtlinien) zu verwenden sind, sowie die zu erstellenden Managementberichte
umfassen.
Die uns bekanntenSoftwareentwicklungsmanagement-Tools sind als organisatorische nicht-
funktionale Anforderungen definiert.

Organisatorische Anforderungen können in folgende Kategorien eingeteilt werden (Sommerville):

 Umgebungsanforderungen:Beschreibt die Betriebsumgebung, in der das System arbeiten

muss.
 Betriebliche Anforderungen: Betriebliche Verfahren, die beschreiben, wie das System im
Kontext der Organisation genutzt wird.
 Entwicklungsanforderungen:Zu verwendende Programmiersprache,
Kodierungsstandards,Entwurfs- und Programmiermuster (und Anti-Muster), Werkzeuge zur
Verwaltung der Softwareentwicklung, Softwareentwicklungsumgebung (Entwicklungsumgebung),
Softwaretestumgebung (Testumgebung) und andere.

Einer der Aspekte, die als organisatorischeFunktionsanforderungen dokumentiert werden, ist die
Umgebung, insbesondere dieWartungs- und Verwaltungsverfahren der
Softwareentwicklungsumgebung.

Diese Verwaltung umfasst auch dieVerfahren zur Verwaltung der End-to-End-

Testumgebungen.

Externe nicht-funktionale Anforderungen

Diese ergeben sich aus dem organisatorischen Umfeld (nicht dem technischen Umfeld), in dem
das System entwickelt wird, und können entweder auf das Produkt (die entwickelte Software) oder
auch auf den Softwareentwicklungsprozess bezogen werden.

Zu diesen Anforderungen gehören u. a. wirtschaftliche Zwänge, die Interaktion oder die

Notwendigkeit, dass das System mit anderen Systemen zusammenarbeitet, gesetzliche
Anforderungen in den Bereichen Gesundheit, Sicherheit oder Datenschutz, gesetzliche
Anforderungen in Bezug auf Lizenzen, Vorschriften oder Zertifizierungen, die das Produkt je nach
Branche benötigt.

Somerville unterteilt diese Anforderungen weiter in:

Regulatorische Anforderungen:Gesetze und Vorschriften, die festlegen, was das System tun
muss und wie es es tun muss, um den Anforderungen zu entsprechen. Der Schwerpunkt eines
Systems oder einer neuen Funktion kann ausschließlich auf der Einhaltung einer Vorschrift liegen.
 Ethische Anforderungen: Anforderungen, die sicherstellen, dass das System für den
Benutzer und die Allgemeinheit akzeptabel ist und den Gepflogenheiten der Gesellschaft
entspricht, in der es eingesetzt wird oder dient.
 Gesetzliche Anforderungen:Merkmale, die das System erfüllen muss, um den
gesetzlichen Vorschriften zu entsprechen, z. B. im Bereich der Rechnungslegung
(Rechnungslegungsvorschriften und Finanzstandards), Anforderungen an die Arbeitssicherheit (für
kritische Systeme) und andere Aspekte.

Bedeutung der Klassifizierung nicht-funktionaler Anforderungen

Eine unvollständige oder ungenaue Spezifikation der nichtfunktionalen Anforderungen kann zum
Scheitern Ihres Softwareentwicklungsprojekts führen.

Nicht funktionale Anforderungen nicht zu verwalten, ist einer derklassischen Fehler im

Softwareentwicklungsmanagement, wie er von Steve McConnell definiert wurde.

Die ordnungsgemäße Klassifizierung der einzelnen ermittelten nichtfunktionalen Anforderungen ist

sehr wichtig, um diesen Prozess zu gewährleisten.

https://www.youtube.com/user/codigofacilito
https://www.youtube.com/channel/UC4CEqh4d3-6RcyyJxhFCMGg
https://marvelapp.com/.