See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Lastenheft – Wikipedia

Lastenheft

aus Wikipedia, der freien Enzyklopädie

Redundanz
Die Artikel Anforderungsmanagement, Lastenheft, Anforderungserhebung, Software Requirements Specification und Anforderung (Informatik) überschneiden sich thematisch. Hilf mit, die Artikel besser voneinander abzugrenzen oder zu vereinigen. Bitte äußere dich in der Diskussion über diese Überschneidungen, bevor du diesen Baustein entfernst. ~ğħŵ 08:53, 2. Dez. 2007 (CET)

Ein Lastenheft (teils auch auch Anforderungsspezifikation, Kundenspezifikation oder Requirements Specification) beschreibt die unmittelbaren Anforderungen durch den Besteller eines Produktes.

Im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehörenden formellen Abnahme beschreibt das Lastenheft präzise die nachprüfbaren Leistungen und Lieferungen.

Inhaltsverzeichnis

[Bearbeiten] Gegenstand

Ein Lastenheft kann nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten. Diese abstrakten Merkmale wären, wenn nicht durch eine Prüfung zu belegen, kaum durch denjenigen, der das Produkt herstellen soll, so einzuschätzen, dass sie zielführend berücksichtigt werden könnten.

Gemäß DIN 69905 (Begriffe der Projektabwicklung) beschreibt das Lastenheft die

„vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.

Das Lastenheft beschreibt in der Regel somit, was und wofür etwas gemacht werden soll (Fachkonzept). Die Adressaten des Lastenhefts sind [1] der (externe oder firmeninterne) Auftraggeber sowie die Auftragnehmer. In der Softwaretechnik ist das Lastenheft das Ergebnis der Planungsphase und wird in der Regel einvernehmlich von den Bestellern und den Entwicklern als Vorstufe des Pflichtenhefts überarbeitet.

Um ein Lastenheft übersichtlich zu halten, wird es vorzugsweise in knapp orientierendem Text gefasst und mit Detaillierungen beispielsweise in tabellarischer Form, mit Zeichnungen oder Grafiken ergänzt. Es gibt dazu auch formalisierende Ansätze, wie die Beschreibungssprache UML.

[Bearbeiten] Folgeschritte

Wurde ein Lastenheft angenommen, folgt mit dem Pflichtenheft die nächste Phase - dieses beschreibt, was und womit etwas realisiert werden soll. Dabei können gewöhnlich jeder Anforderung des Lastenhefts eine oder mehrere Leistungen des Pflichtenheftes zugeordnet werden. So wird auch die Reihenfolge der beiden Dokumente im Entwicklungsprozess deutlich: Die Anforderungen (requirements) werden durch Leistungen (features) erfüllt.

Nach DIN 69905 enthält das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.

[Bearbeiten] Abgrenzung

Je nach Einsatzgebiet und Branche können sich Lastenhefte in Aufbau und Inhalt stark unterscheiden. Auch werden in der Praxis die Begriffe Lastenheft, Pflichtenheft und Spezifikation oft nicht klar gegeneinander abgegrenzt oder gar synonym verwendet. Die unscharfe Verwendung der Begriffe Lastenheft und Pflichtenheft sowie die fehlende Trennung technischer Information und operationeller Absichten ist häufig Ursache für Missverständnisse.

Auf einen Kaufvertrag nach BGB §433 oder einen rechtlich gleichgestellten Liefervertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Lieferungen im Kaufvertrag von einer durch den Lieferanten einseitig vorgegebenen Spezifikation in der Art und von der durch den Besteller einseitig vorgegebenen Liefermenge bestimmt werden.

Auf einen Dienstvertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Leistungen im Dienstvertrag nicht einer formellen Abnahme unterzogen werden.

[Bearbeiten] Aufbau

Ein Lastenheft lässt sich auf verschiedene Weise gliedern. Folgende Angaben werden typisch berücksichtigt:

  1. Ausgangssituation und Zielsetzung
  2. Produkteinsatz
  3. Produktübersicht
  4. Funktionale Anforderungen
  5. Nicht funktionale Anforderungen
  6. Risikoakzeptanz
  7. Skizze des Entwicklungszyklus und der Systemarchitektur oder auch ein Struktogramm
  8. Lieferumfang
  9. Abnahmekriterien

[Bearbeiten] Branchenspezifika

In einigen Branchen haben sich standardisierte Vorgaben für Lastenhefte und deren Abwicklung etabliert.

So orientieren sich die in der Raumfahrt benutzten Lastenhefte häufig am NASA Standard, um die internationale Kooperation zu vereinfachen. Es hat sich folgendes Prinzip herausgebildet:

  • Der Auftraggeber erstellt eine Anforderungsspezifikation (requirements spec), die die Missionsanforderungen und Rahmenbedingungen enthält (z. B. es soll ein bemanntes Labormodul für die ISS geliefert werden, das mit dem Space Shuttle dorthin transportiert werden soll);
  • Der Auftragnehmer antwortet darauf mit einer Implementierungsspezifikation (design-to-spec), die den vom Auftragnehmer gewählten Entwurf spezifiziert (z. B. ein zylinderförmiges Druckmodul mit bestimmtem Durchmesser und Länge);
  • Der Auftraggeber akzeptiert formell die mehr Details enthaltende Implementierungsspezifikation. Im Falle eines später auftretenden Konflikts hat die Anforderungsspezifikation jedoch Vorrang.

Für das Columbus Projekt hat die Implementierungsspezifikation (APM Spezifikation) diesen Aufbau[2]:

  1. Document Change Record
  2. Para 1. Scope: Purpose, Summary Description, Classification, Applicability
  3. Para 2. Related Documents: Applicable Documents, Reference Documents
  4. Para 3. Functional / Performance Requirements
  5. Para 4. Support Requirements: Product Assurance, EMC, Contamination etc.
  6. Para 5. Interface Requirements
  7. Para 6. Implementation Requirements: Configuration, Budget Allocation
  8. Para 7. Preparation for Delivery
  9. Attachments: List of Abbreviations, Verification Requirements.

In einigen Spezifikationen werden die Verifikationsanforderungen zusammen mit den Leistungsanforderungen in den verschiedenen Paragraphen definiert sodass der entsprechende Anhang im obigen Beispiel entfällt.

[Bearbeiten] Siehe auch

[Bearbeiten] Normen und Standards

[Bearbeiten] Quellen

  1. Helmut Balzert: Lehrbuch der Software- Technik 1/2. mit 3 CD-ROMs. Band 1 (2. Auflage, 2000), Band 2 (1. Auflage, 1998) Software-Entwicklung / Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung; Spektrum Akademischer Verlag; ISBN 3-827-40301-4
  2. Columbus Design Spec (COL-RIBRE-SPE-0028, iss 10/F, 25.06.2004)

[Bearbeiten] Weblinks

Andere Sprachen


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -