Geschäftsanalyse - Kurzanleitung

Was ist Geschäftsanalyse?

Geschäftsanalyse ist eine Reihe von Aufgaben, Kenntnissen und Techniken, die erforderlich sind, um Geschäftsanforderungen zu identifizieren und Lösungen für geschäftliche Probleme von Unternehmen zu ermitteln. Obwohl die allgemeine Definition ähnlich ist, können die Praktiken und Verfahren in verschiedenen Branchen variieren.

In der Informationstechnologiebranche enthalten Lösungen häufig eine Systementwicklungskomponente, können aber auch aus Prozessverbesserungen oder organisatorischen Änderungen bestehen.

Geschäftsanalysen können auch durchgeführt werden, um den aktuellen Status einer Organisation zu verstehen oder um als Grundlage für die Identifizierung von Geschäftsanforderungen zu dienen. In den meisten Fällen wird jedoch eine Geschäftsanalyse durchgeführt, um Lösungen zu definieren und zu validieren, die den Geschäftsanforderungen, -zielen oder -zielen entsprechen.

Wer ist ein Business Analyst?

Ein Business Analyst ist jemand, der eine Organisation oder einen Geschäftsbereich (real oder hypothetisch) analysiert und dessen Geschäft, Prozesse oder Systeme dokumentiert, um das Geschäftsmodell oder seine Integration in die Technologie zu bewerten. Organisationstitel variieren jedoch wie Analyst, Business Analyst, Business System Analyst oder möglicherweise System Analyst.

Warum ein Business Analyst?

Unternehmen setzen Geschäftsanalysen aus folgenden Gründen ein:

  • Verständnis der Struktur und Dynamik der Organisation, in der ein System bereitgestellt werden soll.

  • Aktuelle Probleme in der Zielorganisation verstehen und Verbesserungspotenziale identifizieren.

  • Um sicherzustellen, dass Kunde, Endbenutzer und Entwickler ein gemeinsames Verständnis der Zielorganisation haben.

In der Anfangsphase eines Projekts, in der die Anforderungen von den Lösungs- und Designteams interpretiert werden, besteht die Rolle eines Geschäftsanalysten darin, die Lösungsdokumente zu überprüfen und eng mit den Lösungsdesignern (IT-Team) und Projektmanagern zusammenzuarbeiten, um dies sicherzustellen Anforderungen sind klar.

In einer typischen großen IT-Organisation, insbesondere in einer Entwicklungsumgebung, finden Sie sowohl On-Site- als auch Offshore-Bereitstellungsteams mit den oben genannten Rollen. Sie finden einen „Business Analyst“, der als Schlüsselperson fungiert und beide Teams verbinden muss.

Manchmal interagierte er mit Geschäftsbenutzern und manchmal technischen Benutzern und schließlich mit allen Beteiligten in den Projekten, um die Genehmigung und das endgültige Nicken zu erhalten, bevor er mit der Dokumentation fortfuhr.

Daher ist die Rolle des BA für den effektiven und erfolgreichen Start eines Projekts von entscheidender Bedeutung.

Rolle eines IT Business Analyst

Die Rolle eines Geschäftsanalysten beginnt mit der Definition und Festlegung der Geschäftsbereiche des Unternehmens, der Ermittlung der Anforderungen, der Analyse und Dokumentation der Anforderungen, der Übermittlung dieser Anforderungen an die entsprechenden Stakeholder, der Ermittlung der richtigen Lösung und der anschließenden Validierung der Lösung, um festzustellen, ob die Anforderungen erfüllen die erwarteten Standards.

Wie unterscheidet es sich von anderen Berufen?

Die Geschäftsanalyse unterscheidet sich von der Finanzanalyse, dem Projektmanagement, der Qualitätssicherung, der Organisationsentwicklung, dem Testen, der Schulung und der Dokumentationsentwicklung. Abhängig von der Organisation kann ein Business Analyst jedoch einige oder alle dieser verwandten Funktionen ausführen.

Geschäftsanalysten, die ausschließlich an der Entwicklung von Softwaresystemen arbeiten, können als IT-Geschäftsanalysten, technische Geschäftsanalysten, Online-Geschäftsanalysten, Geschäftssystemanalysten oder Systemanalysten bezeichnet werden.

Die Geschäftsanalyse umfasst auch die Zusammenarbeit zwischen Stakeholdern, Entwicklungsteams, Testteams usw.

Lebenszyklus der Softwareentwicklung

Der Software Development Life Cycle (SDLC) ist ein Prozess, der in einem Softwareprojekt innerhalb einer Softwareorganisation durchgeführt wird. Es besteht aus einem detaillierten Plan, der beschreibt, wie bestimmte Software entwickelt, gewartet, ersetzt und geändert oder verbessert wird. Es definiert eine Methodik zur Verbesserung der Qualität von Software und des gesamten Entwicklungsprozesses.

  • SDLC ist ein Prozess, der von IT-Analysten verwendet wird, um ein qualitativ hochwertiges Softwaresystem zu entwickeln oder neu zu gestalten, das sowohl den Kunden- als auch den realen Anforderungen entspricht.

  • Es berücksichtigt alle damit verbundenen Aspekte des Softwaretests, der Analyse und der Wartung nach dem Prozess.

Die wichtigen Phasen der SDLC sind in der folgenden Abbildung dargestellt:

Planung

Jede Aktivität muss mit einem Plan beginnen. Zu versagen zu planen ist planen zu versagen. Der Planungsgrad ist von Modell zu Modell unterschiedlich, aber es ist sehr wichtig, ein klares Verständnis dafür zu haben, was wir durch die Erstellung der Systemspezifikationen erstellen werden.

Bühne definieren

In dieser Phase analysieren und definieren wir die Systemstruktur. Wir definieren die Architektur, die Komponenten und wie diese Komponenten zusammenpassen, um ein funktionierendes System zu erzeugen.

Bühne gestalten

Beim Systemdesign werden die Designfunktionen und -vorgänge ausführlich beschrieben, einschließlich Bildschirmlayouts, Geschäftsregeln, Prozessdiagrammen und anderer Dokumentation. Die Ausgabe dieser Stufe beschreibt das neue System als eine Sammlung von Modulen oder Subsystemen.

Bauphase

Dies ist die Entwicklungsphase. Wir beginnen die Codegenerierung basierend auf dem Systemdesign mit Compilern, Interpreten und Debuggern, um das System zum Leben zu erwecken.

Implementierung

Die Implementierung ist Teil der Bauphase. In dieser Phase beginnen wir mit der Codegenerierung basierend auf dem Systemdesign unter Verwendung von Compilern, Interpretern und Debuggern, um das System zum Leben zu erwecken.

Testphase

Da verschiedene Teile des Systems abgeschlossen sind; Sie werden einer Reihe von Tests unterzogen. Es wird anhand der Anforderungen getestet, um sicherzustellen, dass das Produkt tatsächlich die in der Anforderungsphase angesprochenen Anforderungen erfüllt.

  • Testpläne und Testfälle werden verwendet, um Fehler zu identifizieren und sicherzustellen, dass das System gemäß den Spezifikationen funktioniert.

  • In dieser Phase werden verschiedene Arten von Tests wie Unit-Tests, manuelle Tests, Abnahmetests und Systemtests durchgeführt.

Fehlerverfolgung beim Testen

Software-Testberichte werden verwendet, um die Ergebnisse der ausgeführten Testpläne zu kommunizieren. In diesem Fall sollte ein Bericht alle Testinformationen enthalten, die sich auf das aktuell getestete System beziehen. Die Vollständigkeit der Berichte wird in exemplarischen Sitzungen überprüft.

Das Testen für ein Projekt zielt darauf ab, zwei Hauptziele zu erreichen -

  • Erkennen Sie Fehler und Defekte im System.

  • Erkennen Sie Inkonsistenzen zwischen Anforderungen und Implementierung.

Das folgende Flussdiagramm zeigt die Defect Tracking Process - -

Um die Hauptziele zu erreichen, besteht die Teststrategie für das vorgeschlagene System normalerweise aus vier Teststufen.

Dies sind Unit-Tests, Integrationstests, Abnahmetests und Regressionstests. In den folgenden Unterabschnitten werden diese Teststufen beschrieben, für deren Entwicklung und Ausführung die Rollen des Entwicklungsteams verantwortlich sind, sowie Kriterien für die Bestimmung ihrer Vollständigkeit.

Einsatz

Nach Beendigung der Testphase wird das System freigegeben und tritt in die Produktionsumgebung ein. Sobald das Produkt getestet und einsatzbereit ist, wird es offiziell auf dem entsprechenden Markt veröffentlicht. Manchmal erfolgt die Produktbereitstellung schrittweise gemäß der Geschäftsstrategie des Unternehmens.

Das Produkt kann zunächst in einem begrenzten Segment veröffentlicht und in der realen Geschäftsumgebung getestet werden (UAT-User Acceptance Testing). Basierend auf dem Feedback kann das Produkt dann unverändert oder mit vorgeschlagenen Verbesserungen im Zielmarktsegment veröffentlicht werden.

Post-SDLC-Prozess

Nachdem das Produkt auf den Markt gebracht wurde, erfolgt die Wartung für den bestehenden Kundenstamm.

In der Produktionsumgebung wird das System aufgrund nicht erkannter Fehler oder anderer unerwarteter Ereignisse geändert. Das System wird ausgewertet und der Zyklus zur Wartung des Systems wiederholt.

Rolle des Business Analyst während des SDLC-Prozesses

Wie das folgende Diagramm zeigt, ist BA daran beteiligt, die Geschäftsanforderungen voranzutreiben und sie in Lösungsanforderungen umzuwandeln.

Er ist an der Umsetzung der Lösungsfunktionen in Softwareanforderungen beteiligt. Führt dann in der Analyse- und Entwurfsphase, diktiert in der Codeentwicklung, folgt dann der Testphase während der Fehlerbehebung als Change Agent im Projektteam und erfüllt letztendlich die Kundenanforderungen.

Geschäftsanalyse - Rollen

Die Rolle eines Business Analyst in einem IT-Projekt kann vielfältig sein. Projektteammitglieder können mehrere Rollen und Verantwortlichkeiten haben. In einigen Projekten kann der BA die Rollen des Business Intelligence Analyst, des Datenbankdesigners, des Spezialisten für Softwarequalitätssicherung, des Testers und / oder des Trainers übernehmen, wenn nur begrenzte Ressourcen verfügbar sind.

Es ist auch möglich, dass ein Projektkoordinator, ein Leiter der Anwendungsentwicklung oder ein Entwickler die Rolle des Business Analyst in bestimmten Projekten übernimmt.

Die Geschäftsanalyse überschneidet sich stark mit der Analyse der Anforderungen des Geschäfts, um wie gewohnt zu funktionieren und ihre Funktionsweise zu optimieren. Einige Beispiele für Geschäftsanalysen sind -

  • Geschäftsarchitektur erstellen
  • Business Case vorbereiten
  • Durchführung einer Risikobewertung
  • Anforderungserhebung
  • Geschäftsprozessanalyse
  • Dokumentation der Anforderungen

Hauptrollen eines BA

Eine Schlüsselrolle der meisten Geschäftsanalysten ist die Verbindung zwischen dem Geschäft und den technischen Entwicklern. Geschäftsanalysten arbeiten mit den Geschäftskunden zusammen, um die Anforderungen eines Systems oder Prozesses zu erfassen / zu definieren, um die Produktivität zu verbessern, und arbeiten gleichzeitig mit den technischen Teams zusammen, um das System / den Prozess zu entwerfen und zu implementieren.

Als Mitwirkender

Die Hauptverantwortung eines BA besteht darin, zur Entwicklung von Geschäftsbenutzern / Hauptbenutzern bei der Identifizierung von Geschäftsproblemen, -bedürfnissen und -funktionen beizutragen, die Anliegen und Anforderungen der Stakeholder zu verstehen, um Verbesserungsmöglichkeiten zu identifizieren, und geschäftliche Beiträge zur Entwicklung des Geschäftsmodells für die IT beizutragen Systementwicklungsprojekt.

Als Moderator

Ein Business Analyst soll auch die Ermittlung und Analyse von Anforderungen, die Zusammenarbeit und Kommunikation mit Stakeholdern erleichtern / koordinieren sowie deren Erwartungen und Bedürfnisse verwalten und sicherstellen, dass die Anforderungen vollständig und eindeutig sind und sie den Geschäftsanforderungen in Echtzeit zuordnen einer Organisation.

Als Analyst

Eine weitere wichtige Rolle wäre die Bewertung der vorgeschlagenen System- und Organisationsbereitschaft für die Systemimplementierung sowie die Unterstützung der Benutzer und die Koordinierung mit den IT-Mitarbeitern.

Unterstützung bei der Überprüfung und Bereitstellung von Inputs für das Design des vorgeschlagenen IT-Systems aus geschäftlicher Sicht, Lösung von Problemen / Konflikten zwischen Stakeholdern, Unterstützung bei der Organisation einer umfassenden und qualitativ hochwertigen UAT durch Unterstützung der Benutzer bei der Entwicklung von Testfällen und Unterstützung bei der Organisation von Schulungen mit dem Ziel, die Sicherheit zu gewährleisten Einsatz eines IT-Systems, das in der Lage ist, geschäftliche Anforderungen und Anforderungen zu erfüllen und die erwarteten Vorteile zu realisieren.

Planung und Überwachung der Geschäftsanalyseaktivitäten für die Umfangsentwicklung, Zeitplan und Ansatz für die Durchführung der Aktivitäten im Zusammenhang mit der Geschäftsanalyse für das IT-Systementwicklungsprojekt, Überwachung des Fortschritts, Koordinierung mit dem internen Projektmanager und Berichterstattung über Umsatz, Rentabilität, Risiken und Probleme, wo immer angemessen.

Hauptverantwortung eines Business Analyst

Die Verantwortung eines Geschäftsanalysten würde erfordern, dass er in verschiedenen Phasen eines Projekts unterschiedliche Aufgaben erfüllt, und diese werden im Folgenden erläutert.

Initiationsphase

Diese Phase markiert den Beginn eines neuen Projekts und ein Geschäftsanalyst wird die folgenden Verantwortlichkeiten variieren:

  • Unterstützung bei der Durchführung der Kosten-Nutzen-Analyse des Projekts.
  • Verstehen Sie den Business Case.
  • Überprüfen Sie die Machbarkeit der Lösung / des Projekts / des Produkts.
  • Hilfe bei der Erstellung der Projektcharta.
  • Identifizieren Sie die Stakeholder im Projekt.

Planungsphase

In dieser Phase werden die Anforderungen gesammelt und geplant, wie das Projekt ausgeführt und verwaltet wird. Zu seinen Aufgaben gehören die folgenden Funktionen:

  • Ermittlung der Anforderungen
  • Anforderungen analysieren, organisieren und dokumentieren.
  • Verwalten Sie Anforderungen, indem Sie Anwendungsfälle, RTM, BRD, SRS usw. erstellen.
  • Bewerten Sie die vorgeschlagenen Lösungen.
  • Kontaktaufnahme und Verbesserung der Kommunikation mit Stakeholdern.
  • Unterstützung bei der Formulierung der Projektmanagementpläne.
  • Hilfe bei der Ermittlung des Projektumfangs, der Einschränkungen, Annahmen und Risiken.
  • Unterstützung beim Entwerfen der Benutzererfahrung der Lösung.

Ausführungsphase

Diese Phase markiert die Entwicklung der Lösung gemäß den gesammelten Anforderungen. Die Verantwortlichkeiten umfassen -

  • Erklären Sie dem IT- / Entwicklungsteam die Anforderungen.

  • Klären Sie Zweifel und Bedenken hinsichtlich der vorgeschlagenen Lösung, die entwickelt werden soll.

  • Diskutieren und priorisieren Sie Änderungen des Projektumfangs und erzielen Sie eine Einigung.

  • Erstellen Sie Betatestskripte für den ersten Test.

  • Teilen Sie die Entwicklungsmodule mit den Stakeholdern und holen Sie deren Feedback ein.

  • Termine einhalten und die Erwartungen der Stakeholder verwalten.

  • Konflikte lösen und Kommunikation mit dem Projektteam verwalten.

Überwachungs- und Kontrollphase

In dieser Phase wird das Projekt auf Abweichungen von den ursprünglichen Plänen gemessen und kontrolliert. Diese Phase läuft gleichzeitig mit der Ausführungsphase.

  • Entwicklung von Testskripten und Durchführung umfassender Modul- und Integrationstests.

  • Durchführen von UAT (Verwendung von Abnahmetests) und Erstellen von Testberichten.

  • Erhalten Sie die Annahme / Genehmigung der Leistungen vom Kunden.

  • Erklären Sie dem Entwicklungsteam die Änderungsanforderungen.

  • Überwachen Sie die Entwicklung der Änderungsanforderungen und überprüfen Sie deren Implementierung gemäß dem Projektziel.

Abschlussphase

Diese Phase markiert den Abschluss des Projekts. Die Verantwortlichkeiten sind -

  • Präsentieren Sie das abgeschlossene Projekt dem Kunden und gewinnen Sie dessen Akzeptanz.

  • Erstellen Sie Benutzerschulungshandbücher, Funktionsmaterialien und andere Anleitungen.

  • Führen Sie aufwändige Integrationstests in der Produktionsumgebung durch.

  • Erstellen Sie endgültige Produktdokumentationen und dokumentieren Sie die gewonnenen Erkenntnisse aus dem Projekt.

Was wird von einem BA erwartet?

Ein Business Analyst dient als Brücke zwischen den Geschäftsbenutzern und den technischen IT-Mitarbeitern. Ihre Präsenz wird wesentlich zum Erfolg von IT-Projekten beitragen. Ein engagierter Business Analyst bietet viele Vorteile. Ein engagierter Business Analyst kann -

  • Liefert einen klaren Projektumfang aus geschäftlicher Sicht.

  • Entwickeln Sie fundierte Business Cases und eine realistischere Einschätzung der Ressourcen und des Geschäftsnutzens.

  • Erstellt bessere Berichte über Projektumfang, Planung und Management in Bezug auf Kosten und Zeitplan, insbesondere für große IT-Projekte.

  • Erzeugt klare und präzise Anforderungen, was wiederum dazu beiträgt, klarere und genauere Anforderungen zu stellen, wenn das IT-Projekt ausgelagert wird.

  • Ermitteln Sie die tatsächlichen Geschäftsanforderungen von Benutzern und verwalten Sie die Benutzererwartungen effektiv.

  • Verbessert die Designqualität des vorgeschlagenen IT-Systems, sodass es den Benutzeranforderungen entspricht.

  • Gewährleistet die Qualität des entwickelten Systems, bevor es zur Überprüfung und Akzeptanz an die Endbenutzer weitergegeben wird.

  • Organisation eines umfassenden Qualitätstests für die gelieferten Systeme und Rückmeldung an die technischen IT-Mitarbeiter.

Geschäftsanalyse - Tools und Techniken

Ein Business Analyst sollte mit verschiedenen Analysetools und verwandten Technologien vertraut sein, wenn Sie den BA-Hut tragen. Ich meine, wenn Sie diese Position halten.

Wie wir bereits zuvor erfahren haben, ist die Geschäftsanalyse ein Prozess, bei dem Sie versuchen, ein Unternehmen zu verstehen und Chancen, Problembereiche, Probleme zu identifizieren und eine breite Palette von Personen mit unterschiedlichsten Rollen und Verantwortlichkeiten wie CEO, VP, Director und zu treffen Verständnis ihrer Geschäftsanforderungen.

Grundsätzlich gibt es drei Arten von Geschäftsanalysen, die wir in folgende Kategorien einteilen können:

  • Strategic Analysis- Die strategische Geschäftsanalyse befasst sich mit der Arbeit vor dem Projekt. Es ist die Methode oder der Prozess, um Geschäftsprobleme zu identifizieren und Geschäftsstrategien, -ziele und -ziele zu entwickeln, die dem Top-Management helfen. Es bietet Berichte zu Managementinformationen für einen effektiven Entscheidungsprozess.

  • Tactical Analysis - Es beinhaltet Kenntnisse über bestimmte Geschäftsanalysetechniken, die zum richtigen Zeitpunkt im entsprechenden Projekt angewendet werden müssen.

  • Operational Analysis- Bei dieser Art der Geschäftsanalyse konzentrieren wir uns durch den Einsatz von Informationstechnologie auf den Geschäftsaspekt. Es ist auch ein Prozess der Untersuchung von Betriebssystemen mit dem Ziel, Möglichkeiten zur Geschäftsverbesserung zu identifizieren.

Für jede Art von Analyse gibt es eine Reihe von Tools, die auf dem Markt verfügbar sind und auf der Grundlage der organisatorischen Bedürfnisse und Anforderungen verwendet werden sollen.

Um die geschäftlichen Anforderungen in verständliche Informationen umzusetzen, wird ein guter BA bei seinen täglichen Aktivitäten Techniken wie Faktenfindung, Interviews, Überprüfung der Dokumentation, Fragebögen, Stichproben und Forschung einsetzen.

Funktionale und nicht funktionale Anforderungen

Wir können eine Anforderung in zwei Haupttypen wie funktionale und nicht funktionale Anforderungen aufteilen.

Bei allen Technologieprojekten müssen funktionale und nicht funktionale Anforderungen getrennt und getrennt analysiert werden.

Das richtige Werkzeug und eine geeignete Technik zu definieren, könnte eine gewaltige Herausforderung sein. Egal, ob Sie eine brandneue Anwendung ausführen oder eine vorhandene Anwendung ändern. Die richtige Technik für den Funktionsprozess zu betrachten, ist eine Kunst für sich.

Ein Überblick über die weit verbreiteten Geschäftsanalysetechniken, die derzeit auf dem Markt sind -

Prozesse Techniken Prozessleistungen (Ergebnisse)
Ermittlung funktionaler und nicht funktionaler Anforderungen
  • JAD-Sitzungen
  • Szenarien und Anwendungsfälle
  • Organisationsmodellierung
  • Bereichsmodellierung
  • Funktionale Zersetzung
  • Interviews
  • Beobachtung (Job Shadowing)
  • Schwerpunktgruppen
  • Akzeptanz und Bewertung
  • Sequenzdiagramme
  • Benutzergeschichten
  • Brainstorming
  • Storyboarding
  • Prototyping
  • Strukturierter Durchgang
  • Ereignisanalyse
  • Analyse von Geschäftsregeln
  • Anforderungsworkshops
  • Risikoanalyse
  • Ursachenanalyse

Business Requirements Documents - -

  • Geschäfts- und Funktionsanforderungen
  • Nicht-funktionale Anforderungen
  • Geschäftsregeln
  • Anforderungsrückverfolgbarkeitsmatrix

Common Template - -

  • Geschäftsanforderungsdokument

Anwendbarkeit von Werkzeugen und Verfahren

Obwohl Geschäftsanalysten eine Vielzahl von Tools und Verfahren zur Verfügung stehen, hängt alles von den aktuellen Praktiken des Unternehmens ab und davon, wie sie es verwenden möchten.

Zum Beispiel, root-cause analysis wird verwendet, wenn es erforderlich ist, tiefer in einen bestimmten wichtigen Bereich oder eine bestimmte Funktion einzudringen.

Das Dokument mit den Geschäftsanforderungen ist jedoch die beliebteste und anerkannteste Methode, um die Anforderungen in das Dokumentationsformat zu bringen.

In den folgenden Kapiteln werden wir einige der oben genannten Techniken ausführlich diskutieren.

Geschäftsanalyse - JAD-Sitzung

Joint Application Development (JAD) ist ein Prozess, mit dem Geschäftsanforderungen erfasst und gleichzeitig neue Informationssysteme für ein Unternehmen entwickelt werden. Der JAD-Prozess kann auch Ansätze zur Verbesserung der Benutzerbeteiligung, zur Beschleunigung der Entwicklung und zur Verbesserung der Qualität von Spezifikationen umfassen. Die Absicht einer JAD-Sitzung ist es, Fachexperten / Business Analysten oder IT-Spezialisten zusammenzufassen, um Lösungen herauszubringen.

Ein Business Analyst ist derjenige, der mit der gesamten Gruppe interagiert und die Informationen sammelt, analysiert und ein Dokument herausbringt. Er spielt eine sehr wichtige Rolle in der JAD-Sitzung.

Verwendung einer JAD-Sitzung

JAD-Sitzungen sind hoch strukturierte, moderierte Workshops, in denen Kundenentscheider und IT-Mitarbeiter zusammenkommen, um in kurzer Zeit qualitativ hochwertige Ergebnisse zu erzielen.

Mit anderen Worten, eine JAD-Sitzung ermöglicht es Kunden und Entwicklern, schnell eine Einigung über den grundlegenden Umfang, die Ziele und Spezifikationen eines Projekts zu erzielen oder, falls dies nicht der Fall ist, eine Einigung zu erzielen, was bedeutet, dass das Projekt neu bewertet werden muss.

Einfach ausgedrückt, JAD-Sitzungen können

  • Simplify - Es fasst monatelange Besprechungen und Telefonanrufe in einem strukturierten Workshop zusammen.

  • Identify - Themen und Teilnehmer

  • Quantify - Informations- und Verarbeitungsbedarf

  • Clarify - Kristallisieren und klären Sie alle in der Sitzung vereinbarten Anforderungen.

  • Unify - Die Ausgabe von einer Entwicklungsphase wird in die nächste eingegeben.

  • Satisfy- Die Kunden definieren das System; deshalb ist es ihr System. Eine geteilte Teilnahme trägt zum Ergebnis bei. Sie engagieren sich für den Erfolg des Systems.

Teilnehmer an einer JAD-Sitzung

Die an einer JAD-Sitzung beteiligten Teilnehmer sind wie folgt:

Executive Sponsor

Ein Executive Sponsor ist die Person, die das Projekt steuert - der Systembesitzer. Sie kommen normalerweise aus höheren Positionen und sind in der Lage, Entscheidungen zu treffen und die notwendige Strategie, Planung und Anleitung bereitzustellen.

Fachexperten

Dies sind die Geschäftsanwender und externen Experten, die für einen erfolgreichen Workshop erforderlich sind. Die Fachexperten sind das Rückgrat der JAD-Sitzung. Sie werden die Änderungen vorantreiben.

Moderator

Er leitet die Sitzung; Er identifiziert Probleme, die im Rahmen des Meetings gelöst werden können. Der Moderator trägt keine Informationen zum Meeting bei.

Schlüsselbenutzer

Schlüsselbenutzer oder in einigen Fällen auch als Superuser bezeichnet, wurden austauschbar verwendet und unterscheiden sich immer noch von Unternehmen zu Unternehmen. Hauptbenutzer sind im Allgemeinen die Geschäftsbenutzer, die enger mit dem IT-Projekt verbunden sind und für die Konfiguration der Profile ihrer Teammitglieder während der Projekte verantwortlich sind.

Zum Beispiel: Angenommen, John ist ein Schlüsselbenutzer und Nancy, Evan sind Benutzer eines SAP-Systems. In diesem Fall haben Nancy und Evan keinen Zugriff auf die Änderung der Funktionalität und des Profils, während John als Key-Benutzer Zugriff auf die Bearbeitung von Profilen mit mehr Berechtigungen hat.

Es wird angenommen, dass der JAD-Ansatz im Vergleich zur traditionelleren Praxis zu schnelleren Entwicklungszeiten und einer höheren Kundenzufriedenheit führt, da der Kunde während des gesamten Entwicklungsprozesses involviert ist. Im Vergleich dazu untersucht der Entwickler beim traditionellen Ansatz der Systementwicklung die Systemanforderungen und entwickelt eine Anwendung, wobei die Kundeneingabe aus einer Reihe von Interviews besteht.

Anforderungserfassungstechniken

Techniken beschreiben, wie Aufgaben unter bestimmten Umständen ausgeführt werden. Eine Aufgabe kann keine oder eine oder mehrere verwandte Techniken haben. Eine Technik sollte sich auf mindestens eine Aufgabe beziehen.

Im Folgenden sind einige der bekannten Techniken zum Sammeln von Anforderungen aufgeführt:

Brainstorming

Brainstorming wird beim Sammeln von Anforderungen verwendet, um so viele Ideen wie möglich von einer Gruppe von Personen zu erhalten. Wird im Allgemeinen verwendet, um mögliche Lösungen für Probleme zu identifizieren und Details von Möglichkeiten zu klären.

Dokumentenanalyse

Das Überprüfen der Dokumentation eines vorhandenen Systems kann beim Erstellen von AS-IS-Prozessdokumenten hilfreich sein und die Lückenanalyse für den Umfang von Migrationsprojekten vorantreiben. In einer idealen Welt würden wir sogar die Anforderungen überprüfen, die zur Erstellung des vorhandenen Systems geführt haben - ein Ausgangspunkt für die Dokumentation der aktuellen Anforderungen. Nuggets von Informationen sind häufig in vorhandenen Dokumenten vergraben, die uns helfen, Fragen zu stellen, um die Vollständigkeit der Anforderungen zu überprüfen.

Fokusgruppe

Eine Fokusgruppe ist eine Versammlung von Personen, die für die Benutzer oder Kunden eines Produkts repräsentativ sind, um Feedback zu erhalten. Das Feedback kann über Bedürfnisse / Möglichkeiten / Probleme gesammelt werden, um Anforderungen zu identifizieren, oder kann gesammelt werden, um bereits ermittelte Anforderungen zu validieren und zu verfeinern. Diese Form der Marktforschung unterscheidet sich vom Brainstorming dadurch, dass es sich um einen verwalteten Prozess mit bestimmten Teilnehmern handelt.

Schnittstellenanalyse

Schnittstellen für ein Softwareprodukt können Mensch oder Maschine sein. Die Integration mit externen Systemen und Geräten ist nur eine weitere Schnittstelle. Benutzerorientierte Designansätze stellen sehr effektiv sicher, dass wir verwendbare Software erstellen. Schnittstellenanalyse - Das Überprüfen der Berührungspunkte mit anderen externen Systemen ist wichtig, um sicherzustellen, dass Anforderungen nicht übersehen werden, die für Benutzer nicht sofort sichtbar sind.

Interview

Interviews mit Stakeholdern und Benutzern sind entscheidend für die Erstellung der großartigen Software. Ohne die Ziele und Erwartungen der Benutzer und Stakeholder zu verstehen, ist es sehr unwahrscheinlich, dass wir sie erfüllen. Wir müssen auch die Perspektive jedes Befragten erkennen, damit wir seine Eingaben richtig abwägen und ansprechen können. Zuhören ist die Fähigkeit, die einem großartigen Analysten hilft, mehr Wert aus einem Interview zu ziehen als ein durchschnittlicher Analyst.

Überwachung

Durch Beobachtung der Benutzer kann ein Analyst einen Prozessablauf, Schritte, Schwachstellen und Verbesserungsmöglichkeiten identifizieren. Beobachtungen können passiv oder aktiv sein (Fragen stellen während des Beobachtens). Passive Beobachtung ist besser, um Feedback zu einem Prototyp zu erhalten (um Anforderungen zu verfeinern), wobei aktive Beobachtung effektiver ist, um ein Verständnis für einen vorhandenen Geschäftsprozess zu erlangen. Jeder Ansatz kann verwendet werden.

Prototyp entwickeln

Prototyping ist eine relativ moderne Technik zum Sammeln von Anforderungen. Bei diesem Ansatz erfassen Sie vorläufige Anforderungen, anhand derer Sie eine erste Version der Lösung erstellen - einen Prototyp. Sie zeigen dies dem Kunden, der Ihnen dann zusätzliche Anforderungen stellt. Sie ändern die Anwendung und fahren erneut mit dem Client. Dieser sich wiederholende Prozess wird fortgesetzt, bis das Produkt die kritische Masse der Geschäftsanforderungen oder eine vereinbarte Anzahl von Iterationen erfüllt.

Anforderungsworkshops

Workshops können sehr effektiv sein, um Anforderungen zu sammeln. Die beteiligten Parteien sind strukturierter als eine Brainstorming-Sitzung und arbeiten zusammen, um die Anforderungen zu dokumentieren. Eine Möglichkeit, die Zusammenarbeit zu erfassen, besteht in der Erstellung von Domänenmodellartefakten (wie statischen Diagrammen, Aktivitätsdiagrammen). Ein Workshop ist mit zwei Analysten effektiver als mit einem.

Reverse Engineering

Wenn ein Migrationsprojekt keinen Zugriff auf eine ausreichende Dokumentation des vorhandenen Systems hat, ermittelt das Reverse Engineering, was das System tut. Es wird nicht identifiziert, was das System tun soll, und es wird nicht identifiziert, wann das System das Falsche tut.

Fragebogen

Beim Sammeln von Informationen von vielen Personen - zu viele, um mit Budget- und Zeitbeschränkungen zu sprechen - kann eine Umfrage oder ein Fragebogen verwendet werden. Die Umfrage kann Benutzer dazu zwingen, aus Auswahlmöglichkeiten auszuwählen, etwas zu bewerten („Stark zustimmen, zustimmen…“) oder offene Fragen zu haben, die Freiformantworten ermöglichen. Das Umfragedesign ist schwierig - Fragen können die Befragten beeinflussen.

Dokument mit den funktionalen Anforderungen

Das Functional Requirements Document (FRD) ist eine formale Erklärung der funktionalen Anforderungen einer Anwendung. Es dient dem gleichen Zweck wie ein Vertrag. Hier erklären sich die Entwickler damit einverstanden, die angegebenen Funktionen bereitzustellen. Der Kunde erklärt sich damit einverstanden, das Produkt als zufriedenstellend zu betrachten, wenn es die in der FRD angegebenen Funktionen bietet.

Funktionale Anforderungen erfassen das beabsichtigte Verhalten des Systems. Dieses Verhalten kann als Dienste, Aufgaben oder Funktionen ausgedrückt werden, die das System ausführen muss. Das Dokument sollte auf die Bedürfnisse eines bestimmten Projekts zugeschnitten sein. Sie definieren Dinge wie Systemberechnungen, Datenmanipulation und -verarbeitung, Benutzeroberfläche und Interaktion mit der Anwendung.

Das Functional Requirements Document (FRD) weist die folgenden Merkmale auf:

  • Es zeigt, dass die Anwendung in den nächsten Jahren einen Mehrwert in Bezug auf die Geschäftsziele und Geschäftsprozesse bietet.

  • Es enthält einen vollständigen Satz von Anforderungen für die Anwendung. Es lässt niemandem Raum, etwas anzunehmen, was nicht in der FRD angegeben ist.

  • Es ist lösungsunabhängig. Die ERD ist eine Aussage darüber, was die Anwendung tun soll - nicht darüber, wie sie funktioniert. Die FRD verpflichtet die Entwickler nicht zu einem Entwurf. Aus diesem Grund ist ein Hinweis auf die Verwendung einer bestimmten Technologie in einer FRD völlig unangemessen.

Die funktionale Anforderung sollte Folgendes umfassen:

  • Beschreibungen von data in das System eingegeben werden

  • Beschreibungen von operations von jedem Bildschirm durchgeführt

  • Beschreibungen von work-flows vom System durchgeführt

  • Beschreibungen von system reports oder andere Ausgänge

  • Wer kann das betreten data in das System?

  • Wie das System zutrifft regulatory requirements?

Die Funktionsspezifikation ist so konzipiert, dass sie von einem allgemeinen Publikum gelesen werden kann. Leser sollten das System verstehen, aber es sollten keine technischen Kenntnisse erforderlich sein, um dieses Dokument zu verstehen.

Funktionale Anforderungen Ergebnisse

Ein Business Requirements Document (BRD) besteht aus -

  • Functional Requirements- Ein Dokument mit detaillierten Anforderungen an das zu entwickelnde System. Diese Anforderungen definieren die funktionalen Merkmale und Fähigkeiten, die ein System besitzen muss. Stellen Sie sicher, dass alle im Business Case identifizierten Annahmen und Einschränkungen korrekt und aktuell sind.

  • Business Process Model - Ein Modell des aktuellen Status des Prozesses ("wie es ist" -Modell) oder ein Konzept dessen, was der Prozess werden soll ("zu sein" -Modell)

  • System Context Diagram - Ein Kontextdiagramm zeigt die Systemgrenzen, externen und internen Entitäten, die mit dem System interagieren, und die relevanten Datenflüsse zwischen diesen externen und internen Entitäten.

  • Flow Diagrams (as-is or to-be)- Diagramme zeigen grafisch die Abfolge von Vorgängen oder die Bewegung von Daten für einen Geschäftsprozess. Je nach Komplexität des Modells sind ein oder mehrere Flussdiagramme enthalten.

  • Business Rules and Data Requirements - Geschäftsregeln definieren oder beschränken einige Aspekte des Geschäfts und werden verwendet, um Datenbeschränkungen, Standardwerte, Wertebereiche, Kardinalität, Datentypen, Berechnungen, Ausnahmen, erforderliche Elemente und die relationale Integrität der Daten zu definieren.

  • Data Models - Entitätsbeziehungsdiagramme, Entitätsbeschreibungen, Klassendiagramme

  • Conceptual Model - Übergeordnete Anzeige verschiedener Entitäten für eine Geschäftsfunktion und deren Beziehung zueinander.

  • Logical Model - Veranschaulicht die spezifischen Entitäten, Attribute und Beziehungen, die an einer Geschäftsfunktion beteiligt sind, und repräsentiert alle Definitionen, Merkmale und Beziehungen von Daten in einer geschäftlichen, technischen oder konzeptionellen Umgebung.

  • Data Dictionary and Glossary - Eine Sammlung detaillierter Informationen zu den Datenelementen, Feldern, Tabellen und anderen Entitäten, aus denen das Datenmodell besteht, das einer Datenbank oder einem ähnlichen Datenverwaltungssystem zugrunde liegt.

  • Stakeholder Map- Identifiziert alle Stakeholder, die von der vorgeschlagenen Änderung betroffen sind, und ihren Einfluss / ihre Autorität für Anforderungen. Dieses Dokument wurde in der Erstellungsphase der Projektmanagement-Methodik (PMM) entwickelt und gehört dem Projektmanager. Es muss jedoch vom Projektteam aktualisiert werden, da während des gesamten Prozesses neue / geänderte Stakeholder identifiziert werden.

  • Requirements Traceability Matrix - Eine Tabelle, die logische Verknüpfungen zwischen einzelnen Funktionsanforderungen und anderen Arten von Systemartefakten veranschaulicht, einschließlich anderer Funktionsanforderungen, Anwendungsfälle / Benutzergeschichten, Architektur- und Designelemente, Codemodule, Testfälle und Geschäftsregeln.

Softwareanforderungen

Eine Software Requirements Specification (SRS) ist ein Dokument, das als Kommunikationsmedium zwischen den Kunden verwendet wird. Eine Softwareanforderungsspezifikation in ihrer grundlegendsten Form ist ein formales Dokument, das zur Kommunikation der Softwareanforderungen zwischen dem Kunden und dem Entwickler verwendet wird.

Ein SRS-Dokument konzentriert sich auf WHAT muss getan werden und vermeidet sorgfältig die Lösung (how to do). Es dient als Vertrag zwischen dem Entwicklungsteam und dem Kunden. Die Anforderungen in dieser Phase werden unter Verwendung der Endbenutzerterminologie geschrieben. Falls erforderlich, wird später eine formale Anforderungsspezifikation daraus entwickelt.

SRS ist eine vollständige Beschreibung des Verhaltens eines zu entwickelnden Systems und kann eine Reihe von Anwendungsfällen enthalten, die die Interaktionen beschreiben, die die Benutzer mit der Software haben werden.

Zweck von SRS

SRS ist ein Kommunikationstool zwischen Kunden / Kunden, Business Analysten, Systementwicklern und Wartungsteams. Es kann sich auch um einen Vertrag zwischen Käufer und Lieferant handeln.

  • Es wird eine solide Grundlage für die Entwurfsphase geben
  • Unterstützt Projektmanagement und -steuerung
  • Hilft bei der Steuerung und Weiterentwicklung des Systems

Eine Spezifikation der Softwareanforderungen sollte vollständig, konsistent, nachvollziehbar, eindeutig und überprüfbar sein.

Folgendes sollte in der Systemspezifikation behandelt werden:

  • Definieren Sie die Funktionen der Systeme
  • Definieren Sie die funktionale Hardware- / Software-Partitionierung
  • Definieren Sie die Leistungsspezifikation
  • Definieren Sie die Hardware- / Software-Leistungspartitionierung
  • Sicherheitsanforderungen definieren
  • Definieren Sie die Benutzeroberfläche (Benutzerhandbuch)
  • Installationszeichnungen / -anweisungen bereitstellen
  • Spezifikationsvorlage für Softwareanforderungen

Versionsgeschichte

Datum Beschreibung Autor Bemerkungen
<Datum> <Version 1> <Ihr Name> <Erste Revision>

Dokumentgenehmigung

Die folgende Softwareanforderungsspezifikation wurde von den folgenden akzeptiert und genehmigt:

Unterschrift Gedruckter Name Titel Datum
<Ihr Name> Lead Software Eng.
David Lehrer

Geschäftsanalyse - Anwendungsfälle

Eines der neun Diagramme von UMLs ist das Anwendungsfalldiagramm. Dies sind nicht nur wichtige, sondern notwendige Voraussetzungen für Softwareprojekte. Es wird grundsätzlich in Software-Lebenszyklen verwendet. Wie wir wissen, gibt es verschiedene Phasen im Entwicklungszyklus, und die am häufigsten verwendete Phase für Anwendungsfälle ist die Phase der Anforderungserfassung.

Was ist ein Anwendungsfall?

Ein Anwendungsfall beschreibt eine Folge von Aktionen, die von einem System ausgeführt werden, das einem Akteur einen Wert bietet. Der Anwendungsfall beschreibt das Verhalten des Systems unter verschiedenen Bedingungen, wenn es auf eine Anfrage eines der Stakeholder namens "the" reagiertprimary actor.

Der Schauspieler ist das Who des Systems, mit anderen Worten, er ist der Endbenutzer.

In der Software- und Systemtechnik ist ein Anwendungsfall eine Liste von Schritten, die typischerweise Interaktionen zwischen einer Rolle (in UML als "Akteur" bezeichnet) und einem System definieren, um ein Ziel zu erreichen. Der Schauspieler kann ein menschliches oder ein externes System sein.

Ein Anwendungsfall gibt den Ereignisfluss im System an. Es geht mehr darum, was das System ausführt, um die Abfolge der Aktionen auszuführen.

Vorteile eines Anwendungsfalls

Ein Anwendungsfall bietet die folgenden Vorteile:

  • Es ist ein einfaches Mittel, um die funktionalen Anforderungen zu erfassen, wobei der Schwerpunkt auf dem Mehrwert für den Benutzer liegt.

  • Anwendungsfälle sind im Vergleich zu herkömmlichen Anforderungsmethoden relativ einfach zu schreiben und zu lesen.

  • Anwendungsfälle zwingen Entwickler, aus der Perspektive des Endbenutzers zu denken.

  • Anwendungsfall Binden Sie den Benutzer in den Anforderungsprozess ein.

Die Anatomie eines Anwendungsfalls

Name : Beschreibender Name, der den Zweck des Anwendungsfalls veranschaulicht.

Beschreibung : Beschreibt in einigen Sätzen, was der Anwendungsfall bewirkt.

Schauspieler : Listen Sie alle Akteure auf, die am Anwendungsfall teilnehmen.

Voraussetzung : Bedingungen, die vor Beginn des Anwendungsfalls erfüllt sein müssen.

Ablauf der Ereignisse : Beschreibung der Interaktion zwischen dem System und dem Akteur.

Nachbedingung : Beschreiben Sie den Status des Systems, nachdem ein Anwendungsfall seinen Lauf genommen hat.

Anleitung für Anwendungsfallvorlagen

Dokumentieren Sie jeden Anwendungsfall anhand der Vorlage am Ende dieses Kapitels. Dieser Abschnitt enthält eine Beschreibung jedes Abschnitts in der Anwendungsfallvorlage.

Use-Case-Identifikation

  • Use-Case ID- Geben Sie jedem Anwendungsfall eine eindeutige numerische Kennung in hierarchischer Form: XY Verwandte Anwendungsfälle können in der Hierarchie gruppiert werden. Funktionale Anforderungen lassen sich auf einen gekennzeichneten Anwendungsfall zurückführen.

  • Use-Case Name- Geben Sie einen präzisen, ergebnisorientierten Namen für den Anwendungsfall an. Diese spiegeln die Aufgaben wider, die der Benutzer mit dem System ausführen muss. Fügen Sie ein Aktionsverb und ein Substantiv hinzu. Einige Beispiele -

    • Teilenummerninformationen anzeigen.

    • Markieren Sie die Hypertextquelle manuell und stellen Sie eine Verknüpfung zum Ziel her.

    • Bestellen Sie eine CD mit der aktualisierten Softwareversion.

Anwendungsfallhistorie

Hier erwähnen wir die Namen der Personen, die an dem Usecase-Dokument beteiligt sind.

  • Created By - Geben Sie den Namen der Person an, die diesen Anwendungsfall ursprünglich dokumentiert hat.

  • Date Created - Geben Sie das Datum ein, an dem der Anwendungsfall ursprünglich dokumentiert wurde.

  • Last Updated By - Geben Sie den Namen der Person an, die die letzte Aktualisierung der Anwendungsfallbeschreibung durchgeführt hat.

  • Date Last Updated - Geben Sie das Datum ein, an dem der Anwendungsfall zuletzt aktualisiert wurde.

Anwendungsfalldefinition

Das Folgende sind die Definitionen der Schlüsselkonzepte des Anwendungsfalls -

Darsteller

Ein Akteur ist eine Person oder eine andere Entität außerhalb des angegebenen Softwaresystems, die mit dem System interagiert und Anwendungsfälle ausführt, um Aufgaben auszuführen. Unterschiedliche Akteure entsprechen häufig unterschiedlichen Benutzerklassen oder Rollen, die von der Kundengemeinschaft identifiziert wurden, die das Produkt verwenden wird. Nennen Sie die Schauspieler, die diesen Anwendungsfall ausführen.

Beschreibung

Geben Sie eine kurze Beschreibung des Grundes und des Ergebnisses dieses Anwendungsfalls oder eine allgemeine Beschreibung der Abfolge der Aktionen und des Ergebnisses der Ausführung des Anwendungsfalls an.

Voraussetzungen

Listen Sie alle Aktivitäten auf, die stattfinden müssen, oder alle Bedingungen, die erfüllt sein müssen, bevor der Anwendungsfall gestartet werden kann. Nummerieren Sie jede Voraussetzung.

Examples

  • Die Identität des Benutzers wurde authentifiziert.
  • Der Computer des Benutzers verfügt über ausreichend freien Speicher, um die Aufgabe zu starten.

Post Bedingungen

Beschreiben Sie den Status des Systems am Ende der Ausführung des Anwendungsfalls. Nummerieren Sie jede Postbedingung.

Examples

  • Das Dokument enthält nur gültige SGML-Tags.
  • Der Preis des Artikels in der Datenbank wurde mit einem neuen Wert aktualisiert.

Priorität

Geben Sie die relative Priorität der Implementierung der Funktionalität an, die erforderlich ist, damit dieser Anwendungsfall ausgeführt werden kann. Das verwendete Prioritätsschema muss mit dem in der Spezifikation der Softwareanforderungen verwendeten übereinstimmen.

Häufigkeit der Nutzung

Schätzen Sie, wie oft dieser Anwendungsfall von den Akteuren pro geeigneter Zeiteinheit ausgeführt wird.

Normaler Ablauf

Geben Sie eine detaillierte Beschreibung der Benutzeraktionen und Systemantworten an, die während der Ausführung des Anwendungsfalls unter normalen, erwarteten Bedingungen ausgeführt werden. Diese Dialogsequenz führt letztendlich dazu, dass das im Anwendungsfallnamen und in der Beschreibung angegebene Ziel erreicht wird. Diese Beschreibung kann als Antwort auf die hypothetische Frage geschrieben werden: "Wie erfülle ich <die im Anwendungsfallnamen angegebene Aufgabe>?" Dies geschieht am besten als nummerierte Liste der vom Akteur ausgeführten Aktionen im Wechsel mit den vom System bereitgestellten Antworten.

Alternative Kurse

Dokumentieren Sie andere, legitime Verwendungsszenarien, die in diesem Anwendungsfall stattfinden können, separat in diesem Abschnitt. Geben Sie den alternativen Kurs an und beschreiben Sie alle Unterschiede in der Reihenfolge der Schritte, die stattfinden. Nummerieren Sie jeden Alternativkurs mit der Use-Case-ID als Präfix, gefolgt von „AC“, um „Alternativkurs“ anzugeben. Beispiel: XYAC.1.

Ausnahmen

Beschreiben Sie alle erwarteten Fehlerbedingungen, die während der Ausführung des Anwendungsfalls auftreten können, und definieren Sie, wie das System auf diese Bedingungen reagieren soll. Beschreiben Sie außerdem, wie das System reagieren soll, wenn die Ausführung des Anwendungsfalls aus einem unerwarteten Grund fehlschlägt. Nummerieren Sie jede Ausnahme mit der Anwendungsfall-ID als Präfix, gefolgt von „EX“, um „Ausnahme“ anzuzeigen. Beispiel: XYEX.1.

Beinhaltet

Listen Sie alle anderen Anwendungsfälle auf, die in diesem Anwendungsfall enthalten sind („aufgerufen“). Gemeinsame Funktionen, die in mehreren Anwendungsfällen angezeigt werden, können in einen separaten Anwendungsfall aufgeteilt werden, der von denjenigen eingeschlossen wird, die diese gemeinsamen Funktionen benötigen.

Spezielle Anforderungen

Identifizieren Sie alle zusätzlichen Anforderungen, z. B. nicht funktionierende Anforderungen, für den Anwendungsfall, die möglicherweise während des Entwurfs oder der Implementierung berücksichtigt werden müssen. Dies können Leistungsanforderungen oder andere Qualitätsmerkmale sein.

Annahmen

Listen Sie alle in der Analyse getroffenen Annahmen auf, die dazu geführt haben, dass dieser Anwendungsfall in die Produktbeschreibung aufgenommen und die Anwendungsfallbeschreibung geschrieben wurde.

Anmerkungen und Probleme

Listen Sie zusätzliche Kommentare zu diesem Anwendungsfall oder alle verbleibenden offenen Probleme oder TBDs (noch festzulegen) auf, die behoben werden müssen. Identifizieren Sie, wer jedes Problem lösen wird, das Fälligkeitsdatum und die endgültige Lösung.

Änderungsmanagement und Versionskontrolle

Die Versionskontrolle ist die Verwaltung von Änderungen an Dokumenten, großen Websites und anderen Informationssammlungen. Änderungen werden normalerweise durch einen Zahlen- oder Buchstabencode gekennzeichnet, der als Revisionsnummer oder Revisionsstand bezeichnet wird. Jede Revision ist einem Zeitstempel und einer Person zugeordnet, die die Änderung vornimmt.

Anwendungsfalldiagramme

Ein wichtiger Teil der Unified Modeling Language (UML) sind die Möglichkeiten zum Zeichnen von Anwendungsdiagrammen. Anwendungsfälle werden während der Analysephase eines Projekts verwendet, um die Systemfunktionalität zu identifizieren und zu partitionieren. Sie unterteilen das System in Akteure und Anwendungsfälle. Akteure stellen Rollen dar, die von Benutzern des Systems gespielt werden können.

Diese Benutzer können Menschen, andere Computer, Hardwareteile oder sogar andere Softwaresysteme sein. Das einzige Kriterium ist, dass sie außerhalb des Teils des Systems liegen müssen, der in Anwendungsfälle unterteilt wird. Sie müssen diesen Teil des Systems mit Stimuli versorgen und von ihm Ausgänge empfangen.

Anwendungsfälle stellen die Aktivitäten dar, die Akteure mit Hilfe Ihres Systems ausführen, um ein Ziel zu verfolgen. Wir müssen definieren, was diese Benutzer (Akteure) vom System benötigen. Der Anwendungsfall sollte die Bedürfnisse und Ziele der Benutzer widerspiegeln und von einem Akteur initiiert werden. Unternehmen, Akteure und Kunden, die am Geschäftsanwendungsfall teilnehmen, sollten durch Vereinigung mit dem Anwendungsfall verbunden werden.

Anwendungsfalldiagramme zeichnen

Die folgende Abbildung zeigt, wie ein Anwendungsfall wie eine UML-Schaltform aussehen könnte. Der Anwendungsfall selbst sieht aus wie ein Oval. Die Schauspieler sind als kleine Strichmännchen gezeichnet. Die Akteure sind über Linien mit dem Anwendungsfall verbunden.

Use-case 1 - Verkäufer checkt einen Artikel aus

  • Der Kunde legt den Artikel auf den Schalter.
  • «Verwendet» Swipe UPC Reader.
  • Das System sucht in der Datenbank nach UPC-Code, um die Artikelbeschreibung und den Preis zu ermitteln
  • Das System gibt einen Signalton aus.
  • Das System gibt die Artikelbeschreibung und den Preis über die Sprachausgabe bekannt.
  • Das System fügt der aktuellen Rechnung Preis und Artikeltyp hinzu.
  • Das System addiert den Preis zur korrekten Zwischensumme der Steuern

Die Beziehung «using» ähnelt also stark einem Funktionsaufruf oder einer Unterroutine.

Der auf diese Weise verwendete Anwendungsfall wird als abstrakter Anwendungsfall bezeichnet, da er nicht eigenständig existieren kann, sondern von anderen Anwendungsfällen verwendet werden muss.

Beispiel ─ Anwendungsfall für das Zurückziehen

Das Ziel eines Kunden in Bezug auf unseren Geldautomaten ist es, Geld abzuheben. Also fügen wir hinzuWithdrawalAnwendungsfall. Das Abheben von Geld aus dem Automaten kann eine Bank für die durchzuführenden Transaktionen einbeziehen. Also fügen wir noch einen weiteren Schauspieler hinzu -Bank. Beide am Anwendungsfall beteiligten Akteure sollten durch Vereinigung mit dem Anwendungsfall verbunden sein.

Der Geldautomat bietet dem Kunden und den Akteuren der Bank einen Anwendungsfall für die Auszahlung.

Beziehungen zwischen Akteuren und Anwendungsfällen

Anwendungsfälle können mithilfe der folgenden Beziehungen organisiert werden:

  • Generalization
  • Association
  • Extend
  • Include

Verallgemeinerung zwischen Anwendungsfällen

Es kann Fälle geben, in denen Akteure mit ähnlichen Anwendungsfällen verbunden sind. In diesem Fall erbt ein untergeordneter Anwendungsfall die Eigenschaften und das Verhalten der übergeordneten Verwendung. Daher müssen wir den Akteur verallgemeinern, um die Vererbung von Funktionen zu zeigen. Sie werden durch eine durchgezogene Linie mit einer großen Pfeilspitze mit hohlem Dreieck dargestellt.

Assoziation zwischen Anwendungsfällen

Assoziationen zwischen Akteuren und Anwendungsfällen sind in Anwendungsfalldiagrammen durch durchgezogene Linien gekennzeichnet. Eine Assoziation besteht immer dann, wenn ein Akteur an einer Interaktion beteiligt ist, die durch einen Anwendungsfall beschrieben wird.

Erweitern

Es gibt einige Funktionen, die optional ausgelöst werden. In solchen Fällen wird die Erweiterungsbeziehung verwendet und die Erweiterungsregel daran angehängt. Beachten Sie, dass der Basisanwendungsfall in der Lage sein sollte, eine Funktion selbst auszuführen, selbst wenn der erweiterte Anwendungsfall nicht aufgerufen wird.

Die erweiterte Beziehung wird als gestrichelte Linie mit einer offenen Pfeilspitze angezeigt, die vom erweiterten Anwendungsfall zum erweiterten (Basis-) Anwendungsfall gerichtet ist. Der Pfeil ist mit dem Schlüsselwort «verlängern» gekennzeichnet.

Einschließen

Es wird verwendet, um Anwendungsfallfragmente zu extrahieren, die in mehreren Anwendungsfällen dupliziert werden. Es wird auch verwendet, um große Anwendungsfälle zu vereinfachen, indem es in mehrere Anwendungsfälle aufgeteilt wird, und um gemeinsame Teile des Verhaltens von zwei oder mehr Anwendungsfällen zu extrahieren.

Schließen Sie die Beziehung zwischen Anwendungsfällen ein, die durch einen gestrichelten Pfeil mit einer offenen Pfeilspitze vom Basisanwendungsfall zum eingeschlossenen Anwendungsfall angezeigt wird. Der Pfeil ist mit dem Schlüsselwort «include» gekennzeichnet.

Anwendungsfälle befassen sich nur mit den funktionalen Anforderungen an ein System. Andere Anforderungen wie Geschäftsregeln, Anforderungen an die Servicequalität und Implementierungsbeschränkungen müssen separat dargestellt werden.

Das folgende Diagramm ist ein Beispiel für ein einfaches Anwendungsfalldiagramm mit allen markierten Elementen.

Grundprinzipien für eine erfolgreiche Anwendung von Anwendungsfällen

  • Halten Sie es einfach, indem Sie Geschichten erzählen
  • Seien Sie produktiv ohne Perfektion
  • Verstehe das große Ganze
  • Identifizieren Sie die Wiederverwendungsmöglichkeit für Anwendungsfälle
  • Wert im Fokus
  • Bauen Sie das System in Scheiben
  • Liefern Sie das System in Schritten
  • Passen Sie sich an die Bedürfnisse des Teams an

Anwendungsfallvorlage

Hier haben wir eine Beispielvorlage eines Anwendungsfalls gezeigt, die ein Business Analyst ausfüllen kann, damit die Informationen für das technische Team nützlich sein können, um Informationen über das Projekt zu ermitteln.

Anwendungsfall-ID:
Anwendungsfallname:
Erstellt von: Zuletzt aktualisiert von
Datum erstellt: Datum der letzten Aktualisierung
Darsteller:
Beschreibung:
Voraussetzungen:
Postbedingungen:
Priorität:
Häufigkeit der Nutzung:
Normaler Ablauf:
Alternative Kurse:
Ausnahmen:
Beinhaltet:
Spezielle Anforderungen:
Annahmen:
Anmerkungen und Probleme:

Geschäftsanalyse - Anforderungen Mngmt

Das Sammeln von Softwareanforderungen ist die Grundlage des gesamten Softwareentwicklungsprojekts. Das Einholen und Sammeln von Geschäftsanforderungen ist ein kritischer erster Schritt für jedes Projekt. Um die Lücke zwischen geschäftlichen und technischen Anforderungen zu schließen, müssen die Geschäftsanalysten die Geschäftsanforderungen im gegebenen Kontext vollständig verstehen, diese Anforderungen an den Geschäftszielen ausrichten und die Anforderungen sowohl den Stakeholdern als auch dem Entwicklungsteam ordnungsgemäß mitteilen.

Die wichtigsten Stakeholder wünschen sich, dass jemand die Kundenanforderungen in einfachem Englisch erklärt. Wird dies ihnen zugute kommen, wenn sie den Wert auf hohem Niveau verstehen? Dies wird der Schwerpunkt sein, da sie versuchen werden, die Dokumentation mit den Anforderungen abzubilden und wie BA bestmöglich kommunizieren kann.

Warum Projekte scheitern

Es gibt viele Gründe, warum Projekte scheitern, aber einige der gemeinsamen Bereiche umfassen die folgenden:

  • Markt- und Strategieversagen
  • Organisations- und Planungsfehler
  • Qualitätsmängel
  • Führungs- und Governance-Fehler
  • Kompetenz-, Wissens- und Kompetenzfehler
  • Engagement, Teamarbeit und Kommunikationsfehler

Im Mittelpunkt des Problems steht, dass Projekte immer komplexer werden, Änderungen auftreten und die Kommunikation eine Herausforderung darstellt.

Warum erfolgreiche Teams Anforderungsmanagement betreiben

Beim Anforderungsmanagement geht es darum, Ihr Team zu halten in-sync und Bereitstellung visibility zu dem, was innerhalb eines Projekts vor sich geht.

Für den Erfolg Ihrer Projekte ist es entscheidend, dass Ihr gesamtes Team versteht, was Sie aufbauen und warum - so definieren wir das Anforderungsmanagement. Das „Warum“ ist wichtig, weil es Kontext zu den Zielen, Rückmeldungen und Entscheidungen bietet, die über die Anforderungen getroffen werden.

Dies erhöht die Vorhersehbarkeit zukünftiger Erfolge und potenzieller Probleme und ermöglicht Ihrem Team, Probleme schnell zu beheben und Ihr Projekt pünktlich und innerhalb des Budgets erfolgreich abzuschließen. Als Ausgangspunkt ist es für alle Beteiligten wertvoll, ein grundlegendes Verständnis dafür zu haben, was Anforderungen sind und wie sie zu verwalten sind.

Beginnen wir mit den Grundlagen

Eine Anforderung ist eine Bedingung oder Fähigkeit, die ein Stakeholder benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. Eine Bedingung oder Fähigkeit, die von einem System oder System erfüllt oder besessen werden muss. Komponente zur Erfüllung eines Vertrags, einer Norm, einer Spezifikation oder anderer formal auferlegter Dokumente.

Eine Anforderung kann mit Text, Skizzen, detaillierten Modellen oder Modellen ausgedrückt werden, unabhängig davon, welche Informationen einem Ingenieur am besten mitteilen, was gebaut werden soll, und einem QS-Manager, was getestet werden soll. Abhängig von Ihrem Entwicklungsprozess verwenden Sie möglicherweise unterschiedliche Begriffe, um Anforderungen zu erfassen.

Übergeordnete Anforderungen werden manchmal einfach als bezeichnet needs oder goals. Innerhalb der Softwareentwicklungspraktiken können Anforderungen als "Anwendungsfälle", "Funktionen" oder "funktionale Anforderungen" bezeichnet werden. Noch genauer innerhalb agiler Entwicklungsmethoden werden Anforderungen häufig als erfasstepics und stories.

Unabhängig davon, wie Ihr Team sie nennt oder welchen Prozess Sie verwenden. Anforderungen sind für die Entwicklung aller Produkte von wesentlicher Bedeutung. Ohne klare Definition der Anforderungen können Sie ein unvollständiges oder fehlerhaftes Produkt produzieren. Während des gesamten Prozesses können viele Personen an der Definition von Anforderungen beteiligt sein.

Ein Stakeholder kann eine Funktion anfordern, die beschreibt, wie das Produkt bei der Lösung eines Problems einen Mehrwert bietet. Ein Designer kann eine Anforderung definieren, die darauf basiert, wie das Endprodukt unter dem Gesichtspunkt der Benutzerfreundlichkeit oder der Benutzeroberfläche aussehen oder funktionieren soll.

Ein Geschäftsanalyst kann eine Systemanforderung erstellen, die bestimmten technischen oder organisatorischen Einschränkungen entspricht. Für die Entwicklung anspruchsvoller Produkte und Softwareanwendungen von heute sind häufig Hunderte oder Tausende von Anforderungen erforderlich, um den Umfang eines Projekts oder einer Version ausreichend zu definieren. Daher ist es unerlässlich, dass das Team in der Lage ist, auf jede Anforderung zuzugreifen, zusammenzuarbeiten, sie zu aktualisieren und bis zum Abschluss zu testen, da sich die Anforderungen während des Entwicklungsprozesses natürlich ändern und im Laufe der Zeit weiterentwickeln.

Nachdem wir den Wert des Anforderungsmanagements auf hoher Ebene definiert haben, gehen wir näher auf die vier Grundlagen ein, die jedes Teammitglied und jeder Stakeholder vom Verständnis profitieren kann.

  • Planen Sie gute Anforderungen: "Was zum Teufel bauen wir?"
  • Zusammenarbeit und Buy-In: „Genehmigen Sie die Spezifikation bereits!“
  • Rückverfolgbarkeit und Änderungsmanagement: "Warten Sie, wissen die Entwickler, dass sich dies geändert hat?"
  • Qualitätssicherung: „Hallo, hat jemand dieses Ding getestet?“

Weiß jeder, was wir bauen und warum? Das ist der Wert des Anforderungsmanagements.

Zusammenarbeit und Buy-In von Stakeholdern

Ist jeder auf dem Laufenden? Haben wir eine Genehmigung für die Anforderungen, um vorwärts zu kommen? Diese Fragen tauchen während der Entwicklungszyklen auf. Es wäre großartig, wenn sich alle auf Anforderungen einigen könnten, aber bei großen Projekten mit vielen Stakeholdern geschieht dies normalerweise nicht. Der Versuch, alle zu einer Einigung zu bringen, kann dazu führen, dass Entscheidungen verzögert oder gar nicht getroffen werden. Es ist nicht immer einfach, bei jeder Entscheidung einen Konsens zu erzielen.

In der Praxis möchten Sie nicht unbedingt einen „Konsens“, sondern ein „Buy-In“ der Gruppe und eine Genehmigung der Verantwortlichen, damit Sie das Projekt vorantreiben können. Mit Konsens versuchen Sie, alle dazu zu bringen, Kompromisse einzugehen und sich auf die Entscheidung zu einigen. Mit Buy-In versuchen Sie, die Leute dazu zu bringen, die beste Lösung zu unterstützen, eine kluge Entscheidung zu treffen und das Notwendige zu tun, um vorwärts zu kommen.

Sie müssen nicht alle zustimmen, dass die Entscheidung die beste ist. Sie brauchen jeden, der die Entscheidung unterstützt. Teamzusammenarbeit kann dabei helfen, Unterstützung bei Entscheidungen zu erhalten und gute Anforderungen zu planen.

Kollaborative Teams arbeiten hart daran, sicherzustellen, dass jeder an Projekten beteiligt ist und Feedback gibt. Kollaborative Teams tauschen kontinuierlich Ideen aus, haben in der Regel eine bessere Kommunikation und unterstützen Entscheidungen, die getroffen werden, weil ein gemeinsames Gefühl des Engagements und des Verständnisses für die Ziele des Projekts besteht.

Wenn Entwickler, Tester oder andere Stakeholder sich „out of the loop“ fühlen, treten Kommunikationsprobleme auf, die Leute werden frustriert und Projekte verzögern sich. Sobald sich alle für den Arbeitsumfang entschieden haben, müssen die Anforderungen klar und gut dokumentiert sein. Wenn Sie alle Anforderungen im Auge behalten, wird es schwierig.

Stellen Sie sich vor, Sie haben eine Aufgabenliste mit einer Länge von einer Meile, bei der Sie mit mehreren Personen zusammenarbeiten müssen. Wie würden Sie all diese Dinge gerade halten? Wie würden Sie verfolgen, wie sich eine Änderung an einem Element auf den Rest des Projekts auswirken würde? Hier schaffen Rückverfolgbarkeit und Änderungsmanagement einen Mehrwert.

Gute Anforderungen planen

Was macht also eine gute Anforderung aus? Eine gute Anforderung sollte wertvoll und umsetzbar sein. Es sollte einen Bedarf definieren und einen Weg zu einer Lösung bieten. Jeder im Team sollte verstehen, was es bedeutet. Die Anforderungen variieren in der Komplexität.

  • Ein gutes Anforderungsdokument kann Teil einer Gruppe mit allgemeinen Anforderungen sein, die in Unteranforderungen unterteilt sind.

  • Sie können auch sehr detaillierte Spezifikationen enthalten, die eine Reihe von funktionalen Anforderungen enthalten, die das Verhalten oder die Komponenten des Endprodukts beschreiben.

  • Gute Anforderungen müssen präzise und spezifisch sein und die Frage beantworten: "Was brauchen wir?" Anstatt: "Wie erfüllen wir ein Bedürfnis?"

  • Gute Anforderungen stellen sicher, dass alle Beteiligten ihren Teil des Plans verstehen. Wenn Teile unklar sind oder falsch interpretiert werden, kann das Endprodukt defekt sein oder versagen.

Das Verhindern von Fehlern oder Fehlinterpretationen von Anforderungen kann unterstützt werden, indem während des gesamten Prozesses kontinuierlich Feedback vom Team erhalten wird, wenn sich die Anforderungen ändern. Kontinuierliche Zusammenarbeit und Zusammenarbeit mit allen ist ein Schlüssel zum Erfolg.

Anforderungserfassung und -analyse

Eine Anforderung ist eine Bedingung oder Fähigkeit, die ein Stakeholder benötigt, um ein Problem zu lösen oder ein organisatorisches Ziel zu erreichen. eine Bedingung oder Fähigkeit, die von einem System erfüllt oder besessen werden muss.

Die Anforderungsanalyse in der Softwareentwicklung umfasst diejenigen Aufgaben, die zur Bestimmung der Anforderungen oder Bedingungen für ein neues oder geändertes Produkt unter Berücksichtigung der möglichen widersprüchlichen Anforderungen verschiedener Interessengruppen, zur Analyse, Dokumentation, Validierung und Verwaltung von Software- oder Systemanforderungen erforderlich sind.

Die Anforderungen sollten sein -

  • Documented
  • Actionable
  • Measurable
  • Testable
  • Traceable

Die Anforderungen sollten sich auf identifizierte Geschäftsanforderungen oder -chancen beziehen und bis zu einem Detaillierungsgrad definiert werden, der für das Systemdesign ausreicht.

Ein Business Analyst sammelt Informationen, indem er die vorhandenen Systeme beobachtet, die vorhandenen Verfahren untersucht, mit den Kunden und den Endbenutzern diskutiert. Der Analyst sollte auch über einfallsreiche und kreative Fähigkeiten verfügen, wenn kein funktionierendes System vorhanden ist. Das Analysieren der gesammelten Anforderung, um die fehlenden Glieder zu finden, ist eine Anforderungsanalyse.

Ansatz erfragen

Stellen Sie dem Geschäftsexperten, dem Entwicklungsleiter und dem Projektsponsor die folgenden Fragen, um die Ziele zu ermitteln:

  • Welche Geschäftsziele des Unternehmens wird dieses Projekt erreichen?

  • Warum machen wir dieses Projekt jetzt?

  • Was passiert, wenn wir es später tun?

  • Was ist, wenn wir es überhaupt nicht tun?

  • Wer wird von diesem Projekt profitieren?

  • Halten die Menschen, die davon profitieren werden, es für die wichtigste Verbesserung, die derzeit möglicherweise erzielt werden kann?

  • Sollten wir stattdessen ein anderes Projekt machen?

Mögliche Ziele könnten sein, die Kosten zu senken, den Kundenservice zu verbessern, den Arbeitsablauf zu vereinfachen, veraltete Technologien zu ersetzen, eine neue Technologie zu testen und viele andere. Stellen Sie außerdem sicher, dass Sie genau verstehen, wie das vorgeschlagene Projekt zur Erreichung des festgelegten Ziels beiträgt.

Verschiedene Arten von Anforderungen

Die häufigsten Arten von Anforderungen, an denen ein Business Analyst interessiert ist, sind folgende:

Geschäftsanforderungen

Geschäftsanforderungen sind die kritischen Aktivitäten eines Unternehmens, die ausgeführt werden müssen, um die organisatorischen Ziele zu erreichen und gleichzeitig lösungsunabhängig zu bleiben. Ein Business Requirements Document (BRD) beschreibt die Geschäftslösung für ein Projekt einschließlich der Dokumentation der Kundenbedürfnisse und -erwartungen.

Benutzeranforderungen

Benutzeranforderungen sollten die spezifischen Anforderungen angeben, die der Benutzer von Software erwartet / wünscht, die aus dem Softwareprojekt erstellt werden soll. Eine Benutzeranforderung sollte überprüfbar, klar und präzise, ​​vollständig, konsistent, nachvollziehbar und lebensfähig sein.

Das Benutzeranforderungsdokument (URD) ​​oder die Benutzeranforderungsspezifikation ist ein Dokument, das normalerweise in der Softwareentwicklung verwendet wird und das angibt, was der Benutzer von der Software erwartet.

System Anforderungen

Die Systemanforderungen befassen sich mit der Definition der Softwareressourcenanforderungen und -voraussetzungen, die auf einem Computer installiert werden müssen, um ein optimales Funktionieren einer Anwendung zu gewährleisten.

Funktionale Anforderungen

Funktionale Anforderungen erfassen und spezifizieren das spezifische beabsichtigte Verhalten des zu entwickelnden Systems. Sie definieren Dinge wie Systemberechnungen, Datenmanipulation und -verarbeitung, Benutzeroberfläche und Interaktion mit der Anwendung sowie andere spezifische Funktionen, die zeigen, wie Benutzeranforderungen erfüllt werden. Weisen Sie jeder Anforderung eine eindeutige ID-Nummer zu.

Nicht-funktionale Anforderungen

Die nicht funktionale Anforderung gibt Kriterien an, anhand derer der Betrieb eines Systems beurteilt werden kann und nicht bestimmte Verhaltensweisen. Die Systemarchitektur spricht über den Plan zur Implementierung nicht funktionaler Anforderungen.

Nichtfunktionale Anforderungen sprechen dafür, wie das System aussehen soll, oder es kann als „System soll“ bezeichnet werden. Nichtfunktionale Anforderungen werden als Eigenschaften des Systems bezeichnet.

Übergangsanforderungen

Übergangsanforderungen beschreiben Funktionen, die die Lösung erfüllen muss, um den Übergang vom aktuellen Status des Unternehmens in einen gewünschten zukünftigen Status zu erleichtern. Diese werden jedoch nach Abschluss dieses Übergangs nicht mehr benötigt.

Sie unterscheiden sich von anderen Anforderungsarten, weil sie immer vorübergehender Natur sind und erst entwickelt werden können, wenn sowohl eine bestehende als auch eine neue Lösung definiert sind. Sie umfassen in der Regel die Datenkonvertierung aus vorhandenen Systemen, Qualifikationslücken, die behoben werden müssen, und andere damit verbundene Änderungen, um den gewünschten zukünftigen Status zu erreichen. Sie werden durch Lösungsbewertung und -validierung entwickelt und definiert.

Rückverfolgbarkeit und Änderungsmanagement

Die Rückverfolgbarkeit von Anforderungen ist eine Möglichkeit, alle Ihre Anforderungen von der ersten Ideengenerierung bis zur Testphase zu organisieren, zu dokumentieren und zu verfolgen.

Die Requirements Trace Capability Matrix (RTM) bietet eine Methode zur Verfolgung der funktionalen Anforderungen und ihrer Implementierung während des Entwicklungsprozesses. Jede Anforderung wird zusammen mit der zugehörigen Abschnittsnummer in die Matrix aufgenommen.

Im Verlauf des Projekts wird das RIM aktualisiert, um den Status jeder Anforderung widerzuspiegeln. Wenn das Produkt für Systemtests bereit ist, listet die Matrix jede Anforderung auf, welche Produktkomponente sie anspricht und welcher Test überprüft, ob sie korrekt implementiert ist

Fügen Sie Spalten für jede der folgenden Optionen in das RTM ein -

  • Anforderungsbeschreibung
  • Anforderungsreferenz in FRD
  • Verifikationsverfahren
  • Anforderungsreferenz im Testplan

Example- Verbinden Sie die Punkte, um die Beziehungen zwischen Elementen in Ihrem Projekt zu identifizieren. Es ist ein Verbinder der gemeinsamen nachgeschalteten Strömung.

Ideenanforderungen Design Test Geschäftsziele

Sie sollten in der Lage sein, jede Ihrer Anforderungen auf das ursprüngliche Geschäftsziel zurückzuführen.

Durch Nachverfolgen von Anforderungen können Sie die Welligkeitseffektänderungen identifizieren, feststellen, ob eine Anforderung abgeschlossen wurde und ob sie ordnungsgemäß getestet wird. Das Rückverfolgbarkeits- und Änderungsmanagement bietet Managern Sicherheit und Transparenz, um Probleme zu antizipieren und eine kontinuierliche Qualität sicherzustellen.

Qualitätskontrolle

Wenn die Anforderungen beim ersten Mal richtig geliefert werden, kann dies zu einer besseren Qualität, schnelleren Entwicklungszyklen und einer höheren Kundenzufriedenheit mit dem Produkt führen. Das Anforderungsmanagement hilft Ihnen nicht nur, es richtig zu machen, sondern hilft Ihrem Team auch, während des gesamten Entwicklungsprozesses Geld und viele Kopfschmerzen zu sparen.

Durch präzise, ​​spezifische Anforderungen können Sie Probleme frühzeitig erkennen und beheben, anstatt später, wenn die Behebung viel teurer ist. Darüber hinaus kann es bis zu kosten100 times mehr, um einen Fehler später im Entwicklungsprozess zu korrigieren, nachdem er codiert wurde, als um ihn frühzeitig zu korrigieren, während eine Anforderung vorliegt.

Durch die Integration des Anforderungsmanagements in Ihren Qualitätssicherungsprozess können Sie Ihrem Team helfen, die Effizienz zu steigern und Nacharbeiten zu vermeiden. Darüber hinaus treten bei Nacharbeiten die meisten Kostenprobleme auf.

Mit anderen Worten, Entwicklungsteams verschwenden einen Großteil ihres Budgets für Anstrengungen, die beim ersten Mal nicht korrekt ausgeführt werden. Ein Entwickler codiert beispielsweise eine Funktion basierend auf einem alten Spezifikationsdokument, um später zu erfahren, dass sich die Anforderungen für diese Funktion geändert haben. Diese Art von Problemen kann mit effektiven Best Practices für das Anforderungsmanagement vermieden werden.

Zusammenfassend lässt sich sagen, dass Anforderungsmanagement wie eine komplexe Disziplin klingen kann. Wenn Sie es jedoch auf ein einfaches Konzept reduzieren, geht es darum, den Teams bei der Beantwortung der Frage zu helfen: „Versteht jeder, was wir aufbauen und warum?“. Von den Geschäftsanalysten, Produktmanagern und Projektleitern über die Entwickler, QS-Manager und Tester bis hin zu den beteiligten Stakeholdern und Kunden ist die Hauptursache für das Scheitern eines Projekts häufig ein Missverständnis des Projektumfangs.

Wenn alle zusammenarbeiten und den gesamten Kontext und die Sichtbarkeit der Diskussionen, Entscheidungen und Änderungen im Zusammenhang mit den Anforderungen während des gesamten Lebenszyklus des Projekts haben, ist der Erfolg konstant und Sie behalten die kontinuierliche Qualität bei. Darüber hinaus ist der Prozess für alle Beteiligten reibungsloser und mit weniger Reibung und Frustration verbunden.

Note- Untersuchungen haben gezeigt, dass Projektteams 50-80% der Projektfehler beseitigen können, indem sie die Anforderungen effektiv verwalten. Laut dem Software-Engineering-Institut von Carnegie Mellon entfallen 60 bis 80 Prozent der Kosten für die Softwareentwicklung auf Nacharbeiten.

Anforderungsabmeldung erhalten

Die Anforderungsunterzeichnung formalisiert die Vereinbarung der Projektbeteiligten, dass der Inhalt und die Darstellung der Anforderungen, wie dokumentiert, korrekt und vollständig sind. Eine formelle Vereinbarung verringert das Risiko, dass ein Stakeholder während oder nach der Implementierung eine neue (bisher nicht angetroffene) Anforderung einführt.

Das Abrufen der Anforderungsfreigabe umfasst in der Regel eine persönliche abschließende abschließende Überprüfung der Anforderungen, wie dokumentiert, mit jedem Projektbeteiligten. Am Ende jeder Überprüfung wird der Stakeholder gebeten, das überprüfte Anforderungsdokument offiziell zu genehmigen. Diese Genehmigung kann entweder physisch oder elektronisch aufgezeichnet werden.

Das Abrufen der Anforderungsfreigabe ist normalerweise die letzte Aufgabe in der Anforderungskommunikation. Der Business Analyst benötigt die Ausgabe der Überprüfung (en) der formalen Anforderungen, einschließlich der Berücksichtigung von Kommentaren oder Einwänden, die während des Überprüfungsprozesses erhoben wurden.

Geschäftsanalyse - Modellierung

Ein Geschäftsmodell kann als Darstellung eines Geschäfts oder einer Lösung definiert werden, die häufig eine grafische Komponente sowie unterstützenden Text und Beziehungen zu anderen Komponenten enthält. Wenn wir beispielsweise das Geschäftsmodell eines Unternehmens verstehen müssen, möchten wir folgende Bereiche untersuchen:

  • Grundwerte des Unternehmens
  • Was dient es?
  • Was zeichnet aus?
  • Seine wichtigsten Ressourcen
  • Wichtige Beziehungen
  • Seine Lieferkanäle

Mithilfe von Modellierungstechniken können wir eine vollständige Beschreibung der vorhandenen und vorgeschlagenen Organisationsstrukturen, Prozesse und Informationen erstellen, die vom Unternehmen verwendet werden.

Das Geschäftsmodell ist ein strukturiertes Modell, genau wie eine Blaupause für das zu entwickelnde Endprodukt. Es gibt Struktur und Dynamik für die Planung. Es bildet auch die Grundlage für das Endprodukt.

Zweck der Geschäftsmodellierung

Die Geschäftsmodellierung wird verwendet, um den aktuellen und zukünftigen Status eines Unternehmens zu entwerfen. Dieses Modell wird vom Business Analyst und den Stakeholdern verwendet, um sicherzustellen, dass sie das aktuelle Ist-Modell des Unternehmens genau verstehen.

Es wird verwendet, um zu überprüfen, ob die Stakeholder ein gemeinsames Verständnis für das vorgeschlagene „Zukünftige der Lösung“ haben.

Die Analyse von Anforderungen ist Teil des Geschäftsmodellierungsprozesses und bildet den Schwerpunktbereich. Funktionsanforderungen werden im „aktuellen Zustand“ erfasst. Diese Anforderungen werden von den Stakeholdern in Bezug auf die Geschäftsprozesse, Daten und Geschäftsregeln bereitgestellt, die die gewünschte Funktionalität beschreiben, die im zukünftigen Zustand entworfen wird.

Durchführen einer GAP-Analyse

Nach der Definition der Geschäftsanforderungen muss der aktuelle Status (z. B. aktuelle Geschäftsprozesse, Geschäftsfunktionen, Merkmale eines aktuellen Systems und der angebotenen Dienste / Produkte sowie Ereignisse, auf die das System reagieren muss) ermittelt werden, um zu verstehen, wie Personen, Prozesse und Technologien strukturiert sind und Architektur unterstützen das Geschäft, indem sie Input von IT-Mitarbeitern und anderen verwandten Stakeholdern, einschließlich Geschäftsinhabern, einholen.

Anschließend wird eine Lückenanalyse durchgeführt, um festzustellen, ob eine Lücke vorliegt, die die Erfüllung der Geschäftsanforderungen verhindert, indem der identifizierte aktuelle Status mit den gewünschten Ergebnissen verglichen wird.

Wenn es keine Lücke gibt (dh der aktuelle Status ist ausreichend, um die Geschäftsanforderungen und gewünschten Ergebnisse zu erfüllen), ist es wahrscheinlich nicht erforderlich, das IT-Projekt zu starten. Andernfalls sollten die Probleme / Probleme identifiziert werden, die angegangen werden müssen, um die Lücke zu schließen.

Techniken wie SWOT-Analyse (Stärken, Schwächen, Chancen und Bedrohungen) und Dokumentenanalyse können verwendet werden.

Bewertung des vorgeschlagenen Systems

BA sollte das IT-Projektteam bei der Bewertung des vorgeschlagenen IT-Systems unterstützen, um sicherzustellen, dass es den Geschäftsanforderungen entspricht und die den Stakeholdern gelieferten Werte maximiert. BA sollte auch die Bereitschaft der Organisation überprüfen, den Übergang zum vorgeschlagenen IT-System zu unterstützen, um eine reibungslose Systemimplementierung sicherzustellen.

BA sollte dem IT-Projektteam helfen, festzustellen, ob die vorgeschlagene Systemoption und das Systemdesign auf hoher Ebene die Geschäftsanforderungen erfüllen und genügend Geschäftswert liefern können, um die Investition zu rechtfertigen. Wenn es mehr als eine Systemoption gibt, sollte BA mit den IT-Mitarbeitern zusammenarbeiten, um die Vor- und Nachteile jeder Option zu ermitteln und die Option auszuwählen, die den größten Geschäftswert bietet.

Leitprinzipien für die Geschäftsmodellierung

Die Hauptaufgabe der Geschäftsmodellierung liegt hauptsächlich in der Anfangsphase und in der Ausarbeitungsphase des Projekts und verblasst während der Bau- und Übergangsphase. Dies betrifft hauptsächlich analytische Aspekte des Geschäfts in Verbindung mit der technischen Zuordnung der Anwendung oder Softwarelösung.

  • Domain and User variation- Die Entwicklung eines Geschäftsmodells zeigt häufig Bereiche der Uneinigkeit oder Verwirrung zwischen den Stakeholdern. Der Business Analyst muss die folgenden Variationen im Ist-Modell dokumentieren.

  • Multiple work units perform the same function- Dokumentieren Sie die Abweichungen im AS-IS-Modell. Dies können unterschiedliche Abteilungen oder Regionen sein.

  • Multiples users perform the same work- Verschiedene Stakeholder können ähnliche Arbeiten unterschiedlich ausführen. Die Abweichung kann das Ergebnis unterschiedlicher Fähigkeiten und Ansätze verschiedener Geschäftsbereiche oder das Ergebnis unterschiedlicher Bedürfnisse externer Stakeholder sein, die vom Unternehmen betreut werden. Dokumentieren Sie die Abweichungen im AS-IS-Modell.

  • Resolution Mechanism- Der Business Analyst sollte dokumentieren, ob die ToBe-Lösung die Inkonsistenzen im aktuellen Geschäftsmodell berücksichtigt oder ob die Lösung standardisiert werden muss. Die Interessengruppen müssen festlegen, welcher Ansatz verfolgt werden soll. Das To-Be-Modell wird ihre Entscheidung widerspiegeln.

Beispiel für eine BA-Rolle bei der Modellierung von ERP-Systemen

Ein Business Analyst soll einen Standard-Geschäftsprozess definieren und in ein ERP-System einbauen, das für eine effiziente Implementierung von zentraler Bedeutung ist. Es ist auch die Pflicht eines BA, die Sprache der Entwickler vor der Implementierung in verständlicher Sprache zu definieren und dann Best Practices zu verwenden und sie basierend auf den Systemfähigkeiten zuzuordnen.

Eine Anforderung an das System ist die GAAP-Anpassungsanalyse, die zwischen -

  • Die Notwendigkeit der technischen Änderungen, die die Verbesserungen sind, um Identität mit der bestehenden Praxis zu erreichen.

  • Effektive Änderungen, die sich auf das Re-Engineering bestehender Geschäftsprozesse beziehen, um die Implementierung der Standardfunktionalität und die Anwendung von Prozessmodellen zu ermöglichen.

Functional Business Analyst

Domain-Know-how wird in der Regel über einen bestimmten Zeitraum erworben, indem Sie im „Geschäft“ tätig sind. Zum Beispiel,

  • EIN banking associate erlangt Kenntnisse über verschiedene Arten von Konten, die ein Kunde (Einzelperson und Unternehmen) zusammen mit einem detaillierten Geschäftsprozessablauf betreiben kann.

  • Ein insurance sales representative kann die verschiedenen Phasen der Beschaffung einer Versicherungspolice verstehen.

  • EIN marketing analyst hat mehr Chancen, die wichtigsten Stakeholder und Geschäftsprozesse eines Customer Relationship Management-Systems zu verstehen.

  • Ein Business Analyst, der an capital marketsDas Projekt soll über Fachkenntnisse und fundierte Kenntnisse in den Bereichen Aktien, festverzinsliche Wertpapiere und Derivate verfügen. Es wird auch erwartet, dass er sich mit Backoffice, Frontoffice und praktischer Exposition bei der Anwendung von Risikomanagementmodellen befasst hat.

  • EIN Healthcare Business Analyst Grundlegendes Verständnis der Finanz- und Nutzungsmetriken des US-Gesundheitswesens, technische Erfahrung und Verständnis von EDI 837/835/834, HIPAA-Richtlinien, ICD-Kodifizierung - 9/10 und CPT-Codes, LOINC, SNOMED-Kenntnisse.

Einige Geschäftsanalysten erwerben Domänenwissen, indem sie Geschäftsanwendungen testen und mit den Geschäftsbenutzern zusammenarbeiten. Sie schaffen durch ihre zwischenmenschlichen und analytischen Fähigkeiten eine förderliche Lernumgebung. In einigen Fällen ergänzen sie ihr Domain-Wissen durch einige Domain-Zertifizierungen, die von AICPCU / ​​IIA und LOMA im Bereich Versicherungen und Finanzdienstleistungen angeboten werden. Es gibt andere Institute, die Zertifizierungen in anderen Bereichen anbieten.

Andere Hauptaktivitäten

Nach einer gründlichen Prüfung der aktuellen Geschäftsprozesse können Sie hochprofessionelle Unterstützung bei der Ermittlung des optimalen Ansatzes für die Modellierung des Systems anbieten.

  • Organisation der Erstellung einer formalisierten und einheitlichen Beschreibung von Geschäftsprozessen in einer Weise, die eine effiziente Automatisierung im System gewährleistet.

  • Unterstützung Ihrer Teams beim Ausfüllen von Standardfragebögen für das betreffende System, die möglicherweise von den Entwicklern bereitgestellt werden.

  • Die Anforderungen an die Teilnahme an Arbeitstreffen gegenüber den Entwicklern sind definiert.

  • Überprüfen und kontrollieren Sie, ob die von Ihnen festgelegten Anforderungen ordnungsgemäß „reproduziert“ und in den Dokumenten aufgezeichnet wurden, die das zukünftige Modell im System beschreiben (Blaupausen).

  • Datenaufbereitung und Unterstützung beim Prototyping des Systems.

  • Unterstützung bei der Vorbereitung von Daten für die Migration von Listen und Salden in dem vom System geforderten Format.

  • Überprüfung des Setup-Prototyps auf Einhaltung der von den Geschäftsprozessverantwortlichen festgelegten Anforderungen.

  • Als Support-Ressource für Ihre IT-Teams bei der Vorbereitung von Daten und der tatsächlichen Durchführung von Funktions- und Integrationstests im System.

Im nächsten Abschnitt werden einige der beliebten Business Modeling Tools, die von großen Unternehmen in IT-Umgebungen verwendet werden, kurz erläutert.

Tool 1: Microsoft Visio

MS-Visio ist eine Zeichen- und Diagrammsoftware, mit der Konzepte in eine visuelle Darstellung umgewandelt werden können. Visio bietet Ihnen vordefinierte Formen, Symbole, Hintergründe und Rahmen. Ziehen Sie einfach Elemente per Drag & Drop in Ihr Diagramm, um ein professionelles Kommunikationswerkzeug zu erstellen.

Step 1 - Um eine neue Visio-Zeichnung zu öffnen, gehen Sie zum Startmenü und wählen Sie Programme → Visio.

Step 2 - Bewegen Sie den Mauszeiger über "Geschäftsprozess" und wählen Sie "Grundlegendes Flussdiagramm".

Der folgende Screenshot zeigt die Hauptabschnitte der MS-Visio-Anwendung.

Lassen Sie uns nun den grundlegenden Nutzen jeder Komponente diskutieren -

A- Die Symbolleisten am oberen Bildschirmrand ähneln anderen Microsoft-Programmen wie Word und PowerPoint. Wenn Sie diese Programme bereits verwendet haben, werden Sie möglicherweise einige verschiedene Funktionen bemerken, die wir später untersuchen werden.

Die Auswahl der Hilfediagrammgalerie ist eine gute Möglichkeit, sich mit den Arten von Zeichnungen und Diagrammen vertraut zu machen, die in Visio erstellt werden können.

B- Auf der linken Seite des Bildschirms werden die Menüs angezeigt, die für den von Ihnen erstellten Diagrammtyp spezifisch sind. In diesem Fall sehen wir -

  • Pfeilformen
  • Backgrounds
  • Grundlegende Flussdiagrammformen
  • Grenzen und Titel

C - In der Mitte des Bildschirms wird der Diagrammarbeitsbereich angezeigt, der die eigentliche Diagrammseite sowie einige Leerzeichen neben der Seite enthält.

D- Auf der rechten Seite des Bildschirms werden einige Hilfefunktionen angezeigt. Einige Benutzer schließen dieses Fenster möglicherweise, um den Bereich für den Diagrammarbeitsbereich zu vergrößern, und öffnen die Hilfefunktionen bei Bedarf erneut.

Tool 2: Enterprise Architect

Enterprise Architect ist ein visuelles Modellierungs- und Designtool, das auf UML basiert. Die Plattform unterstützt den Entwurf und die Konstruktion von Softwaresystemen, die Modellierung von Geschäftsprozessen und die Modellierung branchenbasierter Domänen. Es wird von Unternehmen und Organisationen verwendet, um nicht nur die Architektur ihrer Systeme zu modellieren. Die Implementierung dieser Modelle wird jedoch über den gesamten Lebenszyklus der Anwendungsentwicklung hinweg verarbeitet.

Mit dem Enterprise Architect soll ermittelt werden, wie ein Unternehmen seine aktuellen und zukünftigen Ziele am effektivsten erreichen kann.

Der Unternehmensarchitekt hat vier Gesichtspunkte:

  • Business perspective - Die Geschäftsperspektive definiert die Prozesse und Standards, nach denen das Geschäft täglich arbeitet.

  • Application Perspective - Die Anwendungsperspektive definiert die Interaktionen zwischen den von der Organisation verwendeten Prozessen und Standards.

  • Information Perspective - Hiermit werden die Rohdaten wie Dokumentdateien, Datenbanken, Bilder, Präsentationen und Tabellen definiert und klassifiziert, die das Unternehmen für einen effizienten Betrieb benötigt.

  • Technology Prospective - Dies definiert die Hardware, Betriebssysteme, Programmier- und Netzwerklösungen, die von der Organisation verwendet werden.

Tool 3: Rational Requisite Pro

Der Prozess des Ermittelns, Dokumentierens, Organisierens, Verfolgens und Änderns von Anforderungen und Übermitteln dieser Informationen an die Projektteams, um sicherzustellen, dass iterative und unerwartete Änderungen während des gesamten Projektlebenszyklus beibehalten werden.

Überwachen des Status und Steuern von Änderungen an der Anforderungsbasislinie. Die Hauptelemente sind Änderungskontrolle und Rückverfolgbarkeit.

Requisite Pro wird für die oben genannten Aktivitäten und Projektverwaltungszwecke verwendet. Das Tool wird zum Abfragen und Suchen sowie zum Anzeigen der Diskussion verwendet, die Teil der Anforderung war.

In Requisite Pro kann der Benutzer das Anforderungsdokument bearbeiten. Das Dokument ist eine MS-Word-Datei, die in der Reqpro-Anwendung erstellt und in die Projektdatenbank integriert wurde. Anforderungen, die außerhalb von Requisite Pro erstellt wurden, können importiert oder in das Dokument kopiert werden.

In Requisite Pro können wir auch mit Rückverfolgbarkeit arbeiten. Hier handelt es sich um eine Abhängigkeitsbeziehung zwischen zwei Anforderungen. Die Rückverfolgbarkeit ist ein methodischer Ansatz zur Verwaltung von Änderungen durch Verknüpfung miteinander verbundener Anforderungen.

Mit Requisite Pro können Sie Änderungen an einer Anforderung während des gesamten Entwicklungszyklus einfach nachverfolgen. Daher müssen Sie nicht alle Dokumente einzeln überprüfen, um festzustellen, welche Elemente aktualisiert werden müssen. Sie können verdächtige Beziehungen mithilfe einer Rückverfolgbarkeitsmatrix oder einer Rückverfolgbarkeitsbaumansicht anzeigen und verwalten.

Mit Requisite Pro-Projekten können wir ein Projekt-Framework erstellen, in dem die Projektartefakte organisiert und verwaltet werden. In jedem Projekt sind die folgenden enthalten.

  • Allgemeine Projektinformationen
  • Packages
  • Allgemeine Dokumentinformationen
  • Dokumenttypen
  • Anforderungsarten
  • Anforderungsattribute
  • Attributwerte
  • Projektübergreifende Rückverfolgbarkeit

Mit Requisite Pro können mehrere Benutzer gleichzeitig auf dieselben Projektdokumente und Datenbanken zugreifen. Daher ist der Aspekt der Projektsicherheit von entscheidender Bedeutung. Die Sicherheit verhindert die Systemnutzung, potenzielle Schäden oder Datenverluste durch unbefugten Benutzerzugriff auf ein Projektdokument.

Es wird empfohlen, die Sicherheit für alle RequisitePro-Projekte zu aktivieren. Auf diese Weise wird sichergestellt, dass alle Änderungen am Projekt mit dem richtigen Benutzernamen der Person verknüpft sind, die die Änderung vorgenommen hat, wodurch sichergestellt wird, dass Sie über einen vollständigen Prüfpfad für alle Änderungen verfügen.