1) Das Lastenheft einer Software (SW) ist die vollständige und eindeutige Beschreibung des Verhaltens der SW. Ein Lastenheft ist demnach aus der Sicht des Anwenders (Betreibers) formuliert und enthält keine Angaben über die Details der technischen Realisierung dieses Verhaltens. Das Lastenheft ist also die Verhaltensbeschreibung der zu entwickelnden Software oder auch die Aufgabenstellung des SW-Projekts.

2) Ein gutes Lastenheft gibt die Erfordernisse eines Marktes oder eines Kunden wieder. Für viele Unternehmen (Technik, Investitionsgüter) gilt: Im Lastenheft steckt ein Wert, der die restlichen Entwicklungskosten meist deutlich übersteigt. D.h. die Kenntnis über Märkte und Kunden sind oft mehr wert, als die Entwicklung eines zugehörigen (SW-)Produkts. Für den Auftraggeber bedeutet ein gutes Lastenheft eine Absicherung, um vom Auftragnehmer auch tatsächlich brauchbare SW zu erhalten.

3) Die meisten praktischen SW-Projekte sind wegen
- unvollständiger
- ungenauer
- zu konkreter
- widersprüchlicher
Anforderungen beeinträchtigt und verspätet/überteuert. Die Liste ist nach absteigender Häufigkeit sortiert. Die Kosten der nachträglichen Realisierung verspäteter/veränderter Anforderungen sind um Größenordnungen höher, als die einmalige Realisierung korrekter Anforderungen.

4) Das Lastenheft besteht aus einzelnen Anforderungen. Jede Anforderung ist eine unabhängig überprüfbare Eigenschaft.  Anforderungen sind die kleinste Einheit der Aufgabenstellung an Software.

5) Es gibt funktionale und nicht-funktionale Anforderungen. Funktionale Anforderungen beschreiben die Funktionen von Software. Nicht-funktionale Anforderungen beschreiben Merkmale wie
- Performanz, Effizienz
- Robustheit (Stabilität bei Belastung durch gutwillige Bedienung)
- Sicherheit (Schutz gegen böswillige Fehlbedienung)
- Verfügbarkeit
- Lesbarkeit, Wartbarkeit, Erweiterbarkeit, Portierbarkeit
- Skalierbarkeit
In professioneller SW gibt es etwa gleich viele funktionale wie nicht-funktionale Anforderungen. Nicht-funktionale Merkmale sollten zuerst beachtet werden, da sie nicht oder nur sehr schwer nachrüstbar sind. Funktionale Anforderungen sind meistens später leicht hinzuzufügen. Web-Software legt mehr Gewicht auf nicht-funktionale Merkmale und realisiert meist recht wenige Funktionen.

6) Jede einzelne Anforderung muss folgende Eigenschaften aufweisen:
- minimal         Die Anforderung fordert nur ein einziges Merkmal
- abstrakt         Die Anforderung ist aus Anwendersicht formuliert
- eindeutig       Das geforderte Merkmal ist entweder vorhanden ist oder nicht
- testbar          Man kann einen Testfall erstellen, der die Erfüllung des
geforderten      Merkmals mit JA oder Nein beantwortet

7) Die Gesamtheit aller Anforderungen in einem Lastenheft muss folgende Eigenschaften erfüllen:
- vollständig           Es gibt keine anderen ungenannten Anforderungen, die auch noch erfüllt werden müssen, aber nicht im LH aufgeführt werden. (Dies ist nicht allein mit dem LH ermittelbar !)

- widerspruchsfrei  Die verschiedenen Anforderungen stehen nicht im Widerspruch zueinander.

8) Es gibt Werkzeuge zur Verwaltung und Verfolgung (Tracing) von Anforderungen. In diesen
Werkzeugen ist jede einzelne Anforderung
- identifizierbar      Jede Anforderung wird durch einen eindeutigen (sprechenden) Schlüssel identifiziert. Mit dem Schlüssel kann die Anforderung gesucht oder referenziert werden.

- in einem Zustand  Jede Anforderung kann unabhängig von anderen Anforderungen in
verschiedenen Bearbeitungszuständen sein. Beispielsweise:
inEntwurf:             der Anforderungstext wird noch verändert
verabschiedet:       die Anforderung ist aktiv, Text ist nicht mehr änderbar
testbar:                die Anforderung tracet horizontal (hat Testfälle)
obsolet:                die Anforderung ist nicht mehr aktiv

9) Die Verwaltung (Suchen, Versionierung, Bearbeitungzustände, Tracing) von Anforderungen  oder Requirements Engineering (RE) kann durch Werkzeuge unterstützt werden, z.B. CaliberRM, C.A.R.E, Cradle, DOORS, Slate, RequisitePro, Zeus

10) Einige Werkzeuge verwenden vorgegebene Satzschablonen zur Darstellung des Anforderungstexts. Jede Satzschablone hat eine Anzahl von Parametern, die eingesetzt werden müssen, damit aus der Schablone eine konkrete Anforderung wird. Auf diese Weise sollen die Eigenschaften unter 6) sichergestellt oder zumindest unterstützt werden. Im Englischen bleibt unabhängig von den Einsetzungen dabei der Satzbau gleich, sodass die Einsetzungen und der Schablonentyp tabellarisch in einer Datenbank gespeichert werden können und nachträglich in natürliche Sprache übersetzt werden. In professionellen SW-Projekten sind derartige generierte Lastenheft oft Vertragsbestandteil.

Es gibt diese Schablonentypen:
Systemaktivität
<when> <if> THE SYSTEM SHALL/SHOULD/WILL <process> <what> <how>

Benutzerinteraktion
<when> <if> THE SYSTEM SHALL/SHOULD/WILL PROVIDE <whom> THE ABILITY TO <process> <what> <how>

Reaktion des Systems auf äußere Bedingungen
<when> <if> THE SYSTEM SHALL/SHOULD/WILL BE ABLE TO <process> <what> <how>

In jedem konkreten müssen Werte für die Parameter in <..> eingesetzt werden.

11) Anforderungen können
- aus vorhandenen Alt-Systemen oder Systemen der Mitbewerber
- anhand von Beschwerden und Service-Anfragen
- anhand von Fragebögen
- mittels Prototypen und Demo-Shows
ermittelt werden. Diese Auflistung ist aufsteigend nach der Neuartigkeit des zu erstellenden Systems sortiert. Weitere Anforderungen ergeben sich aus gesetzlichen Vorgaben oder strategischen Marketingentscheidungen.
.