Der umfassendste Leitfaden für Anforderungsmanagement und Rückverfolgbarkeit
Die Do's and Dont's für Schreibanforderungen
Inhaltsverzeichnis
Wenn Sie wie die meisten Menschen sind, haben Sie wahrscheinlich keine Freude daran, Anforderungen zu schreiben. Es ist nicht die aufregendste Sache der Welt, aber es ist ein kritischer Teil der Produktentwicklung. Ein besseres Anforderungsdokument kann Ihrer Organisation durch eine klare Kommunikation zwischen dem Entwickler und den Produktbeteiligten ein Vermögen sparen. Dies wiederum spiegelt sich im gesamten Unternehmen wider, einschließlich größerer Transparenz, geringerer Nacharbeit und verbesserter Produktivität.
Während jede Organisation unterschiedliche Anforderungen und Methoden hat, bleiben die Grundlagen für das Schreiben von Anforderungen gleich. In diesem Artikel geben wir einige Tipps, die Ihnen helfen können, Ihre Fähigkeiten zum Schreiben von Anforderungen zu verbessern und klare und präzise Anforderungsspezifikationen zu schreiben.
Was ist eine Anforderungsspezifikation?
Die Anforderungsspezifikation, auch Dokumentation genannt, ist ein Prozess, bei dem alle System- und Benutzeranforderungen in Form eines Dokuments festgehalten werden. Diese Anforderungen müssen klar, vollständig, umfassend und konsistent sein.
Während der Erfassungsaktivität sammeln wir alle Anforderungen aus verschiedenen Quellen. Während der Analyse- und Verhandlungsaktivitäten analysieren und verstehen wir diese Anforderungen. Jetzt müssen wir ein formelles Dokument erstellen, in dem diese Anforderungen erläutert werden. Das ist die Anforderungsspezifikation. Genauer gesagt handelt es sich um den Prozess, alle Benutzer- und Systemanforderungen und -beschränkungen klar und genau zu dokumentieren.
Was bedeuten „Best Practices“ im Anforderungsmanagement?
Es ist so interessant für mich, dass alle davon sprechen, sich in „Best Practices“ ausbilden zu lassen. Dieser Begriff wird oft verwendet, um die Art der Beratung zu beschreiben, die wir auch anbieten können. Was bedeutet das wirklich? Ich glaube, wir alle haben uns mit dem Mythos beschäftigt, dass Best Practices die Grundlage für die Schulung von Einzelpersonen sein können. Best Practices werden nicht trainiert, sondern erfahren.
Wenn wir den Best-Practice-Ansatz mit der Natur vergleichen, wissen wir, dass nicht nur die stärksten, sondern auch die produktivsten Arten überleben. Das ist einer der Gründe, warum es so schwierig ist, Prozesse in einer Organisation zu ändern. Denken Sie einen Moment darüber nach. Die stärksten und produktivsten beschreiben wahrscheinlich die Mehrheit der Personen, die Sie in fast jeder Gruppe in Ihrer Organisation haben. Das habe ich im Bereich System Engineering immer wieder erlebt. Die stärksten und produktivsten Ingenieure machen ihren Job oft seit vielen Jahren und haben eine bestimmte Art, wie sie diesen Job machen. Sie zu bitten, neue Techniken und Werkzeuge auszuprobieren, ist oft zwecklos, da sie nicht wissen, wie dies ihre ohnehin schon wunderbare Arbeit verbessern wird. Ihre Praxis wird überleben, wenn wir ihnen weiterhin einen Best-Practice-Ansatz aufzwingen.
Herausforderungen beim Schreiben von Anforderungen
Es gibt verschiedene Herausforderungen, denen Menschen beim Schreiben von Anforderungen gegenüberstehen.
Schlechter Papierkram – In einigen Organisationen ist die Dokumentation von Prozessen entweder nicht vorhanden oder nicht zeitgemäß. In diesem Fall wird das Sammeln von Anforderungen zu einem zweistufigen Prozess: zuerst das Reverse Engineering des bestehenden Prozesses und dann die Identifizierung von Bereichen, die verbessert und optimiert werden müssen. Um zu bestätigen, dass die Anforderungen konkretisiert und genau sind, ist es wichtig, die wichtigsten Stakeholder und Fachexperten zu identifizieren und direkt mit ihnen in Kontakt zu treten. Das Zeichnen von Geschäftsprozesskarten und das Visualisieren von Arbeitsabläufen sind zwei hervorragende Möglichkeiten, dies zu tun. Dies hilft bei der Eliminierung falscher Annahmen und liefert gleichzeitig ein vollständiges Bild. Das Zeichnen von Prozesslandkarten und das Anzeigen von Prozessen sind zwei nützliche Ansätze für diesen Zweck.
Widersprüchliche Anforderungen – Wenn Stakeholder unterschiedliche Prioritäten für ihre Geschäftsziele haben, führt dies zu widersprüchlichen Anforderungen. In solchen Fällen ist es die Aufgabe eines Business Analysten, alle Anforderungen detailliert zu dokumentieren, zu identifizieren, welche Anforderungen einander entgegenstehen, und den Beteiligten die Möglichkeit zu geben, zu entscheiden, was Priorität hat.
Sie können keine Entscheidungen treffen, ohne den Input der Stakeholder zu hören, und als Business Analyst haben Sie möglicherweise einige Ideen dazu, was priorisiert werden sollte. Es ist immer noch entscheidend, die Perspektive der Interessenvertreter zu hören. Das Einrichten einer Umfrage könnte eine der Methoden sein, um Klarheit darüber zu erhalten, was für die Mehrheit der Interessengruppen am wichtigsten ist.
Nichtverfügbarkeit der Benutzereingabe – Einige Gründe können zur Nichtverfügbarkeit von Endbenutzern beitragen, und jeder erfordert seine eigene Lösung. Beispielsweise sind Endbenutzer manchmal so mit ihrer täglichen Arbeit beschäftigt, dass sie nicht bereit sind, an Aktivitäten zum Sammeln von Anforderungen teilzunehmen.
In solchen Fällen ist das Beste, was ein Business Analyst tun kann, die Anzahl und Dauer der Engagements zu begrenzen. Vor dem Treffen hilft es, so viel Recherche wie möglich zu betreiben, um die Diskussion organisierter und informativer zu gestalten. Es ist fast so, als würde man das Sammeln von Anforderungen in Sitzungen zur Anforderungsvalidierung umwandeln. Definieren von Fokusgruppen und Identifizieren der am besten geeigneten Endbenutzer für jede Gruppe
Fokus auf Interface statt Experience – Viele Stakeholder und Endnutzer haben eine klare Vorstellung davon, wie die neue Lösung aussehen soll, wissen aber nicht, was sie leisten soll. Die Benutzeroberfläche eines jeden Systems ist entscheidend, aber sie sollte die Funktionalität nicht definieren oder beeinträchtigen.
Business-Analysten sollten immer daran denken, Design- und Funktionsanforderungen in ihrer Dokumentation getrennt zu halten. Durch die Verwendung allgemeinerer Tools wie Diagramme, User Stories oder Low-Fi-Prototypen anstelle von Designentwürfen können sie sich auf die funktionalen Aspekte der Anforderungserfassung konzentrieren.
Stakeholder-Eingaben – Wenn Interessengruppen oder Endbenutzer versuchen, Designern zu sagen, wie das System funktionieren soll, anstatt zu sagen, was das System tun soll, kann dies zu suboptimalen Designs führen. Um dem vorzubeugen, validieren Sie jede mögliche „falsche Anforderung“, indem Sie nach dem „Warum“ fragen. bis Sie zu dem eigentlichen Problem kommen, das gelöst werden muss.
Kommunikationsprobleme – Zu den Problemen, die zu Missverständnissen zwischen einem Business Analyst und anderen Parteien führen können, gehören Sprachbarrieren, falsche Annahmen, unzureichend erklärter Wortschatz und die übermäßige Verwendung von Fachbegriffen.
Der ideale Ansatz, um dieses Problem zu vermeiden, besteht darin, häufig zu interagieren und wechselseitige Gespräche zu führen. Dokumentieren Sie die Bedürfnisse, die Sie entdeckt haben, und reichen Sie sie zur Begutachtung und Kritik an eine Vielzahl von Fachspezialisten ein, erstellen Sie ein Glossar mit Fachjargon und überprüfen Sie Prämissen doppelt.
10 Gebote und Verbote beim Schreiben von Anforderungen:
Mach Nr. 1. Eins nach dem anderen – Jede Anforderung sollte als separater Testfall behandelt werden. Konjunktionen wie und, oder usw. sollten nicht verwendet werden, da sie dazu führen könnten, dass Anforderungen übersehen werden. Dies ist besonders wichtig, da Begriffe wie diese dazu führen können, dass Softwareentwickler und Tester Anforderungen übersehen. Das Aufteilen komplizierter Anforderungen in kleinere Teile, bis jede separat getestet werden kann, ist eine Möglichkeit, dies zu verhindern.
Nicht Nr. 1. Sprechen Sie „Was“, nicht „Wie“ – Der Fokus sollte darauf liegen, was das System tut, nicht wie es es tut. Vermeiden Sie es außerdem, zu tief in Entwurfsthemen wie Feldnamen, Programmiersprachenobjekte und Softwareobjekte einzutauchen. Wenn Sie diese Themen im Anforderungsspezifikationsdokument diskutieren, treten Sie einen Schritt zurück – das bedeutet wahrscheinlich, dass Sie zu spezifisch werden.
Mach Nr. 2. Rückverfolgbarkeit – Rückverfolgbarkeit im Projektmanagement bezieht sich auf die Sicherstellung, dass Anforderungen mit anderen Komponenten im Projekt verknüpft sind. Dies ermöglicht Projektmanagern, Entwicklern und Stakeholdern, den gesamten Lebenszyklus einer Anforderung von Anfang bis Ende in alle Richtungen sowie mit anderen Teilen des Systems zu verfolgen. Wenn Sie die Rückverfolgbarkeit richtig verwalten, können Sie Code vermeiden, der keiner Anforderung entspricht („streunender“ Code), und sicherstellen, dass jeder Testfall mindestens eine Anforderung abdeckt. Sie können Anforderungen nachvollziehbar machen, indem Sie sie mit einer eindeutigen Kennung versehen und Informationen über ihre Quelle in einem zentralen Repository bereitstellen, das allen Teammitgliedern zugänglich ist.
Nicht Nr. 2. Keine Ausnahmen – Eine Anforderung sollte keine Ausweichklausel haben. Zum Beispiel: „Das System bestimmt die Anzahl der Anmeldeversuche, außer wenn der Benutzer eindeutig einen falschen Benutzernamen eingegeben hat“.
Mach Nr. 3. Möglich – Stellen Sie sicher, dass das Projektbudget und der Zeitplan sowie die verfügbaren Ressourcen realisierbar sind. Wenn diese Bedingung die Anforderung unterstützen kann, ist es möglich, mit dem Plan fortzufahren.
Nicht Nr. 3. Sagen Sie Nein zu „ausgelassenen“ Klauseln – Versuchen Sie, sich von ausgelassenen Sätzen wie aber, außer und nur dann fernzuhalten, wenn es nötig ist.
Mach Nr. 4. Konsistenz – Behalten Sie einen konsistenten Detaillierungsgrad bei. Beispielsweise sollte bei Benutzeranforderungen ein Endbenutzer das Thema jedes Satzes sein. In ähnlicher Weise sollte bei Systemanforderungen ein System das Thema jedes Satzes sein.
Nicht Nr. 4. Keine Abkürzungen – Jede Anforderung sollte ein vollständiger Satz ohne Akronyme oder Jargon sein.
Mach Nr. 5. Aktive Stimme – Schreiben Sie immer mit aktiver Stimme und stellen Sie sicher, dass einer der Schauspieler das Thema jedes Satzes ist.
Nicht Nr. 5. Seien Sie nicht zweideutig – Verwenden Sie keine mehrdeutigen Begriffe wie ca. usw., und weitere ähnliche Begriffe im Anforderungsdokument. Achten Sie darauf, die Anforderungen so zu erklären, dass alle Beteiligten sie richtig verstehen. Vage Aussagen können zu Fehlinterpretationen führen und Konflikte zwischen verschiedenen Beteiligten hervorrufen.
Mach Nr. 6. Subjekt & Prädikat – Für jede Anforderung muss es ein Subjekt (Benutzer/System) und ein Prädikat (beabsichtigtes Ergebnis, Aktion oder Bedingung) geben.
Nicht Nr. 6. Spekulationen können Schaden anrichten – Raten Sie nicht; Erstellen Sie keine Listen mit Merkmalen, die nicht in Frage kommen. Zu sagen, Sie möchten, dass ein System alle unerwarteten Ausfälle handhabt, ist reine Fantasie, da kein System jemals zu 100 Prozent so sein wird, wie Sie es sich wünschen. Vermeiden Sie Doppelungen und widersprüchliche Aussagen.
Mach Nr. 7. Überprüfbar – Eine weitere Sache, die Sie bei der Organisation von Anforderungen beachten sollten, ist, dass sie immer testbar sein sollten. Das bedeutet, dass es möglich sein muss, zu überprüfen, ob das System die jeweilige Anforderung erfüllt. Dies knüpft auch an unseren nächsten Punkt an – die Rückverfolgbarkeit. Wenn eine Anforderung voller vager Begriffe ist, wird es schwieriger zu analysieren und zu überprüfen, ob das System diese Standards in Bezug auf die Leistung tatsächlich erfüllt. Streben Sie daher so weit wie möglich nach Klarheit und Präzision in Ihrer Sprache, damit das Sammeln von Anforderungen kein mehrdeutiger Prozess ist.
Nicht Nr. 7. Vermeiden Sie Optionen – Bieten Sie keine Ideen oder Optionen an. Sie können diese in jeder Aussage erkennen, die die Sätze darf, könnte, könnte oder sollte enthält.
Mach Nr. 8. In Ordnung – Stellen Sie sicher, dass jeder Satz vollständig und grammatikalisch korrekt ist, mit einem richtigen Subjekt, Verb und Prädikat.
Nicht Nr. 8. Sprechen Sie nicht im Futurum – Verweisen Sie nicht auf eine noch zu definierende Anforderung. Ihr Ziel ist es, das Dokument so angenehm wie möglich zu lesen.
Mach Nr. 9. Setzen Sie mit Achtsamkeit – Richten Sie den Fokus ein, indem Sie Geschwafel, überlange Phrasen und Verweise auf veraltete Papiere eliminieren.
Nicht Nr. 9. Was soll wo verwendet werden? – „Muss“ sollte verwendet werden, wenn Anforderungen angegeben werden, „Will“ sollte verwendet werden, um Tatsachen darzustellen; & „Sollte“, um ein zu erreichendes Ziel darzustellen.
Mach Nr. 10. Organisierter Papierkram wirkt Wunder – Organisieren Sie Anforderungen an einem Ort, um die Lesbarkeit Ihres Dokuments zu verbessern und Zeitverschwendung durch Querverweise auf mehrere Quellen zu vermeiden.
Nicht Nr. 10. Verwenden Sie keine unbekannten Begriffe – Verwenden Sie keine unbekannten Begriffe wie „benutzerfreundlich, vielseitig und robust“, da dies zu Schwierigkeiten bei der Definition von Testfällen führen kann. Diese Wörter haben oft unterschiedliche Bedeutungen für verschiedene Menschen.
Visure-Anforderungen ALM-Plattform
Visure ist eine der vertrauenswürdigsten Plattformen für das Application Lifecycle Management, die sich auf das Anforderungsmanagement für Unternehmen aller Größen auf der ganzen Welt spezialisiert hat. Zu den wichtigsten Partnern von Visure zählen geschäftskritische und sicherheitskritische Unternehmen. Das Unternehmen integriert die gesamten Application Lifecycle Management-Prozesse, einschließlich Risikomanagement, Problem- und Fehlerverfolgung, Rückverfolgbarkeitsmanagement, Änderungsmanagement und verschiedene andere Bereiche wie Qualitätsanalyse, Anforderungsversionierung und leistungsstarke Berichterstattung.
Wenn Sie nach einem Anforderungsmanagement-Tool suchen, das Ihnen sowohl bei funktionalen als auch bei nicht funktionalen Anforderungen hilft, sehen Sie sich Visure Requirements an. Mit dieser Plattform können Sie alle Anforderungen Ihres Projekts einfach an einem Ort erstellen, verwalten und verfolgen.
Zusammenfassung
Die Anforderungsspezifikation ist ein kritischer Prozess in der Softwareentwicklung, aber es kann schwierig sein, gute Anforderungen zu schreiben. Die 20 Tipps, die wir bereitgestellt haben, sollen Ihnen dabei helfen, bessere Anforderungen zu schreiben und den Prozess für alle Beteiligten reibungsloser zu gestalten. Wenn Sie das Schreiben Ihrer Anforderungen auf die nächste Stufe heben möchten, sollten Sie die Verwendung eines Tools wie Visure Requirements ALM Platform in Betracht ziehen. Anfrage a Kostenlose 30-Tage-Testversion Informieren Sie sich noch heute, wie unsere Plattform Ihnen dabei helfen kann, Ihre Anforderungserfassungs- und -verwaltungsprozesse zu rationalisieren.
Vergiss nicht, diesen Beitrag zu teilen!
