Nicht-funktionale Anforderungen Wichtig und häufig unterschätzt

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Unter nicht-funk­tio­na­len Anfor­de­run­gen (abge­kürzt: NFAs, sel­te­ner NFAen, eng­lisch: Non-func­tion­al Requi­re­ments — NFRs) wer­den Anfor­de­run­gen ver­stan­den, die sich aus tech­ni­schen Erfor­der­nis­sen und Rand­be­din­gun­gen erge­ben und kei­ne funk­tio­na­len Anfor­de­run­gen dar­stel­len.
In die­sem Bei­trag wer­den die nicht-funk­tio­na­len Anfor­de­run­gen beschrieben.

• Stich­wor­te: Nicht-funk­tio­na­le Anforderungen
• Syn­ony­me: NFA, NFR
• Not­wen­di­ges Know-how: Requirements-Engineering-Kenntnisse
• Schwie­rig­keits­grad: Mittel

Anfor­de­run­gen wer­den im → Requi­re­ments Engi­nee­ring in funk­tio­na­le und nicht-funk­tio­na­le Anfor­de­run­gen (NFAs) unter­teilt (Abbil­dung 0.1). Funk­tio­na­le Anfor­de­run­gen beschrei­ben — grob gespro­chen — was ein Sys­tem leis­ten soll, wäh­rend nicht-funk­tio­na­le Anfor­de­run­gen defi­nie­ren, wie ein Sys­tem etwas leis­ten soll. Die Ermitt­lung, Beschrei­bung und der Umgang mit funk­tio­na­len Anfor­de­run­gen fällt in der Regel leicht, wäh­rend sich bei nicht-funk­tio­na­len Anfor­de­run­gen häu­fig Schwie­rig­kei­ten ergeben.

In Abbil­dung 0.1 ist eine mög­li­che Unter­tei­lung von Anfor­de­run­gen mit funk­tio­na­len und nicht-funk­tio­na­len Anfor­de­run­gen dargestellt.

Abbil­dung 0.1: Unter­tei­lung von Anforderungen

1. Einleitung und Grundlagen

1.1 Definitionen

Das → IIBA defi­niert /BBG17‑d/:
“Nicht-funk­tio­na­le Anfor­de­rung (non-func­tion­al requi­re­ment): Anfor­de­run­gen, die nicht eine kon­kre­te → Funk­ti­on einer Lösung betref­fen, son­dern eher “beglei­ten­der” Natur sind z.B. Qua­li­täts­merk­ma­le oder zwin­gen­de Vor­ga­ben für das Design der Lösung insgesamt.”

In der Wiki­pe­dia steht zu den nicht-funk­tio­na­len Anfor­de­run­gen /#Wiki-Anforderungen/:
“Eine nicht­funk­tio­na­le Anfor­de­rung (eng­lisch non-func­tion­al requi­re­ment, NFR) ist in der Lite­ra­tur nicht ein­heit­lich defi­niert. Gemein­sa­mer Nen­ner ist, dass sie über die funk­tio­na­le Anfor­de­rung hin­aus geht. Die nicht­funk­tio­na­len Anfor­de­run­gen beschrei­ben, wie gut das Sys­tem die Leis­tung erbrin­gen soll; sie wer­den viel­fach als Rand­be­din­gun­gen und Qua­li­täts­ei­gen­schaf­ten verstanden.”

Ebert /Ebert22/ schreibt kurz:
“Nicht­funk­tio­na­le Anfor­de­rung: Eine Qua­li­täts­an­for­de­rung oder eine Einschränkung.”

Win­ter­roll defi­niert /Winteroll21/:
“Nicht­funk­tio­na­le Anfor­de­run­gen beschrei­ben, wie das Sys­tem etwas leis­ten soll.“
und stellt dazu funk­tio­na­le Anfor­de­run­gen gegen­über:
“Funk­tio­na­le Anfor­de­run­gen beschrei­ben, was das Sys­tem leis­ten soll.”

→ Schreib­wei­sen:
In die­sem Bei­trag sowie in allen mei­nen Bei­trä­gen und → Prä­sen­ta­tio­nen wird das Wort “nicht-funk­tio­nal” immer mit Bin­de­strich geschrie­ben. Die Schreib­wei­sen “nicht­funk­tio­nal” und “nicht funk­tio­nal” fin­den kei­ne Anwen­dung. Im Plu­ral wird “NFAs” ver­wen­det, auch wenn “NFAen” rich­ti­ger werden.

1.2 Motivation für die Spezifizierung von nicht-funktionalen Anforderungen

Dörr /Dörr/ beschreibt, war­um es sinn­voll und not­wen­dig ist, sich mit der Spe­zi­fi­ka­ti­on von nicht-funk­tio­na­len Anfor­de­run­gen zu beschäf­ti­gen. Er nennt dabei drei Haupt­mo­ti­va­to­ren (Abbil­dung 1.1):

• Gut begrün­de­te Architekturentscheidungen
• Wirk­sa­me Unterauftragsvergabe
• Früh­zei­ti­ge Qualitätssicherung

Dage­gen füh­ren nicht-spe­zi­fi­zier­te / feh­len­de NFAs zu:

• Unzu­rei­chen­der Produktqualität
• Hohen Nach­be­ar­bei­tungs­kos­ten
• Höhe­re Time-to-Marekt (TTM)

Abbil­dung 1.1: → Moti­va­ti­on für die Spe­zi­fi­zie­rung von NFAs (nach Dörr /Dörr11/)

1.3 Erfassung und Darstellung von nicht-funktionalen Anforderungen

Das Erfas­sen der nicht-funk­tio­na­len Anfor­de­run­gen geschieht in der Regel durch Abgleich mit Lis­ten. So kann bei­spiels­wei­se die ISO 25010 dafür her­an­ge­zo­gen wer­den, die zur Pro­dukt­qua­li­tät fol­gen­de acht Kate­go­rien benennt:

1. Funk­tio­na­le Eig­nung (eng­lisch: Func­tion­al Sui­ta­bi­li­ty)
2. → Effi­zi­enz (Per­for­mance Effi­ci­en­cy)
3. Kom­pa­ti­bi­li­tät (Com­pa­ti­bi­li­ty)
4. Benutz­bar­keit (→ Usa­bi­li­ty)
5. Zuver­läs­sig­keit (Relia­bi­li­ty)
6. Sicher­heit (→ Secu­ri­ty)
7. Wart­bar­keit (Main­taina­bi­li­ty)
8. Über­trag­bar­keit (Por­ta­bi­li­ty)

Die ers­ten sechs Kate­go­rien wer­den auch als äuße­re, die letz­ten bei­den als inne­re Qua­li­täts­ei­gen­schaf­ten bezeichnet. 

1.4 Der Zusammenhang von funktionalen und nicht-funktionalen Anforderungen

Eine funk­tio­na­le Anfor­de­rung kann durch nicht-funk­tio­na­le Anfor­de­run­gen ein­ge­schränkt wer­den (Abbil­dung 1.2).

Abbil­dung 1.2: Funk­tio­na­le und nicht-funk­tio­na­le Anfor­de­run­gen (nach /Hruschka19/)

Das IIBA schreibt dazu /BBG17‑d/:
“Nicht-funk­tio­na­le Anfor­de­run­gen ver­deut­li­chen Restrik­tio­nen, die für bestimm­te funk­tio­na­le Anfor­de­run­gen berück­sich­tigt wer­den müssen.”

Schien­mann /Schienmann01/ zeigt den Zusam­men­hang von Anwen­dungs­fäl­len, funk­tio­na­len und nicht-funk­tio­na­len Anfor­de­run­gen (Abbil­dung 1.3).

Abbil­dung 1.3: Anwen­dun­gungs­fäl­le, funk­tio­na­le und nicht-funk­tio­na­le Anfor­de­run­gen (nach /Schienmann01/)

1.5 Operationalisierung von nicht-funktionalen Anforderungen

Nicht-funk­tio­na­le Anfor­de­run­gen soll­ten kon­kre­ti­siert wer­den, sodass kein Inter­pre­ta­ti­ons­spiel­raum ent­steht. So wür­de bei­spiels­wei­se aus der nicht-funk­tio­na­len Anfor­de­rung “die Tem­pe­ra­tur darf die Maxi­mal­gren­ze nicht über­schrei­ten” die ope­ra­tio­na­li­sier­te Anfor­de­rung “die Tem­pe­ra­tur darf an allen Kom­po­nen­ten zu kei­nem → Zeit­punkt 80 °C überschreiten”.

1.6 Wiederverwendung von nicht-funktionalen Anforderungen

Funk­tio­na­le Anfor­de­run­gen wer­den in der Regel sys­tem­spe­zi­fisch ermit­telt. Nicht-funk­tio­na­le Anfor­de­run­gen hin­ge­gen kön­nen häu­fig “wie­der­ver­wen­det” wer­den, da sie sys­tem­über­grei­fen­de Gül­tig­keit besitzen.

2. Das Ermitteln von nicht-funktionalen Anforderungen

2.1 Quellen für nicht-funktionale Anforderungen

Nicht-funk­tio­na­le Anfor­de­run­gen kön­nen aus ver­schie­de­nen Quel­len kom­men. Hier sind zu nennen:

• → Stake­hol­der
• Ent­wick­ler
• Markt­be­dürf­nis­se
• Orga­ni­sa­ti­ons­in­ter­ne Vorgaben
• Regu­la­to­ri­sche Vorgaben

2.2 Zeitpunkt der Ermittlung

Gene­rell soll­ten nicht-funk­tio­na­le Anfor­de­run­gen mög­lichst früh bestimmt wer­den, da sie häu­fig die Sys­tem-/Soft­ware-Archi­tek­tur beeinflussen.

2.3 Vorgehen bei der Ermittlung

Win­teroll /Winteroll21/ schlägt vor, einen aus dem Qua­li­täts­mo­dell der ISO 25010 abge­lei­te­ten Qua­li­täts­baum zur Ermitt­lung und Ope­ra­tio­na­li­sie­rung der NFAs zu ver­wen­den. Dabei wer­den die Merk­ma­le der ISO 25010 mit den Kate­go­rien benannt. Zu den Kate­go­rien wer­den dann ein­zel­ne Fra­gen gestellt und mit ent­spre­chen­den Ant­wor­ten ver­se­hen (Abbil­dung 2.1).

Abbil­dung 2.1: Das Ermit­teln von nicht-funk­tio­na­len Anfor­de­run­gen mit dem Qua­li­täts­baum: Schema

In Abbil­dung 2.2 ist ein Qua­li­täts­baum zu einem Sys­tem dargestellt.

Abbil­dung 2.2: Das Ermit­teln von nicht-funk­tio­na­len Anfor­de­run­gen mit dem Qualitätsbaum

Der Qua­li­täts­baum kann aus­ge­baut wer­den, indem für jede Unter­ka­te­go­rie ent­spre­chen­de Fra­gen for­mu­liert wer­den, die dann durch den Pro­dukt­ma­na­ger / Sys­tem-Ver­ant­wort­li­chen beant­wor­tet wer­den können.

3. Weitere Aspekte zu den NFAs

3.1 Normen zu den NFAs

Als Nor­men zu den nicht-funk­tio­na­len Anfor­de­run­gen kön­nen gese­hen werden:

• DIN 66272 — “Infor­ma­ti­ons­tech­nik — Bewer­ten von Soft­ware­pro­duk­ten — Qua­li­täts­merk­ma­le und Leit­fa­den zu ihrer Ver­wen­dung”; die­se → Norm weist gro­ße Ähn­lich­keit mit der ISO 9126 auf und wur­de 2006 zurückgezogen
• ISO 9126 — “→ Soft­ware engi­nee­ring — Pro­duct qua­li­ty”; die­se Norm wur­de 2011 zurück­ge­zo­gen und durch die ISO 25010 ersetzt
• ISO 25010:2023 — “Sys­tems and soft­ware engi­nee­ring — Sys­tems and soft­ware Qua­li­ty Requi­re­ments and Eva­lua­ti­on (SQua­RE) — Pro­duct qua­li­ty model”

Auch die inzwi­schen ver­al­ten Nor­men IEEE 830 und IEEE 1362 bie­ten Vor­ga­ben für die Erfas­sung von nicht-funk­tio­na­len Anforderungen.

3.2 Vorlagen zur Erfassung von NFAs

Es gibt eine Rei­he von → Vor­la­gen zur Erfas­sung von nicht-funk­tio­na­len Anfor­de­run­gen. Die­se sind häu­fig in Form von → Check­lis­ten orga­ni­siert. Eben­so kön­nen Glie­de­run­gen aus Nor­men und Stan­dards ver­wen­det wer­den. Hier­zu kann bei­spiels­wei­se das Vole­re-Tem­p­la­te genutzt wer­den, wel­ches die nicht-funk­tio­na­len Anfor­de­run­gen benennt.

3.3 Satzschablonen für NFAs

Bei den Sophis­ten fin­den sich spe­zi­fi­sche → Satz­scha­blo­nen, mit denen nicht-funk­tio­na­le Anfor­de­run­gen erfasst wer­den kön­nen /#Sophist-MASTeR-Broschüre-24/.

Abbil­dung 3.1: Die → Satz­scha­blo­ne zur Erfas­sung von nicht-funk­tio­na­len Anfor­de­run­gen (nach /#Sophist-MASTeR-Broschüre-24/)

Bei­spie­le sind:

• Das Datei­for­mat der Prä­sen­ta­tio­nen muss pdf in der Ver­si­on 1.5 bis 2.0 sein
• Die Ant­wort­zeit des Sys­tems muss kei­ner als 1,5 Sekun­den sein

3.4 User Stories und NFAs

Grund­sätz­lich wer­den in → User Sto­ries funk­tio­na­le Aspek­te fest­ge­hal­ten. Sol­len nicht-funk­tio­na­le Aspek­te berück­sich­tigt wer­den, so gibt es fol­gen­de Möglichkeiten:

• Erstel­len von “nicht-funk­tio­na­len” User Sto­ries, die in einem tech­ni­schen Sprint bear­bei­tet werden
• Rein tech­ni­sche Sprints oder Design-/Ar­chi­tek­tur­sprints

3.5 Das Testen von nicht-funktionalen Anforderungen

Nicht-funk­tio­na­le Tests über­prü­fen die nicht-funk­tio­na­len Anfor­de­run­gen, wie z.B. die Sicher­heit, die Benutz­bar­keit oder die Zuver­läs­sig­keit eines Sys­tems. Dabei steht nicht die Funk­ti­on der Soft­ware (Was tut die Soft­ware?) im Vor­der­grund, son­dern ihre Funk­ti­ons­wei­se (Wie arbei­tet die Software?).

Es wer­den beim → Tes­ten der nicht-funk­tio­na­len Anfor­de­run­gen typi­scher­wei­se Grenz­wer­te benannt, die dann getes­tet wer­den.
Typi­sche Sze­na­ri­en sind dann:

• Reak­ti­ons­zei­ten: Es wer­den die maxi­mal zuläs­si­gen Ant­wort­zei­ten eines Sys­tems benannt
• Hoch­fahr­zei­ten: Es wer­den die Zei­ten benannt, in denen ein Sys­tem hoch­fah­ren muss

Typi­scher­wei­se wer­den die Tests für nicht-funk­tio­na­le Anfor­de­run­gen auto­ma­ti­siert durchgeführt.

4. Zur Verwendung des Begriffs nicht-funktionale Anforderungen

Die Ver­wen­dung des Begriffs “nicht-funk­tio­na­le Anfor­de­run­gen” hat noch zu Beginn der 2000er Jah­re zu regen Dis­kus­sio­nen in der deutsch­spra­chi­gen Fach-Com­mu­ni­ty geführt. 

4.1 “Qualitätsanforderungen und Randbedingungen” statt “nicht-funktionale Anforderungen”

Nach → IREB soll­te auf der Begriff “nicht-funk­tio­na­le Anfor­de­run­gen” nicht mehr ver­wen­det und statt­des­sen “Qua­li­täts­an­for­de­run­gen und Rand­be­din­gun­gen” genutzt wer­den /#IREB-CPRE-FL-Handbuch-24/. Hrusch­ka schreibt dazu /Hruschka23/:
“Eine Bit­te: Strei­chen Sie das Wort “nicht­funk­tio­na­le Anfor­de­run­gen” aus Ihrem Sprach­schatz. Ver­wen­den Sie statt­des­sen die viel aus­sa­ge­kräf­ti­ge­ren Begrif­fe “Qua­li­täts­an­for­de­run­gen” und “Rand­be­din­gun­gen”.”

In Abbil­dung 4.1 ist eine mög­li­che Ein­tei­lung der Begrif­fe funk­tio­na­le Anfor­de­rung, Qua­li­täts­an­for­de­rung und → Rand­be­din­gung ohne Ver­wen­dung der funk­tio­na­len Anfor­de­rung dargestellt.

Abbil­dung 4.1: Arten von Anfor­de­run­gen (nach /Hruschka23/)

4.2 Unterteilung bei Rupp

Rupp und die Sophis­ten /Rupp20, #Sophist-MAS­TeR-Bro­schü­re-24/ unter­tei­len die nicht-funk­tio­na­len Anfor­de­run­gen in fol­gen­den sechs Kategorien:

• Qua­li­täts­an­for­de­run­gen
• Tech­no­lo­gi­sche Anforderungen
• Benut­zungs­ober­flä­che
• Sons­ti­ge Lieferbestandteile
• Durch­zu­füh­ren­de Tätigkeiten
• Recht­lich-ver­trag­li­che Anforderungen

Abbil­dung 4.2: Unter­tei­lung der nicht-funk­tio­na­len Anfor­de­run­gen (nach /Rupp20/ und /#Sophist-MASTeR-Broschüre-24/)

5. Häufig gestellte Fragen und Antworten (FAQ) zu den nicht-funktionalen Anforderungen

Eini­ge Fra­gen zu den nicht-funk­tio­na­len Anfor­de­run­gen wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

• F: Muss man nicht-funk­tio­na­le Anfor­de­run­gen sepa­rat betrach­ten?
  A: Dies ist durch­aus rat­sam, ins­be­son­de­re da die nicht-funk­tio­na­len Anfor­de­run­gen die Sys­tem­ar­chi­tek­tur beein­flus­sen und daher sehr früh­zei­tig bekannt sein müssen.
• F: Kann in der Pra­xis auf die Betrach­tung und Behand­lung von nicht-funk­tio­na­len Anfor­de­run­gen ver­zich­tet wer­den?
  A: Nein, in der Regel nicht. 
• F: Gibt es Über­sich­ten zur Ermitt­lung und Erfas­sung von nicht-funk­tio­na­len Anfor­de­run­gen?
  A: Ja. Es gibt eini­ge, meist lis­ten­ar­ti­ge Über­sich­ten, in denen typi­sche nicht-funk­tio­na­le Anfor­de­run­gen benannt wer­den. In die­sem Bei­trag wur­de dazu der Qua­li­täts­baum auf Basis der ISO 25010 vorgestellt.

A. Präsentationen, Literatur und Weblinks

A.1 Meine öffentliche Präsentationen mit Bezug zu den NFAs

Inhalt	Typ
Requi­re­ments Engi­nee­ring (und Busi­ness Ana­ly­sis) – Eine Ein­füh­rung (RE-Basis­prä­sen­ta­ti­on)

A.2 Literatur

• /BAPG15/ Pro­ject Manage­ment Insti­tu­te: → Busi­ness Ana­ly­sis For Prac­ti­tio­ners: A Prac­ti­ce Gui­de, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2015, ISBN 978–1‑62825–069‑5
• /BBG15/ IIBA: A Gui­de to the Busi­ness Ana­ly­sis Body of Know­ledge (BABOK Gui­de), Inter­na­tio­nal Insti­tu­te of Busi­ness Ana­ly­sis, Mari­et­ta, Geor­gia 3rd Edi­ti­on 2015, ISBN 978–1‑927584–02‑6
• /BBG17‑d/ IIBA: BABOK v3: Leit­fa­den zur Busi­ness-Ana­ly­se BABOK Gui­de 3.0, Dr. Götz Schmidt, Wet­ten­berg 2017, ISBN 978–3‑945997–03‑1
• /Dörr11/ Jörg Dörr: Eli­ci­ta­ti­on of a Com­ple­te Set of Non-Func­tion­al Requi­re­ments, Fraun­ho­fer Ver­lag, Stutt­gart 2011, ISBN 978–3‑8396–0261‑4
• /Ebert22/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 7. Auf­la­ge 2022, ISBN 978–3‑86490–919‑1
• /Hruschka19/ Peter Hrusch­ka: → Busi­ness Ana­ly­sis und Requi­re­ments Engi­nee­ring: Pro­zes­se und Pro­duk­te nach­hal­tig ver­bes­sern, Han­ser, Mün­chen 2. Auf­la­ge 2019, ISBN 978–3‑446–45589‑4
• /Hruschka23/ Peter Hrusch­ka: Busi­ness Ana­ly­sis und Requi­re­ments Engi­nee­ring. Pro­zes­se und Pro­duk­te nach­hal­tig ver­bes­sern, Han­ser, Mün­chen 3. Auf­la­ge 2023, ISBN 978–3‑446–47692‑9
• /PMG-BA17/ Pro­ject Manage­ment Insti­tu­te: The → PMI Gui­de to Busi­ness Ana­ly­sis, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2017, ISBN 978–1‑62825–198‑2
• /Rupp20/ Chris Rupp: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Das Hand­buch für Anfor­de­run­gen in jeder Situa­ti­on, Han­ser, Mün­chen 7. Auf­la­ge 2020, ISBN 978–3‑446–45587‑0
• /Schienmann01/ Bru­no Schien­mann: → Anfor­de­rungs­ma­nage­ment. Pro­zes­se – Tech­ni­ken – Werk­zeu­ge, Addi­son-Wes­ley, Mün­chen 2001, ISBN 978–3‑8273–1787‑2
• /Wiegers13/ Karl E. Wie­gers, Joy Beat­ty: Soft­ware Requi­re­ments, Micro­soft Press, Red­mond, Washing­ton 3rd Edi­ti­on 2013, ISBN 978–0‑7356–7966‑5
• /Wiegers23/ Karl Wie­gers, Can­da­se Hokan­son: Soft­ware Requi­re­ments Essen­ti­als. Core Prac­ti­ces for Suc­cessful Busi­ness Ana­ly­sis, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2023, ISBN 978–0‑13–819028‑6
• /Winteroll21/ Mar­cus Win­teroll: Requi­re­ments Engi­nee­ring für Dum­mies, Wiley-VCH, Wein­heim 2021, ISBN 978–3‑527–71635‑7

A.3 Weblinks

• /*Dörr11/ Jörg Dörr: Eli­ci­ta­ti­on of a Com­ple­te Set of Non-Func­tion­al Requi­re­ments, Web­site zum Buch mit Open Access zur kom­plet­ten Aus­ga­be (eng­lisch, pdf-Datei, 219 Seiten) 
• /IREB/ Inter­na­tio­nal Requi­re­ments Board (IREB), deutsch und englisch
• /IREB-24/, /#IREB-24/, /#IREB-CPRE-FL-24/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Lehr­plan / Syl­labus zum CPRE-FL, Ver­si­on 3.2.0 vom Febru­ar 2024 (deutsch, pdf-Datei, 51 Seiten)
• /#IREB-CPRE-FL-Handbuch-24/ IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board: Hand­buch für das CPRE Foun­da­ti­on Level nach dem IREB-Stan­dard, Ver­si­on 1.2.0 vom Mai 2024 (deutsch, pdf-Datei, 174 Seiten)
• /ISO-25010/ ISO/IEC 25010:2023: “Sys­tems and soft­ware engi­nee­ring – Sys­tems and soft­ware Qua­li­ty Requi­re­ments and Eva­lua­ti­on (SQua­RE) – Pro­duct qua­li­ty model”: Über­sichts­sei­te
• /#Sophist-MASTeR-Broschüre-24/ Fa. Sophist: Satz­scha­blo­nen für alle Fäl­le, 6. Auf­la­ge 2024, (deutsch, pdf-Datei, 52 Seiten)
• /#Wiki-Anforderung/ Anfor­de­rung (Infor­ma­tik) in der deut­schen Wikipedia
• /#Wiki-DIN-66272/ DIN 66272 in der deut­schen Wikipedia
• /#Wiki-ISO-9126/ ISO/IEC 9126 in der deut­schen Wikipedia

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website 

Letz­te Aktua­li­sie­rung: 20.09.2024 © Peter­jo­hann Con­sul­ting, 2005–2024