Spezifikation der Systemanforderungen und ihre wichtigsten Komponenten

Die Tätigkeit eines Business Analysten in einem IT-Unternehmen ist unabdingbar, um mit den letzten technologischen Neuerungen der Branche und ihren Markttrends Schritt zu halten und für die beliebte und anerkannte Forschung in der Branche bekannt zu sein. Die Kenntnis der grundlegenden Regeln, Methoden und Instrumente der BA ist jedoch nicht weniger wichtig. Besonders, wenn Sie gerade erst angefangen haben...

Eine der Haupttätigkeiten eines BA ist die Arbeit mit Anforderungen. Auf der einen Seite kommuniziert der BA mit den Stakeholdern oder dem Product Owner und sammelt deren Geschäftsanforderungen. Auf der anderen Seite muss der BA Softwareanforderungen für die Entwickler entwickeln. Bei der Arbeit mit Informationen ist es wichtig, alle notwendigen Artefakte zu sammeln, Informationen zu verarbeiten und in verschiedenen Arten von Dokumenten zu systematisieren. Es gibt drei Arten von Anforderungsdokumenten in Bezug auf die Ebene ihres Kontexts:

• Geschäftsanforderungsdokument (BRD)
• Software-Anforderungsspezifikation (SRS)
• Funktionale Anforderungsspezifikation (FRS)

Geschäftliches Anforderungsdokument

Das Business Requirement Document (BRD) ist ein übergeordnetes Dokument. Das BRD enthält die Hauptidee des IT-Projekts und beantwortet die "WARUM"-Frage nach dem Ziel des Projekts als Geschäftsidee. Das BRD wird von Stakeholdern, Investoren, Top-Managern, mittleren Managern und Analytikern des Projekts verwendet.

Software-Anforderungsspezifikation

Die Software-Anforderungsspezifikation (SRS) ist ein Dokument der mittleren Ebene. Die SRS beantwortet die Frage nach dem "WIE" und beschreibt die grundlegende Struktur und den Stand der Projektimplementierung. Dieses Dokument wird von Product Owner, Projektmanager und Tech Lead verwendet.

Funktionale Anforderungsspezifikation

Die funktionale Anforderungsspezifikation (FRS) ist ein detailliertes Entwicklungsdokument. Es beschreibt, "WAS" zu tun ist, um die erwarteten Ergebnisse zu erzielen. FRD wird von Geschäftsanalysten, Systemanalysten, QA-Ingenieuren und Entwicklerteams verwendet.

SRS-Struktur

Schenken wir der SRS als "Brücke" zwischen einer Geschäftsidee und ihrer Umsetzung mehr Aufmerksamkeit. SRS umfasst:

den Architekten des Projekts mit eindeutigen visuellen Mockups

• High-Level-Prozessdiagramme;
• eine Beschreibung anderer notwendiger IT-Systeme für die Synchronisation und Kooperation;
• die Teamstruktur;
• Bedingungen für die Implementierung. 
• Er beschreibt die funktionalen und nicht-funktionalen Anforderungen. SRS ist ein detaillierter Plan, der genügend Informationen für die Budgetberechnung liefert.

Die wichtigsten Bestandteile der SRS sind:

1. Intro. Beschreibung des Zwecks des Dokuments, Art und Weise der Umsetzung der Geschäftsidee, Arbeitsumfang, Überblick über ein zukünftiges Produkt.
2. Allgemeine Beschreibung des Projekts, seines Architekten, der Funktionen, der Benutzereigenschaften, des Marktes, der Merkmale und der Vorteile.
3. Funktionale Anforderungen. Die erwarteten Ergebnisse des Softwaresystems werden durch Diagramme, Anwendungsfälle, Mockups und andere geeignete Instrumente vollständig erläutert. Überblick über den Datenbankarchitekten, seine Verarbeitung. Die Entwicklungsphasen und -fristen werden geordnet und geplant.
4. Nicht-funktionale Anforderungen werden beschrieben, wie z.B. die Frage der Systemsicherheit. Seine stabile Arbeit unter Online- und Offline-Bedingungen.
5. Schnittstellenanforderungen, die die Art und Weise der Kommunikation zwischen dem zukünftigen Produkt und anderen verwandten Systemen, zwischen Produkt und Benutzern erklären.
6. Budget und Zeitplan. Der Arbeitsumfang ist eine grundlegende Information für die Budgetberechnung. Natürlich hängt er auch von der Anzahl und dem Erfahrungsstand des Entwickler- und QS-Teams ab. Außerdem bietet er die Möglichkeit, die Phasen der Projektdurchführung zu planen.
7. Anhang. Beschreibung von Begriffen, Akronymen und anderen spezifischen Informationen werden als Referenzen gesammelt und erläutert.

Die wichtigsten Grundsätze der SRS-Dokumentation sind:

• Klarheit der Definition 
• Einzigartigkeit des Kontexts 
• logische Abfolge in der Darstellung
• Eindeutigkeit der Zweckbestimmung
• Prägnanz 
• Die Art der Erfassung und Präsentation von SRS-Dokumenten ist von großer Bedeutung. Einerseits sollte sie für die Benutzer bequem und einfach sein. Auf der anderen Seite ist die Frage des Informationszugangs und der Sicherheit aktuell. Es gibt eine Vielzahl von Möglichkeiten - Confluens, Google docs, Quip, Coda, etc.

In der Zwischenzeit spielt das Wissen des Business Analysten über den Fachbereich eine wichtige Rolle. Das Verständnis der Geschäftsprozesse auf höchster Ebene und der Markttrends hilft, das Risiko von Fallstricken zu vermeiden und die Zeit für die Untersuchung zu verkürzen. Außerdem ist ein tiefes Verständnis des Fachgebiets von Vorteil, wenn es darum geht, die Erwartungen der Benutzer, die UI/ UX und die Quelle der Produkthypothese zu verstehen. 

Je aufmerksamer und detaillierter das SRS-Dokument ist, desto klarer und verständlicher ist der Arbeits- und Aktionsplan. Und kurzfristige Ziele und strategische Zwecke sind in einem Zeitrahmen besser erreichbar.

Software Development Hub ist ein Team von Gleichgesinnten mit breiter Erfahrung in der Softwareentwicklung, Web- und Mobile Engineering. Wir bieten unseren Kunden einen umfassenden, kundenspezifischen Entwicklungszyklus, einschließlich Architekturplanung, Geschäftsanalyse für Kunden, UI/UX-Design, Qualitätskontrolle, Projektmanagement und Support.

Categories