Requirements für Newssystem erfassen
11. Juni 2009 Roland
- Erstellen eines Newssystems
- Akteure im Newssystem
- Newssystem Anwendungsfälle für den Systemadministrator
- Newssystem Anwendungsfälle für den Editor
- Newssystem Anwendungsfälle Zusammenfassung
- Newssystem Anwendungsfälle Webuser
- Anwendungsfall Add Category
- Anwendungsfall Add Editor to Category
- Anwendungsfall Change Editor
- Nebenläufigkeiten beim Editieren von Newseinträgen
- Anwendungsfall Create Editor
- Anwendungsfall Delete Category
- Anwendungsfall Delete Editor
- Anwendungsfall Edit Category
- Anwendungsfall Remove Editor From Category
- Anwendungsfall Show Editors
- Anwendungsfall Show Categories
- Anwendungsfall Add Image to Newsentry
- Anwendungsfall Create Newsentry
- Anwendungsfall Delete Image
- Anwendungsfall Delete Newsentry
- Anwendungsfall Edit Image Data
- Anwendungsfall Edit Newsentry
- Anwendungsfall Navigate in Newslist
- Anwendungsfall Remove Image from Newsentry
- Anwendungsfall Search Image
- Anwendungsfall Search News
- Anwendungsfall Set Presentation Times
- Anwendungsfall Upload Image
- Anwendungsfall Navigate Archive News Shortentries
- Anwendungsfall Navigate Shortentries
- Anwendungsfall Show Archive Newsentry
- Anwendungsfall Show Newsentry
- Anwendungsfall Show Shortentries
- Aufbereiten der bisherigen Anwendungsfälle
- Technische Anwendungsfälle
- Nebenläufigkeiten beim Lesen von Newseinträgen
- Lasst uns mal über Performancemessung reden
- Erste Gedanken zum Backup und Restore für unser Newssystem
- Zwischenschicht zur Performancemessung einbauen
- Performancemessungen ein- und ausschalten
- Performance Messung auf dem Server durchführen
- Newssytem Daten Modellieren
- Anwender Aktionen loggen
- Geschäftsmodelle erkennen
- ImageModel Beschreibung
- Installierbarkeit des Newssystems
- Housekeeping im Newssystem
- Anwendungsfall SearchNotUsedImages
- UserModel Beschreibung
- Meldungsverwaltung und Severity Bestimmung im Newssystem
- UserModelFactory
- Einsatz eines Frameworks für die Erstellung des Newssystems
- Ist das Newssystem einfach nur eine View auf eine Blogsoftware?
- Factory- und Adapter Pattern für die Erweiterung von WordPress
- Wieso will ich das Newssystem nicht als WordPress Plugin erstellen?
- Newssystem gesundschrumpfen
- Wer sind unsere Kunden für das Newssystem?
- Requirements für Newssystem erfassen
- Rahmenbedingungen für das Newssystem
- Entscheidung wie das Newssystem jetzt umgesetzt werden soll
- Welche Tools können wir zur Anforderungsverwaltung einsetzen?
- Verwalten der Anforderungen
- Namensänderungen im Newssystem Modell
- Ein Tool für die Anforderungen
- Komponenten die im ersten Sprint umgesetzt werden sollen
- Auf der Suche nach einem Tool um Anforderungen zu erfassen
- Security fummelt man am Besten gleich in die Architektur hinein
- Security Komponenten Klassendiagramm
- wie schrumpft man das System Gesund?
Für das Newssystem ist mittlerweile sehr viel geschrieben worden.
So ganz aus dem Gefühl heraus würde ich sagen, dass wir noch einiges mehr schreiben werden 
Wenn ich Projekte vorantreibe, habe ich immer ein Requirement Tool.
Requirements, also auf deutsch Anforderungen, beschreiben was von einem System alles erwartet wird.
Wenn du einen Nagel in die Wand treiben willst, hast du Anforderungen an das zu verwendende Werkzeug.
Es soll einen Griff haben mit dem du das Nagel-in-die-Wandtreib Werkzeug halten kannst.
Dann soll es eine Fläche haben mit der du den Nagel treffen willst.
Und dann soll es noch ein ziemliches Eigengewicht haben, damit die vernichtende Massenträgheitenergie den Nagel in seine Wand wuchten kann.
Was für Tools setzte ich normalerweise für die Anforderungssammlung ein?
Wenn es gar nichts gibt, dann nehme ich halt eine Excel Liste und schreibe die Anforderungen da rein.
Wenn ich ein Modelierungswerkeug, wie Enterprise Architect, verwende, dann nutze ich die darin befindlichen Anforderungslisten.
Wenn es gar ein Content Management System gibt, dann nehme ich das.
Beispielsweise können bei ITIL der Incident Manager seine Anforderungen in ein Ticket System eintragen und an den Problem Manager übergeben.
Oder er eröffnet sofort einen Change Antrag. Auch dies kann über das Tickettool laufen.
Was will ich zu jeder Anforderung beschreiben?
Für das Newssystem stelle ich mir vor, dass wir die Anforderungen wie eine Issue List betreiben.
In einer Issue List wird beschrieben was, wie und wann von wem geklärt werden soll.
Unsere Anforderungen beinhalten dann:
Titel
Pro Anforderung wird ein relativ eindeutiger Titel erwartet.
Beispiele:
-
JavaScript wird nicht vorausgesetzt
oder
-
Redakteur kann nur seine Newseinträge editieren
Beschreibung
Ein Text, vielleicht auch mit Bildern falls es die Anforderung leichter beschreibt, mit dem die Anforderung genauer beschrieben wird.
Beispiele:
-
JavaScript kann in jedem Bereich des Newssystems eingesetzt werden um einzelne Abläufe für den Anwender zu vereinfachen.
-
Jede Funktion des Newssystems muss jedoch ohne eingeschaltetes JavaScript durchgeführt werden können.
-
Es dürfen hierdurch keine massiven Einschränkungen der Funktionsweise auftreten.
oder
-
Damit keine fremden Newseinträge verändert werden, dürfen jedem Redakteur nur seine eigenen Newseinträge zur Veränderung angezeigt werden.
Betroffene Komponenten
Wenn eine Anforderung analysiert wurde, ist es voll toll zu wissen welche Komponenten davon betroffen sind. Hier beschreibt man was man alles wie umbauen muss um diese Anforderung zu erfüllen.
Beispiele:
-
Alle Abläufe, alle Views und Controller, sind so anzupassen dass es eine JavaScript und wenn nötig eine JavaScript freie Version gibt.
oder
-
Die Selektion der Newseinträge wird im Newsmodel (siehe XXX) realisiert.
Testfallbeschreibung
Hab ich heute im ITIL Kurs gelernt. Ist doch wirklich sau cool wenn zu den einzelnen Anforderungen gleich noch die Tests festlegt gelle?
Abhängig von
Eine Anforderung kann von vielen anderen Anforderungen abhängig sein.
Beispielsweise kann ein Editor erst seine Newseinträge selektieren, wenn wir in der Lage sind einen Editor im System überhaupt anzulegen.
Ersteller
Damit wir wissen, wer diese Anforderung gestellt hat, wird der Name und eventuell eine Kontaktmöglichkeit wie e-Mail, abgelegt.
Dies ist vernünftig, da wir manchmal nachfragen müssen was mit der Anforderung gemeint war.
Es macht das Leben viel einfacher, wenn man nachfragen kann
Bearbeiter
Angabe wer sich zur Zeit um diese Anforderung kümmert. Ich bin ein brutaler Fan davon, jeder Anforderung einen Bearbeiter, oder Owner, zu geben. Dann fühlt sich wenigstens jemand für die arme Anforderung verantwortlich
Erstelldatum
Cool ist, wenn man weiss seit wann eine Anforderung vorhanden ist.
Am Anfang ist das noch ene doofe Information. Wenn wir aber schon ein Newssystem Version 0.87 haben, dann ist es durchaus interessant zu wissen wie lange die Anforderungen so rumdümpeln.
Status
Folgenden Status kann eine Anforderung annehmen:
- Erfasst
- Genehmigt
- Abgewiesen
Falls eine Anforderung abgewiesen wurde, wird der Grund dafür im Beschreibungstext erledigt. - Zugewiesen
- Abgeschlossen
Abschlussdatum
Wenn man was fertig gemacht hat, dann ist es schön wenn man das auch mitteilen kann.
Fazit
Für die Verwaltung der diversen Anforderungen müssen relativ viele Informationen aufgenommen werden.
Der Aufwand, die Anforderungen zu verwalten, lohnt sich jedoch da man dann einfach weniger vergisst.
Der Beitrag wurde
am Donnerstag, den 11. Juni 2009 um 21:51 Uhr veröffentlicht
und wurde unter Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=1414
Dir gefiel der Artikel? Dann abonniere doch den RSS Feed
Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.
[...] wie wir unsere Anforderungen für das Newssystem verwalten können. Ich hatte im Artikel Requirements für Newssystem erfassen beschrieben, welche Informationen zu einer Anforderung beschrieben werden sollen. Im Artikel Welche [...]