Beruflich Dokumente
Kultur Dokumente
Lastenheft
SeminarIS
<Dieses Dokument ist strukturell eng angelehnt an [Ebert 2014]. Das Fallbeispiel stammt aus
[Balzert 2012]. Es dient als Beispiel für ein Lastenheft nach [DIN 69901-5] zur Verwendung in
Lehrveranstaltungen des Instituts für Informatik am Campus Gummersbach der TH Köln. Ggfs.
sind zusätzliche Angaben zur Lehrveranstaltung, dem Semester, den Dozenten/Betreuern etc.
auf dem Deckblatt notwendig. Beachten Sie den Einsatz von Textmarken zur Verlinkung inner-
halb des Dokumentes (in MS Word:
Datei->Optionen->Anzeige->Alle Formatierungszeichen anzeigen)!>
Änderungshistorie
Inhalt
Änderungshistorie ................................................................................................................. 2
Inhalt ........................................................................................................................................ 3
1 Einführung ................................................................................................................... 4
1.1 Zweck ................................................................................................................................... 4
1.2 Marktanforderungen ............................................................................................................. 4
1.3 Glossar .................................................................................................................................. 4
1.4 Referenzen ............................................................................................................................ 6
1.5 Systemübersicht .................................................................................................................... 7
2 Beschreibung .............................................................................................................. 8
2.1 Produktsicht .......................................................................................................................... 8
2.2 Funktionen ............................................................................................................................ 8
2.3 Benutzer ................................................................................................................................ 9
2.4 Einschränkungen ................................................................................................................... 9
2.5 Qualitätsvorgaben ................................................................................................................. 9
2.6 Annahmen ............................................................................................................................. 9
3 Spezifische Anforderungen ..................................................................................... 10
3.1 Produktfunktionen .............................................................................................................. 10
3.1.1 Kundenverwaltung........................................................................................................ 10
3.1.2 Seminarverwaltung ....................................................................................................... 10
3.1.3 Zahlungsverkehr ........................................................................................................... 10
3.1.4 Informationsbetrieb....................................................................................................... 10
3.1.5 Systemverwaltung ........................................................................................................ 10
3.2 Produktdaten ....................................................................................................................... 11
3.3 Produktschnittstellen ........................................................................................................... 11
3.4 Detaillierte Funktionsbeschreibungen ................................................................................ 11
3.5 Architektur .......................................................................................................................... 12
3.6 Einschränkungen ................................................................................................................. 12
3.7 Qualitätsanforderungen und Abnahmekriterien .................................................................. 13
Abnahmekriterien ............................................................................................................................ 14
3.8 Lieferumfang ...................................................................................................................... 14
3.9 Standards............................................................................................................................. 15
3.10 Weitere Quellen .................................................................................................................. 15
Anhänge ................................................................................................................................ 16
A. Konkurrenzanalyse ............................................................................................................. 16
B. Prozessmodelle ................................................................................................................... 16
Index ...................................................................................................................................... 17
1 Einführung
1.1 Zweck
<Hier wird der Gegenstand des Projekts beschrieben. Das können Ziele an das Produkt sein, eine His-
torie des Produkts, oder eine kurze Übersicht zum Projekt>
Es ist ein Seminar-Informationssystem (SeminarIS) zu erstellen, das die Planung und Durchführung von
Seminaren sowie die Kundenverwaltung unterstützen soll. Die Seminarveranstaltungen sind entweder
öffentlich, also für jedermann belegbar, oder speziell auf die Belange einer bestimmten Firma zuge-
schnitten, wobei dann auch nur Mitarbeiter der Firma teilnehmen dürfen. Die Seminare werden in der
Regel von freiberuflich tätigen Dozenten gehalten, die sich anhand von Veröffentlichungen und nach-
gewiesener Projekterfahrung als Experten auf dem jeweiligen Gebiet ausgewiesen haben.
Öffentliche Seminare werden langfristig geplant und müssen in Anbetracht der wirtschaftlichen Lage
und der starken Konkurrenz effektiv beworben werden, um zu einer kostendeckenden Teilnehmerzahl
zu kommen. Firmenseminare sind dahingegen oft kurzfristig durchzuführen, was aber oft an der Ver-
fügbarkeit kompetenter Dozenten scheitert.
Durch das Seminar-Informationssystem, das die Seminarverwaltung und die Bearbeitung von Anfragen
der Kundenbetreuer unterstützt, erhofft sich der Auftraggeber Erleichterungen für seine Angestellten.
Außerdem erwartet er eine verbesserte Kundenbetreuung und eine Steigerung der Produktivität. Rech-
nungskopien werden an ein zentrales Fakturierungssystem übermittelt und von diesem weiter bearbeitet
und verfolgt.
1.2 Marktanforderungen
<Die Marktanforderungen werden einzeln identifizierbar beschrieben. Das beinhaltet Markt, Bedarf,
Design, Alleinstellungsmerkmale, etc. Nicht immer passt eine einheitliche Schablone, denn auch Rand-
bedingungen und Kenngrößen des Markts, der Mitbewerber, konkurrierender Lösungen sollen beschrie-
ben werden.>
Kerngeschäft des Auftraggebers ist die [M10] Konzeption, Planung und Durchführung von Seminar-
veranstaltungen in allen Bereichen der Informatik. Zielgruppe des Produkts sind die Seminar- und Kun-
densachbearbeiter des Auftraggebers. Das System wird in den Zweigstellen des Auftraggebers einge-
setzt, wobei eine [M20] zentrale Datenhaltung vorzusehen ist.
In der bisher manuell abgewickelten Seminarverwaltung muss die [M30] Unterstützung der Angestell-
ten und insbesondere der Kundenbetreuer des Auftraggebers verbessert werden. [M40] Informationen
über Personen und ihre bisher belegten Seminare müssen derzeit mühsam aus einzelnen Akten extrahiert
werden. Schon einfache Anfragen über freie Plätze in Seminaren können vom Kundenbetreuer oft nicht
schnell genug erledigt werden. [M50] Darüber hinaus ist die Zahlungsmoral einiger Teilnehmer schlecht
und sollte bei der Belegung von Seminaren berücksichtigt werden können.
…
1.3 Glossar
<Alle verwendeten Definitionen, Akronyme, Abkürzungen werden beschrieben. Das Glossar sollte hier
gepflegt werden, kann aber aus einer Datenbank extrahiert sein.>
Begriffe
Adresse
Typ Attributbündel
Beschreibung Informationen für die postalische Zustellung.
2018, Lastenheft_SeminarIS_V1_1.docx Version 1.1 vom 2018-10-10
TH Köln, Campus GM, PM-Team
Lastenheft SeminarIS 5 / 17
Person
Typ Natürliche Person
Beschreibung Eine Person, die im Kontext der Seminarveranstaltungen eine Rolle
spielt.
Struktur Name, Vorname, Titel, Geburtsdatum, Adresse, Telefon, Fax, ...
Beispiel
Kontext Kundenverwaltung, Dozentenverwaltung
Synonyme Interessent
Homonyme -
Verw. Begriffe Teilnehmer, Dozent
Referenzen Lastenheft [F10] [F30] [D10]
Teilnehmer
Typ Natürliche Person
Beschreibung Eine Person, die mindestens eine Seminarveranstaltung belegt hat.
Struktur Name, Vorname, Titel, Geburtsdatum, Adresse, Firma, Telefon, Fax, ...
Beispiel
Kontext Kundenverwaltung
Synonyme Seminarteilnehmer, Kunde
Homonyme -
Verw. Begriffe Person
Referenzen Lastenheft [F10] [F30] [D10]
Seminarveranstaltung
Typ Sachverhalt
Beschreibung Eine Veranstaltung zu einem Seminartyp, die an einem bestimmten Ort zu
einer bestimmten Zeit von einem Seminarleiter und ggfs. einem oder meh-
reren Begleitdozenten durchgeführt wird.
Struktur Seminartitel, Beginn, Ende, Ort, TeilnehmerMax, ...
Beispiel UML für Anfänger, 20.10. 2017, 23.10.2017, Erlangen, 20, …
Kontext Seminarverwaltung, Kundenverwaltung
Synonyme Seminar
Homonyme -
Verw. Begriffe Seminartyp
Referenzen Lastenheft [F40] [F50] [F30] [D30]
Abkürzungen
1.4 Referenzen
<Referenzen zu Gesetzen, Verordnungen, Standards, externen Dokumenten etc. werden hier zusammen-
gefasst. Unbedingt auch URLs und Zugangsmöglichkeiten angeben.>
…
[GoBD 2014] Bundesministerium der Finanzen: Grundsätze zur ordnungsmäßigen Führung und
Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer
Form sowie zum Datenzugriff. Berlin, 2014
http://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schrei-
ben/Weitere_Steuerthemen/Abgabenordnung/Datenzugriff_GDPdU/2014-11-14-
GoBD.pdf?__blob=publicationFile&v=1
1.5 Systemübersicht
2 Beschreibung
2.1 Produktsicht
2.2 Funktionen
<Hier werden die wesentlichen Funktionen als Übersicht beschrieben. Typische Darstellungsformen
sind strukturierter Text, Feature-Bäume oder Use-Cases>
…
Abb. 2 zeigt wichtige Anwendungsfälle des Systems. Zur Vereinfachung ist der DB-Server nicht dar-
gestellt.…
2.3 Benutzer
2.4 Einschränkungen
<Zusammenfassende Darstellung der wesentlichen externen Vorgaben, z.B. Protokolle, Hardware, Al-
gorithmen>
Als Betriebssystem kommt auf dem Server Linux zum Einsatz. Als Datenbanksystem wird mySQL ein-
gesetzt. Fremdsysteme sind über WebServices im SOAP-Format [URL SOAP] auf Basis von HTTPS
anzubinden (s. [IF10]).
…
2.5 Qualitätsvorgaben
2.6 Annahmen
<Beschreibung aller Annahmen, die nicht durch den Kunden definiert wurden, aber für die Realisierung
relevant sind, z.B. Stromversorgung, Klima>
Es existiert keine USV.
…
3 Spezifische Anforderungen
3.1 Produktfunktionen
3.1.1 Kundenverwaltung
[F10] Personen bearbeiten (Angestellte des Auftraggebers sind als Seminarteilnehmer zugelassen),
gezielte Werbung.
[F20] Firmen bearbeiten, bei denen Personen angestellt sind.
[F30] Seminarbelegungen bearbeiten inklusive Teilnehmer-Benachrichtigung (Anmeldung, Abmel-
dung, Änderung, Rechnung), ggf. Firmen-Benachrichtigungen, falls Firma Rechnungsemp-
fänger.
[F35] Firmenseminare („in-House“) bearbeiten inklusive Teilnehmer-Benachrichtigungen (Anmel-
dung, Abmeldung, Änderung, Rechnung),
3.1.2 Seminarverwaltung
3.1.3 Zahlungsverkehr
[F60] Erstellen von Rechnungen und Gutschriften. Kopien der Datensätze werden über das Netz an
das Fakturierungssystem gemeldet. Dieses meldet seinerseits auftretende Zahlungsverzüge an
SeminarIS zurück.
3.1.4 Informationsbetrieb
3.1.5 Systemverwaltung
3.2 Produktdaten
<Hier sind die wesentlichen Daten zu skizzieren, wobei die Einträge im Glossar detaillieren können.>
[D10] Es sind relevante Daten über die Personen zu speichern.
[D20] Gehört eine Person zu einer Firma, sind über die Firma relevante Daten zu speichern.
[D30] Es sind relevante Daten über Seminarveranstaltungen, -typen und Dozenten zu speichern.
[D40] Belegt ein Teilnehmer eine Seminarveranstaltung, dann sind entsprechende Belegungsdaten
zu speichern.
[D50] Ist ein Teilnehmer im Zahlungsverzug, dann sind die Höhe des Zahlungsverzugs und der Stich-
tag zu speichern, an dem der Zahlungsverzug eingetreten ist.
3.3 Produktschnittstellen
<Hier werden Anforderungen an die externen Schnittstellen aufgeführt, z.B. Standards, Protokolle, …>
[IF10] Die Anbindung von Fremdsystemen wie z.B. dem Fakturierungssystem erfolgt über WebSer-
vices im SOAP-Format [URL SOAP] auf Basis von HTTPS.
…
<Hier werden die konkreten Funktionen einzeln identifizierbar mit der Anforderungsschablone be-
schrieben, z.B. Gültigkeitsprüfungen, Use-Cases, Abnahmekriterien>
…
[UC07] Person erfassen
Quellen [F10]
Spezifikation ~/uc/spec/kunden/UC07
Beschreibung Die Daten einer Person werden erfasst. Das System prüft während der Erfas-
sung, ob die Daten bereits in der Datenbank vorliegen, und schlägt ggfs. ent-
sprechende Einträge vor.
Inputs Personendaten
Outputs Speicherbestätigung
Sequenz 1. Der Benutzer gibt die Personendaten ein.
2. Das System schlägt entsprechende vorhandene Einträge vor.
3. Der Benutzer akzeptiert oder verwirft die Vorschläge.
4. Das System prüft die vollständige Eingabe auf Plausibilität und Korrekt-
heit und gibt eine Bestätigung aus.
Ausnahmen -
Vorbedingung -
Nachbedingung Die Personendaten sind konsistent und aktualisiert.
Einschränkungen -
Testfälle ~/qs/akzeptanztest/kunden/UC07
~/qs/unittest/kunden/UC07
3.5 Architektur
<Darstellung und Beschreibung der Architektur. Im Lastenheft wird die Architektur zunächst aus Prob-
lemsicht beschrieben, z.B. extern vorgegebene Datenmodelle, Systemmodelle, Evolution des Systems>
…
Abb. 3 zeigt die Web-MVC-Architektur des Systems. Dem System liegt eine Client/Server-Architektur
mit einem lokalen Netz zugrunde. Die Clients basieren auf dem MS-Windows-Betriebssystem. Eine
graphische Oberfläche in gängigem Standard (z. B. Java-Swing, Eclipse RCP) ist zu integrieren. Alle
Personen- und Seminardaten sind auf einem Linux-Server in einem relationalen Datenbankmanage-
mentsystem (RDBMS) mit JDBC-Schnittstelle zu verwalten. Der Datentransfer erfolgt unter TCP/IP.
3.6 Einschränkungen
< Interne und externe Einschränkungen werden detailliert dargestellt. Sie sollten messbar beschrieben
sein, damit klar ist, wie getestet wird, und wie intern geklärt werden kann, ob sie erfüllt sind. Falls
vorhanden werden Abnahmekriterien beschrieben. Einschränkungen sollten nur das nötigste beschrei-
ben, um den Lösungsraum nicht zu sehr einzuschränken.>
…
Entwicklungs- und Wartungsumgebung des Projektes ist ein Linux-Betriebssystem.
…
<Interne und externe Qualitätsanforderungen werden detailliert dargestellt und priorisiert. Sie sollten
messbar beschrieben sein, damit klar ist, wie getestet wird, und wie intern geklärt werden kann, ob sie
erfüllt sind. Falls vorhanden werden Abnahmekriterien beschrieben.>
Qualitätsmerkmale (nach [ISO 25010])
Anwendungsbezogene Qualität
Merkmal Teilmerkmale Priorität
Effektivität Aufgabenerfüllung innerhalb der Genauigkeits- und Vollstän- Hoch
digkeitsgrenzen
Effizienz Aufgabenerfüllung innerhalb der Aufwandsgrenzen für Benut- Hoch
zer (Zeit, Kosten, ...)
Zufriedenheit Verwendbarkeit, Vertrauen, Begeisterung, Bequemlichkeit Mittel
Risikoabwe- Wirtschaftliche Risiken, Gesundheits- und Sicherheitsrisiken, Mittel
senheit Umgebungs- und Umweltrisiken
Kontextabde- Kontextuelle Vollständigkeit, Flexibilität Mittel
ckung
Produktqualität
Externe Qualität
Merkmal Teilmerkmale Priorität
Funktionalität Vollständigkeit, Richtigkeit, Angemessenheit Sehr Hoch
Performanz Zeitverhalten, Ressourcengebrauch, Kapazität Hoch
Kompatibilität Koexistenz, Interoperabilität Hoch
Benutzbarkeit Angemessenheit, Erkennbarkeit, Erlernbarkeit, Bedienbarkeit, Mittel
Fehlertoleranz, Ästhetik, Zugänglichkeit
Zuverlässig- Reife, Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit Mittel
keit
Sicherheit Vertraulichkeit, Integrität, Nachweisbarkeit, Verantwortlich- Hoch
keit, Authentifizierbarkeit
Interne Qualität
Merkmal Teilmerkmale Priorität
Wartbarkeit Modularität, Wiederverwendbarkeit, Analysierbarkeit, Modifi- Mittel
zierbarkeit, Testbarkeit
Portierbarkeit Anpassbarkeit; Installierbarkeit, Austauschbarkeit Gering
Abnahmekriterien
Mindestens 90% aller Abnahmeprüffälle müssen fehlerfrei ablaufen. Während der Abnahme dürfen
keine schwerwiegenden Fehler auftreten. Es sind alle Vorgänge besonders kritisch, die Veränderungen
von Daten verursachen. Rechnungen müssen absolut korrekt bearbeitet und übertragen werden.
Bei den Sachbearbeiter-Tätigkeiten (Seminarbelegungen, Informationsbetrieb, Personen- und Seminar-
verwaltung) soll die durchschnittliche Bearbeitungsdauer gegenüber dem jetzigen Stand um mindestens
50% verkürzt werden:
[A10] Die Funktionen unter Punkt [F80] dürfen nicht länger als 5 Sekunden Interaktionszeit benöti-
gen, alle anderen Reaktionszeiten müssen unter 2 Sekunden liegen.
Das tatsächlich zu berücksichtigende Datenvolumen ergibt sich aus der Summe der minimalen Größen,
die zusätzlich mit dem Sicherheitsfaktor 2 multipliziert wird:
[A20] Es müssen minimal 50.000 Personen und minimal 3.000 Seminare verwaltet werden können.
[A30] 5 Prozent aller Teilnehmer sind erfahrungsgemäß im Zahlungsverzug.
Folgende Funktionssequenzen müssen fehlerfrei möglich sein:
[T10] Teilnehmeranmeldung, Ersterfassung, Abmeldung, Neuanmeldung, Rechnung, Zahlungsver-
zug.
[T20] Absage bzw. Änderung einer Belegung.
[T30] Stornierung eines Seminars, Gutschriften erstellen.
[T40] Belegungen eines Seminars eintragen, Rechnungen erstellen.
[T50] Durchführung eines Seminars eintragen, Teilnehmerliste und Teilnahmebescheinigungen dru-
cken.
[T60] Backup und Restore des gesamten Datenbestandes.
Folgende Datenkonsistenzen sind einzuhalten:
[T70] Eine Seminarbelegung kann nur vorgenommen werden, wenn sowohl die Person als auch eine
entsprechende Seminarveranstaltung vorhanden sind und die Seminarveranstaltung noch nicht
ausgebucht ist.
[T80] Eine neue Seminarveranstaltung kann nur eingetragen werden, wenn ein entsprechender Se-
minartyp und ein Dozent vorhanden sind.
[T90] Eine Seminarbelegung kann nur vorgenommen werden, wenn der Teilnehmer nicht im Zah-
lungsverzug ist.
…
3.8 Lieferumfang
<Hier sind materielle und immaterielle zu liefernde Dinge (Artefakte, Dienstleistungen) aufzuführen>
Das System inkl. elektronischer Handbücher ist auf einem nicht-wiederbeschreibbaren Datenträger
(DVD-ROM, BlueRay) installationsfähig zu liefern. Updates sind über das Web zu liefern.
Um die Datenbeschaffung kümmert sich der Auftraggeber. Sie ist nicht Gegenstand des Projekts.
Die Erstellung schließt eine einjährige Garantie ein. Anschließend ist über Wartungsverträge zu verhan-
deln.
3.9 Standards
<Standards mit spezifischen Anforderungen werden hier detailliert. Sie sollen nicht abgeschrieben wer-
den, sondern als wesentliche Anforderungen beschrieben werden. In stark regulierten Bereichen, z.B.
Telekommunikation, sind Standards häufig die wesentliche Quelle aller Anforderungen.>
…
[ISO 25010] ISO/IEC 25010: Systems and Software Engineering – Systems and software Quality
Requirements and Evaluation (SQuaRE) – System and software quality models. ISO,
Genf, 2011
[DIN 69901-5] DIN 69901-5: Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe.
Beuth Verlag, Berlin, 2009
[DIN 9241-110] DIN EN ISO 9241-110: Ergonomie der Mensch-System-Interaktion - Teil 110:
Grundsätze der Dialoggestaltung. Beuth Verlag, Berlin, 2008
[DIN ISO 9735] DIN ISO 9735-xx: Elektronischer Datenaustausch für Verwaltung, Wirtschaft und
Transport (EDIFACT) - Syntax-Regeln auf Anwendungsebene. Teile 1-10, Beuth-Ver-
lag, Berlin, 2004
[URL SOAP] SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommen-
dation, 27 April 2007.
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/
…
[Balzert 2012] Balzert, H.: Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und
Betrieb. Springer Spektrum, Heidelberg, 2012
[Ebert 2014] Ebert, C.: Systematisches Requirements Engineering. dpunkt-Verlag, Heidelberg, 2014
[Winter 2005] Winter, M.: Methodische objektorientierte Softwareentwicklung. dpunkt.verlag, Hei-
delberg, 2005
Anhänge
<Ggf. weitere, z.B. firmeninterne Dokumente, Hinweise/Analysen von existierenden Produkten/Syste-
men etc., die für die Anforderungen relevant sind.>
A. Konkurrenzanalyse
SimplyOrg
https://simplyorg.de/loesungen/seminarverwaltung-fuer-bildungsinstitute
Einstiegsinfo
SEMINARVERWALTUNG LEICHT GEMACHT
Die Komplettlösung für Ihr Seminarmanagement: Seminare planen, organisieren, verwalten und ver-
markten – zeit- und kosteneffizient mit einer zentralen Software
Als Anbieter von Seminaren und Weiterbildungen kennen Sie die Herausforderungen, die eine kom-
plexe Planung mit sich bringt. Ab 200 Kursen im Jahr führen unübersichtliche Arbeitsabläufe nicht nur
zu einem enormen Zeitaufwand, sondern letztlich auch zu suboptimaler Planung und Durchführung Ih-
rer Seminare.
Wie schön wäre es, wenn Sie sämtliche Prozesse zur Seminarverwaltung in einer einzigen Software
managen könnten, in der Sie jederzeit den Überblick haben und somit einen reibungslosen Ablauf, hohe
Qualität und optimale Wirtschaftlichkeit Ihrer Kurse garantieren können? Mit der simplyOrg Seminar-
verwaltungssoftware ist dies ganz einfach realisierbar.
• Rundum-Paket: Planung, Vorbereitung, Bewerbung sowie Auswertung und Abrechnung Ihrer
Seminare – alles in einem einzigen Tool
• Übersichtlichkeit und Transparenz: Jederzeit alles im Blick durch eine zentrale Software-Lö-
sung
• Zeitersparnis: Workflow Management zur Automatisierung wiederkehrender Aufgaben und
Prozesse in der Seminarverwaltung
• Qualitätsmanagement: Abarbeitung der Aufgaben via Checklisten, inklusive Abhängigkeiten,
Status und Fälligkeit
• Kostensenkung: Optimierung Ihrer Seminare bezüglich Auslastung und Qualität
• Einfachheit: Intuitiv bedienbare Seminarsoftware zur Digitalisierung aller Prozesse
• Maßgeschneidert: Funktionen und Schnittstellen ganz nach Ihren Bedürfnissen
Lizenz-Info und Kosten
…
B. Prozessmodelle
Index
Adresse 4 Seminarverwaltung 4
Auftraggeber 4 ST Siehe Seminartyp
GoBD 6 SV Siehe Seminarveranstaltung
Person 5 Teilnehmer 5
Seminarveranstaltung 6