Anforderungsanalyse

Im Systemtechnik und Softwareentwicklung, Anforderungsanalyse Konzentriert sich auf die Aufgaben, die die Bedürfnisse oder Bedingungen für das neue oder veränderte Produkt oder Projekt ermitteln und die möglicherweise widersprüchlichen Berücksichtigung berücksichtigen Bedarf der verschiedenen Stakeholder, Analyse, Dokumentation, Validierung und Verwaltung Software- oder Systemanforderungen.^[2]

Die Anforderungenanalyse ist entscheidend für den Erfolg oder Misserfolg eines Systems oder Softwareprojekt.^[3] Die Anforderungen sollten dokumentiert, umsetzbar, messbar, überprüfbar, nachvollziehbar, im Zusammenhang mit identifizierten Geschäftsbedürfnissen oder -chancen und auf ein Detailgenauigkeit definiert werden, das für die Systemdesign ausreicht.

Überblick

Konzeptionell umfasst die Analyseanalyse drei Arten von Aktivitäten:

• Anforderungen ermitteln: (z. B. die Projektcharta oder Definition), Geschäftsprozessdokumentation und Interviews von Stakeholder. Dies wird manchmal auch als Anforderungen als Sammel- oder Anforderungsentdeckung bezeichnet.
• Aufzeichnungsanforderungen: Die Anforderungen können in verschiedenen Formularen dokumentiert werden, in der Regel eine Zusammenfassungsliste und enthalten natürliche Dokumente. Anwendungsfälle, benutzergeschichten, Prozessspezifikationen und eine Vielzahl von Modellen, einschließlich Datenmodellen.
• Analyse der Anforderungen: Bestimmen Sie, ob die angegebenen Anforderungen klar, vollständig, unauslösend, prägnant, gültig, konsistent und eindeutig sind und offensichtliche Konflikte lösen. Die Analyse kann auch Größenanforderungen umfassen.

Die Anforderungenanalyse kann ein langer und anstrengender Prozess sein, bei dem viele heikle psychologische Fähigkeiten beteiligt sind. Neue Systeme verändern die Umwelt und die Beziehungen zwischen Menschen. Daher ist es wichtig, alle Stakeholder zu identifizieren, alle ihre Bedürfnisse zu berücksichtigen und sicherzustellen, dass sie die Auswirkungen der neuen Systeme verstehen. Analysten können verschiedene Techniken anwenden, um die Anforderungen des Kunden zu ermitteln. Dies kann die Entwicklung von Szenarien umfassen (dargestellt als benutzergeschichten in Agile Methoden) die Identifizierung von Anwendungsfälle, die Verwendung der Beobachtung am Arbeitsplatz oder Ethnographie, Holding Interviews, oder Schwerpunktgruppen (In diesem Zusammenhang treffender als Anforderungsworkshops oder Anforderungen überprüft) und Anforderungen zu erstellen. Prototyp entwickeln kann verwendet werden, um ein Beispielsystem zu entwickeln, das den Stakeholdern demonstriert werden kann. Nach Bedarf wird der Analyst eine Kombination dieser Methoden anwenden, um die genauen Anforderungen der Stakeholder zu ermitteln, so dass ein System, das den Geschäftsanforderungen entspricht, erzeugt wird. Die Qualitätsqualität kann durch diese und andere Methoden verbessert werden

• Visualisierung. Verwenden von Tools, die ein besseres Verständnis des gewünschten Endprodukts wie Visualisierung und Simulation fördern.
• Konsistente Verwendung von Vorlagen. Erstellen eines konsistenten Satzes von Modellen und Vorlagen, um die Anforderungen zu dokumentieren.
• Dokumentation Abhängigkeiten. Dokumentieren von Abhängigkeiten und Wechselbeziehungen zwischen Anforderungen sowie Annahmen und Gemeinden.

Anforderungen Analyse Themen

Identifizierung der Stakeholder

Sehen Stakeholder -Analyse Für eine Diskussion von Personen oder Organisationen (juristische Personen wie Unternehmen, Standards), die ein gültiges Interesse am System haben. Sie können entweder direkt oder indirekt davon betroffen sein. Ein großer neuer Schwerpunkt in den neunziger Jahren war ein Fokus auf die Identifizierung von Stakeholder. Es wird zunehmend anerkannt, dass die Stakeholder nicht auf die Organisation beschränkt sind, die den Analysten einsetzt. Andere Stakeholder umfassen:

• Jeder, der das System betreibt (Normal- und Wartungsbetreiber)
• Jeder, der vom System profitiert (funktionale, politische, finanzielle und soziale Begünstigte)
• Jeder, der am Kauf oder Beschaffung des Systems beteiligt ist. In einer Produktorganisation in Massenmarkt wirken Produktmanagement, Marketing und manchmal Vertrieb als Ersatzverbraucher (Massenmarktkunden), um die Entwicklung des Produkts zu leiten.
• Organisationen, die Aspekte des Systems regulieren (finanzielle, Sicherheit und andere Aufsichtsbehörden)
• Menschen oder Organisationen gegen das System (negative Stakeholder; siehe auch Missbrauchsfall)
• Organisationen, die für Systeme verantwortlich sind, die mit dem System unter dem Design verknüpfen.
• jene Organisationen, die horizontal integrieren mit der Organisation, für die der Analyst das System entwirft.

JRD -Sitzungen (Joint Requirement Development)

Anforderungen haben häufig funktionsübergreifende Implikationen, die einzelne Stakeholder unbekannt sind und während der Interviews von Stakeholdern häufig verpasst oder unvollständig definiert wurden. Diese funktionsübergreifenden Implikationen können durch Durchführung von JRD-Sitzungen in einer kontrollierten Umgebung hervorgerufen werden, die durch einen geschulten erleichtert werden Moderator (Business Analyst), wobei die Stakeholder an Diskussionen teilnehmen, um Anforderungen zu ermitteln, ihre Details zu analysieren und funktionsübergreifende Auswirkungen aufzudecken. Ein dedizierter Schreiber sollte vorhanden sein, um die Diskussion zu dokumentieren und den Geschäftsanalysten zu befreien, die Diskussion in eine Richtung zu führen, die geeignete Anforderungen erzeugt, die das Sitzungsziel entsprechen.

JRD -Sitzungen sind analog zu Gemeinsames Anwendungsdesign Sitzungen. Im ersteren erläutern die Sitzungen Anforderungen, die das Design leiten, während letztere die spezifischen Entwurfsmerkmale auslösen, die zur Zufriedenheit der ausgelösten Anforderungen implementiert werden sollen.

Anforderungen im Vertragsstil

Eine traditionelle Methode zur Dokumentation von Anforderungen waren Vertragsstil -Anforderungslisten. In einem komplexen System können solche Anforderungen auf Hunderte von Seiten lang laufen.

Eine angemessene Metapher wäre eine extrem lange Einkaufsliste. Solche Listen sind in der modernen Analyse sehr besorgniserregend. wie sie sich als spektakulär erfolglos erwiesen haben, um ihre Ziele zu erreichen; Aber sie sind bis heute zu sehen.

Stärken

• Bietet eine Checkliste der Anforderungen.
• Stellen Sie einen Vertrag zwischen den Projektsponsor und Entwicklern vor.
• Für ein großes System kann eine hohe Beschreibung bereitgestellt werden, von der von niedrigeren Anforderungen abgeleitet werden können.

Schwächen

• Solche Listen können auf Hunderte von Seiten laufen. Sie sollen nicht als leserfreundliche Beschreibung der gewünschten Anwendung dienen.
• Solche Anforderungen listen alle Anforderungen ab und so gibt es wenig Kontext. Der Business Analyst kann einen Kontext für Anforderungen in der begleitenden Entwurfsdokumentation enthalten.
  • Diese Abstraktion soll nicht beschreiben, wie die Anforderungen zusammenpassen oder zusammenarbeiten.
  • Die Liste spiegelt möglicherweise keine Beziehungen und Abhängigkeiten zwischen den Anforderungen wider. Während eine Liste die Priorisierung jedes einzelnen Elements erleichtert, kann das Entfernen eines Elements aus dem Kontext einen gesamten Anwendungsfall oder die Geschäftsanforderung unbrauchbar machen.
  • Die Liste ersetzt nicht Die Notwendigkeit, die Anforderungen sorgfältig mit den Stakeholdern zu überprüfen, um ein besseres gemeinsames Verständnis der Auswirkungen auf die Gestaltung des gewünschten Systems / die gewünschte Anwendung zu erhalten.
• Das einfache Erstellen einer Liste garantiert nicht ihre Vollständigkeit. Der Business Analyst muss sich nach Treu und Glauben bemühen, eine wesentlich umfassende Liste zu entdecken und zu sammeln und sich auf die Stakeholder zu verlassen, um fehlende Anforderungen zu ermitteln.
• Diese Listen können ein falsches Gefühl des gegenseitigen Verständnisses zwischen den Stakeholdern und Entwicklern erzeugen. Geschäftsanalysten sind für den Übersetzungsprozess von entscheidender Bedeutung.
• Es ist fast unmöglich, alle funktionalen Anforderungen aufzudecken, bevor der Entwicklungs- und Testprozess beginnt. Wenn diese Listen behandelt werden Als unveränderlichen Vertrag können dann Anforderungen, die im Entwicklungsprozess entstehen, zu einer kontroversen Änderungsanforderung.

Alternative zu den Anforderungslisten

Als Alternative zu Anforderungslisten, Agile Software Entwicklung Verwendet Benutzergeschichten Anforderungen in der Alltagssprache vorzuschlagen.

Messbare Ziele

Best Practices nehmen die komponierte Liste der Anforderungen lediglich als Hinweise und fragen wiederholt "Warum?" Bis die tatsächlichen Geschäftszwecke entdeckt werden. Stakeholder und Entwickler können dann Tests entwickeln, um zu messen, welches Niveau jedes Ziels bisher erreicht hat. Solche Ziele ändern sich langsamer als die lange Liste der spezifischen, aber nicht gemessenen Anforderungen. Sobald eine kleine Reihe kritischer, gemessener Ziele festgelegt wurden, Rapid-Prototyping und kurze iterative Entwicklungsphasen können lange vor der Hälfte des Projekts den tatsächlichen Wert der Stakeholder liefern.

Prototypen

Ein Prototyp ist ein Computerprogramm, das einen Teil der Eigenschaften eines anderen Computerprogramms aufweist, sodass Benutzer eine noch nicht konstruierte Anwendung visualisieren können. Eine beliebte Form des Prototyps ist a Attrappe, Lehrmodell, Simulation, was zukünftigen Benutzern und anderen Stakeholdern hilft, eine Vorstellung davon zu bekommen, wie das System aussehen wird. Prototypen erleichtern es einfacher, Entwurfsentscheidungen zu treffen, da Aspekte der Anwendung vor dem Erstellen der Anwendung gesehen und gemeinsam genutzt werden können. Bei der Einführung von Prototypen wurden häufig wichtige Verbesserungen der Kommunikation zwischen Benutzern und Entwicklern beobachtet. Frühe Ansichten von Anwendungen führten später zu weniger Änderungen und senkt daher erheblich die Gesamtkosten.

Prototypen können flache Diagramme sein (oft als als bezeichnet als Wireframes) oder Arbeitsanwendungen mit synthetisierter Funktionalität. Wireframes werden in einer Vielzahl von Grafikdesigndokumenten hergestellt und entfernen häufig alle Farbe aus dem Design (d. H. Verwenden Grafikdesign darauf angewendet. Dies hilft, Verwirrung zu verhindern, ob der Prototyp das endgültige visuelle Erscheinungsbild der Anwendung darstellt.

Anwendungsfälle

Ein Anwendungsfall ist eine Struktur zum Dokumentieren der funktionalen Anforderungen für ein System, die normalerweise Software betreffen, unabhängig davon, ob dies neu ist oder geändert wird. Jeder Anwendungsfall bietet einen Satz von Szenarien Dies vermittelt, wie das System mit einem menschlichen Benutzer oder einem anderen System interagieren sollte, um ein bestimmtes Geschäftsziel zu erreichen. Anwendungsfälle vermeiden technische Jargon in der Regel und bevorzugen stattdessen die Sprache der Endbenutzer oder Domain -Experte. Anwendungsfälle werden häufig von Anforderungsingenieuren und Stakeholdern mitautorisiert.

Anwendungsfälle sind täuschend einfache Tools zur Beschreibung des Verhaltens von Software oder Systemen. Ein Anwendungsfall enthält eine Textbeschreibung der Art und Weise, wie Benutzer mit der Software oder dem System arbeiten sollen. Anwendungsfälle sollten weder interne Arbeiten des Systems beschreiben und auch nicht erklären, wie dieses System implementiert wird. Stattdessen zeigen sie die Schritte, die erforderlich sind, um eine Aufgabe ohne sequentielle Annahmen auszuführen.

Anforderungsspezifikation

Die Anforderungenspezifikation ist die Synthese von Entdeckungsbeeten zu den aktuellen Geschäftsbedürfnissen des Bundesstaates und die Bewertung dieser Bedürfnisse zur Bestimmung und Angabe, was erforderlich ist, um die Bedürfnisse innerhalb des Fokusbereichs des Lösungsbereichs zu erfüllen. Entdeckung, Analyse und Spezifikation verschieben das Verständnis von einem aktuellen Zustand in einem zukünftigen zukünftigen Staat. Die Anforderungenspezifikation kann die volle Breite und Tiefe des zukünftigen Zustands abdecken, oder es kann sich um bestimmte Lücken handeln, die zu füllen sind, z. B. Priority -Software -Systemfehler, um zu reparieren und zu verbessern. Angesichts der Tatsache, dass jeder große Geschäftsprozess fast immer Software- und Datensysteme und -technologien verwendet, wird häufig mit Softwaresystem -Builds, Einkäufen, Cloud -Computing -Strategien, eingebetteter Software in Produkten oder Geräten oder anderen Technologien verbunden. Die breitere Definition der Anforderungsspezifikation umfasst oder konzentriert sich auf Lösungsstrategie oder -komponente wie Schulungen, Dokumentationsführer, Personal, Marketingstrategien, Geräte, Vorräte usw.

Arten von Anforderungen

Anforderungen sind kategorisiert In vielen Wegen. Das Folgende sind häufig Kategorisierungen von Anforderungen, die sich auf das technische Management beziehen:^[1]

Geschäftsanforderungen

Aussagen der Ziele der Geschäftsebene, ohne Bezug auf detaillierte Funktionen. Dies sind in der Regel hochstufige (Software- und/oder Hardware-) Funktionen, die zur Erzielung eines Geschäftsergebnisses erforderlich sind.

Kundenanforderungen

Tatsachenaussagen und Annahmen, die die Erwartungen des Systems in Bezug auf Missionsziele, Umwelt, Einschränkungen und Wirksamkeit und Eignung (MOE/MOS) definieren. Die Kunden sind diejenigen, die die acht Hauptfunktionen von Systemtechnik ausführen, wobei der Betreiber als Hauptkunde liegt. Die betrieblichen Anforderungen definieren die Grundbedürfnisse und beantworten zumindest die in der folgenden Auflistung gestellten Fragen:^[1]

• Betriebsverteilung oder Bereitstellung: Wo wird das System verwendet?
• Missionsprofil oder Szenario: Wie wird das System sein Missionsziel erreichen?
• Leistung und verwandte Parameter: Was sind die kritischen Systemparameter, um die Mission zu erfüllen?
• Nutzungsumgebungen: Wie sollen die verschiedenen Systemkomponenten verwendet werden?
• Effektivitätsanforderungen: Wie effektiv oder effizient muss das System bei der Ausführung seiner Mission sein?
• Betriebslebenszyklus: Wie lange wird das System vom Benutzer verwendet?
• Umfeld: In welchen Umgebungen wird von dem System erwartet, dass sie effektiv betrieben werden?

Architektonische Anforderungen

Die architektonischen Anforderungen erläutern, was zu tun ist, indem die erforderlichen Identifizierung ermittelt werden muss Systemarchitektur von a System.

Strukturelle Anforderungen

Die strukturellen Anforderungen erläutern, was zu tun ist, indem die erforderlichen Identifizierung ermittelt wird Struktur eines Systems.

Verhaltensanforderungen

Verhaltensanforderungen erläutern, was zu tun ist, indem die erforderlichen Identifizierung ermittelt wird Verhalten eines Systems.

Funktionale Anforderungen

Funktionale Anforderungen Erklären Sie, was getan werden muss, indem Sie die erforderliche Aufgabe, Aktion oder Aktivität identifizieren, die erledigt werden müssen. Die Analyse der Funktionsanforderungen wird als Toplevel -Funktionen für die Funktionsanalyse verwendet.^[1]

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen sind Anforderungen, die Kriterien festlegen, die zur Beurteilung des Betriebs eines Systems verwendet werden können, anstatt bestimmte Verhaltensweisen.

Leistungsanforderungen

Das Ausmaß, in dem eine Mission oder Funktion ausgeführt werden muss; im Allgemeinen gemessen in Bezug auf Quantität, Qualität, Abdeckung, Aktualität oder Bereitschaft. Während der Anforderungenanalyse wird die Leistung (wie gut es erfolgt) Anforderungen an alle identifizierten Funktionen, die auf Systemlebenszyklusfaktoren basieren, interaktiv entwickelt. und charakterisiert in Bezug auf den Grad der Sicherheit in ihrer Schätzung, den Grad der Kritikalität für den Systemerfolg und ihre Beziehung zu anderen Anforderungen.^[1]

Entwurfsanforderungen

Das "Build to", "Code to" und "Buy to" -Anforderungen für Produkte und "Wie erledigt" Anforderungen für Prozesse, die in technischen Datenpaketen und technischen Handbüchern ausgedrückt werden.^[1]

Abgeleitete Anforderungen

Anforderungen, die von den Anforderungen auf höherer Ebene impliziert oder transformiert werden. Beispielsweise kann eine Voraussetzung für eine große Reichweite oder hohe Geschwindigkeit zu einem Entwurfsbedarf für geringes Gewicht führen.^[1]

Anforderungen zugewiesen

Eine Anforderung, die durch Teilen oder anderweitig eine hohe Anforderung in mehrere Anforderungen auf niedrigerer Ebene eingerichtet oder anderweitig zugewiesen wird. Beispiel: Ein 100-Pfund-Element, das aus zwei Subsystemen besteht, kann zu Gewichtsanforderungen von 70 Pfund und 30 Pfund für die beiden Elemente auf niedrigerer Ebene führen.^[1]

Bekannte Anforderungen Kategorisierungsmodelle umfassen Furps und Furps+, entwickelt bei Hewlett Packard.

Anforderungsanalysefragen

Stakeholder -Probleme

Steve McConnell in seinem Buch Schnelle Entwicklung, Details auf eine Reihe von Möglichkeiten, wie Benutzer die Anforderungen erfassen können:

• Benutzer verstehen nicht, was sie wollen, oder Benutzer haben keine klare Vorstellung von ihren Anforderungen
• Benutzer verpflichten sich nicht zu einer Reihe schriftlicher Anforderungen
• Benutzer bestehen auf neuen Anforderungen, nachdem die Kosten und der Zeitplan festgelegt wurden
• Die Kommunikation mit den Benutzern ist langsam
• Benutzer nehmen häufig nicht an Bewertungen teil oder sind dazu nicht in der Lage
• Benutzer sind technisch unkompliziert
• Benutzer verstehen den Entwicklungsprozess nicht
• Benutzer wissen nicht über die gegenwärtige Technologie

Dies kann zu der Situation führen, in der sich die Benutzeranforderungen auch dann ändern, selbst wenn System- oder Produktentwicklung gestartet wurde.

Ingenieur/Entwicklerprobleme

Mögliche Probleme, die durch Ingenieure und Entwickler während der Anforderungen verursacht werden, sind:

• Eine natürliche Neigung zum Schreiben von Code kann zu einer Implementierung führen, bevor die Anforderungen abgeschlossen ist, was möglicherweise zu Codeänderungen führt, um die tatsächlichen Anforderungen zu erfüllen, sobald sie bekannt sind.
• Technisches Personal und Endbenutzer haben möglicherweise unterschiedliche Vokabeln. Infolgedessen können sie fälschlicherweise glauben, dass sie perfekt zustimmen, bis das fertige Produkt geliefert wird.
• Ingenieure und Entwickler können versuchen, die Anforderungen zu einem vorhandenen System oder Modell zu erfüllen, anstatt ein System zu entwickeln, das für die Anforderungen des Kunden spezifisch ist.

Versuchte Lösungen

Eine versuchte Lösung für Kommunikationsprobleme bestand darin, Spezialisten für Unternehmens- oder Systemanalysen zu beschäftigen.

Techniken, die in den 1990er Jahren eingeführt wurden wie Prototyp entwickeln, Einheitliche Modellierungssprache (Uml), Anwendungsfälle, und Agile Software Entwicklung sind auch als Lösungen für Probleme mit früheren Methoden gedacht.

Auch eine neue Klasse von Anwendungssimulation oder Tools für Anwendungsdefinition sind in den Markt eingegeben. Diese Tools sind so konzipiert, dass die Kommunikationslücke zwischen Geschäftsnutzern und der IT -Organisation überbrückt und auch die Anwendungen ermöglicht, „Test vermarktet“ zu werden, bevor ein Code erstellt wird. Das Beste dieser Tools bietet:

• Elektronische Whiteboards Anwendungsströme skizzieren und Alternativen testen
• Fähigkeit, Geschäftslogik und Datenbedürfnisse zu erfassen
• Fähigkeit, Hochtreue -Prototypen zu erzeugen, die die endgültige Anwendung genau imitieren
• Interaktivität
• Fähigkeit, kontextbezogene Anforderungen und andere Kommentare hinzuzufügen
• Fähigkeit für Fernbedienung und verteilte Benutzer, mit der Simulation auszuführen und zu interagieren

Siehe auch

Verweise

Literaturverzeichnis

Externe Links

• Peer-Review Encyclopedia -Eintrag in Anforderungstechnik und Analyse
• Verteidigungsakquisition Universität Verfahren zur Definition von Stakeholder -Anforderungen^{[Dead Link]}---Verfahren zur Definition von Stakeholder -Anforderungen Bei der Wayback -Maschine (Archiviert 23. Dezember 2015)
• MIL-HDBK 520 Systemanforderungen Dokumente Anleitung