{"id":7299,"date":"2015-10-30T06:00:25","date_gmt":"2015-10-30T05:00:25","guid":{"rendered":"http:\/\/www.johner-institut.de\/blog\/?p=7299"},"modified":"2024-08-21T10:12:53","modified_gmt":"2024-08-21T08:12:53","slug":"entscheidungstabellen","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62304-medizinische-software\/entscheidungstabellen\/","title":{"rendered":"Entscheidungstabellen zum Spezifizieren von Anforderungen"},"content":{"rendered":"

Entscheidungstabellen<\/strong> sind nicht nur ein hilfreiches Werkzeug, um Software-Tests zu spezifizieren, d.h. um Testf\u00e4lle systematisch herzuleiten. Sie sind genauso n\u00fctzlich beim Spezifizieren von Medizinprodukten (Systemen), von Komponenten oder von\u00a0Software selbst.<\/p>\n

<\/p>\n

Sie sollten (Software-)Anforderungen pr\u00e4zise spezifizieren<\/h2>\n

Was passiert, wenn Sie\u00a0das nicht tun<\/h3>\n

W\u00e4hrend meiner Beratungsprojekte bei Medizinprodukteherstellern sto\u00dfe ich immer wieder auf ziemlich unvollst\u00e4ndige System-Anforderungen\u00a0(manchmal als <\/span>Pflichtenheft<\/a> bezeichnet) bzw. Software-Anforderungen<\/a>. Aus dieser Unvollst\u00e4ndigkeit ergeben sich fast immer die gleichen Probleme<\/strong>:<\/span><\/p>\n

    \n
  1. Abweichungsbericht<\/strong> im Audit, weil Anforderungen unvollst\u00e4ndig spezifiziert sind<\/li>\n
  2. Entwickler<\/strong>, die nicht so richtig wissen, was sie entwickeln sollen, was wiederum zu Projektverzug und fehlerhaften Produkten f\u00fchrt<\/li>\n
  3. Tester<\/strong>, die st\u00e4ndig nachfragen m\u00fcssen und zugleich eher erfahrungsbasiert denn systematisch testen, was wiederum ebenfalls zu erh\u00f6hten Aufw\u00e4nden und schlechterer Produktqualit\u00e4t f\u00fchrt.<\/li>\n<\/ol>\n

    Weshalb sich so viele damit schwer tun<\/h3>\n

    Mir f\u00e4llt auf, dass oft nicht mangelnder Flei\u00df oder mangelnde Einsicht Grund f\u00fcr die unvollst\u00e4ndigen und unpr\u00e4zisen Anforderungen sind, sondern vielmehr ein Unverm\u00f6gen diese zu formulieren<\/strong>. Ich h\u00f6re dann S\u00e4tze wie \u201edas kann man nicht allgemein sagen\u201c oder \u201edas ist sehr kompliziert\u201c. In der Tat beginnen wir dann endlose Listen an wenn-dann-S\u00e4tzen zu formulieren. Bei diesen zahllosen Bedingungen verliert man leicht die \u00dcbersicht, besonders vergisst man schnell zu spezifizieren, was passieren soll, wenn die Bedingung nicht erf\u00fcllt ist.<\/p>\n

    Entscheidungstabellen zum Spezifizieren von Tests und Anforderungen<\/h2>\n

    Wie Sie mit Entscheidungstabellen arbeiten<\/h3>\n

    Unabh\u00e4ngig davon, ob Sie ganze Systeme,\u00a0standalone Software<\/a> oder embeded Software spezifizieren wollen, empfehle ich Ihnen: Ziehen Entscheidungstabellen<\/strong> in Betracht, um eine komplexe Logik vollst\u00e4ndig, systematisch und konsistent zu formulieren. Diese Entscheidungstabellen bestehen aus<\/p>\n

      \n
    1. Zeilen f\u00fcr die Vorbedingungen und m\u00f6glichen Inputs\u00a0der Software bzw. des Systems.
      \nz.B. wenn die Pumpe l\u00e4uft und der Nutzer „Start“ eingibt…<\/li>\n
    2. Zeilen, die m\u00f6glichen Outputs charakterisieren.
      \nz.B. dann stoppt die Software die Pumpe und die Software zeigt eine Warnung<\/li>\n
    3. Spalten, die die Testf\u00e4lle beschreiben d.h. die Kombination der geplanten Inputs und die erwarteten Outputs.<\/li>\n<\/ol>\n

      \"Software-Anforderungen<\/a><\/p>\n

      Ideal ist es, wenn Sie in den\u00a0Entscheidungstabellen die Inputs und v.a. Outputs\u00a0mit eindeutig entscheidbaren\u00a0Kriterien beschreiben. Beispielsweise:<\/p>\n