Management-Zusammenfassung dieses Beitrags:
Die Begriffe Funktion und Feature werden in der → Softwareentwicklung verwendet, sind aber nicht unbedingt identisch einsetzbar.
In diesem Beitrag wird eine Beschreibung der beiden Begriffe geliefert.
In der Wikipedia schreibt zum Begriff Funktion / Funktionen eines Objekts /#Wiki-Funktion/:
“Als Funktionen eines Objektes bezeichnet man die Aufgaben, die es erfüllen kann. Mithilfe seiner Funktionen kann ein Objekt also gewissen Zwecken dienen. Ein einzelnes Objekt kann mehrere Funktionen haben, welche demselben Zweck dienen können oder verschiedenen. Gleichzeitig kann eine Funktion auch für mehrere Zwecke genutzt werden.”
Zum Feature steht in der Wikipedia knapp /#Wiki-Feature/:
“Programmfeature, die Funktionalität einer Software (siehe auch Feature-Request)“
und zum Feature-Request wird dann weiter ausgeführt /#Wiki-Feature-Request/:
“Feature-Request (von engl. feature = Eigenschaft, Fähigkeit, Funktion; request = Antrag, Anfrage, Wunsch; auch Leistungsmerkmalanforderung) oder Verbesserungsvorschlag bezeichnet die Anfrage, eine Software um eine neue Funktion zu erweitern oder die vorhandene Funktionalität zu verändern.”
Das → IIBA definiert den Begriff Feature wie folgt /BBG-17d/:
“Lösungsmerkmal (feature): Abgrenzbarer Bestandteil einer Lösung, in dem eine Reihe von Anforderungen umgesetzt wird und der Wert für → Stakeholder liefert.”
Die Charakterisierungen von Funktion und Feature sind in Abbildung 1 wiedergegeben.
Abbildung 1: Funktion und Feature
Grundsätzlich sind beide Begriffe fast synonym zu verwenden. Während im klassischen Vorgehen eher der Begriff Funktion genutzt wird, findet sich bei agiler Vorgehensweise bevorzugt der Begriff Feature. Wenn von einem Featurebündel (Feature Bundle) gesprochen wird, so ist diese eine zusammenhängende Sammlung von Features, die häufig als Ganzes umgesetzt werden.
Weiteres:
- Bei agiler Vorgehensweise umfasst ein Feature ein oder mehrere → User Stories. Typischerweise sollte ein Feature innerhalb eines Releases, besser noch innerhalb eines Sprints umgesetzt werden können
- Als → Feature Freeze wird ein → Zeitpunkt bei der Erstellung von Anforderungen / Requirements oder bei der Programmierung von Softwaresytemen bezeichnet, ab dem keine weiteren Features mehr hinzugefügt werden dürfen, der Funktionsumfang damit festliegt
- Eine “Feature List” (oder auch “Functional Scope List”) kann in einem → Vorhaben sehr frühzeitig erstellt werden. Eine solche → Liste umfasst die Features des zu erstellenden Produkts und kann weiterverwendet werden, so beispielsweise zur Erstellung eines → Lastenhefts oder zur Releaseplanung
- Eine “Feature Group” wird bei der agilen Softwareentwicklung auch als “Theme” bezeichnet
- Im → Beschaffungswesen gibt es den RFF / Request for Feature (deutsch Aufforderung zur Angebotserweiterung). Dieser Request wird genutzt, wenn ein bestehendes Angebot — beispielsweise auf Basis eines → Lastenhefts — nicht mehr ausreichend ist
- Es gibt den Spruch “It’s not a bug, it’s an feature” / “Es ist kein → Fehler, es ist ein Feature”. Hiermit ist gemeint, dass ein nicht erwartetes Verhalten, welches bei einem → Softwaretest aufgefallen ist, vom Entwickler so beabsichtigt war, es wurde lediglich vergessen, dies zu dokumentieren
- Beim Softwaretest: Nicht-dokumentierte Features sind Fehler
- Es gibt den Ansatz des Feature Driven Developments (FDD), bei dem sich das Umsetzungsvorgehen bei der Entwicklung von Software an denjenigen zu entwickelnden Features orientiert, die Kunden einen Mehrwert bringen
- Die Function-Point-Methode dient dazu, die Größe / → Komplexität von Softwaresystemen zu bewerten und zu vergleichen
- “Buy a Feature” ist eine Methode zur → Priorisierung bei der agilen Softwareentwicklung
- Ein “Minimal Marketable Feature (MMF)” ist die kleinstmögliche Menge von Features, die in Betrieb genommen werden können und gleichzeitig vermarktbar sind
- Ein “Feature Toogle” ist ein System / eine Eigenschaft, bei der ein Feature bei Bedarf an- oder abgeschaltet werden kann
- Unter “Feature-Falle” /Perri20/ wird die Problematik zusammengefasst, dass Produktmanager dazu neigen, bei ihren Produkten eine möglichst hohe Anzahl von Features einzubauen, ohne darauf zu achten, ob diese dem Kunden Mehrwert bringen. Oder anders ausgedrückt: Es wird mehr auf “→ Output” und weniger auf “→ Outcome” geachtet
- Das → Pflichtenheft kann als “Functional Specification” oder “Feature Specification” bezeichnet werden
Literatur
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /Perri18/ Melissa Perri: Escaping the Build Trap. How Effective Product Management Creates Real Value, O’Reilly UK, Farnham, Great Britain 2018, ISBN 978–1‑4919–7379‑0
- /Perri20/ Melissa Perri: Raus aus der Feature-Falle. Wie effektives → Produktmanagement echten Mehrwert schafft, O’Reilly, Köln 2020, ISBN 978–3‑96009–120‑2
Weblinks
- /#Wiki-Feature/ Feature in der deutschen Wikipedia
- /#Wiki-Feature-Request/ Feature-Request in der deutschen Wikipedia
- /#Wiki-Funktion/ Funktion (Objekt) in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 18.11.2023 © Peterjohann Consulting, 2005–2024
