Wprowadzenie

Bardzo często pojawiają się w ofertach i na szkoleniach, dotyczących wymagań, dwa akronimy: FURPS i SMART. Cóż to jest? To zalecenia dotyczące oceny specyfikacji wymagań np. na oprogramowanie. Jednak czym innym jest ocenić czy zalecenia te spełnia dokument wymagań (jego treść) a czym innym jest to jak je spełnić.

Widły Hume’a

Edynburg_2013-04-19_10-52_JZelinski

Gilotyna Hume’a – nazwa problemu sformułowanego przez szkockiego filozofa Davida Hume’a dotyczącego niemożności wnioskowania, co powinno być, na podstawie tego, co jest (ang. is-ought problem).

W filozofii funkcjonuje pojęcie “widły Hume’a“, w dużym uproszczeniu Hume twierdzi, że wiele treści, ksiąg i wypowiedzi to treści ułomne, niezrozumiałe, bezzasadne lub banalne. Hume pisze, że doświadczenie uczy nas jedynie, jak jedno wydarzenie stale następuje po drugim, nie pouczając nas o “tajemnym związku”, który wiąże je ze sobą i czyni je nierozłącznymi (Hume, 1777, s. 63). . W ten sposób Hume kwestionuje wnioskowanie indukcyjne.

Hume, po Galileuszu, był jednym z prekursorów idealizacji wyjaśnienia faktów w postaci opisu mechanizmu ich powstawania . Mechanizm to ten “tajemny związek” łączący przyczyny ze skutkami, bo nie jest nim statystyka.

Czym są owe Widły Hume’a? Stosowanie “na co dzień” polega na tym, by każdą wypowiedź (każde cudze stanowisko) sprawdzić dwoma pytaniami:

  • Co to znaczy?
  • Skąd to wiemy?

Cóż to jest FURPS i SMART? 

Angielski akronim rozszyfrowujemy następująco:

  • Functionality- funkcjonalność w rozumieniu zestawu funkcji uwzględniająca również bezpieczeństwo (ang. security)
  • Usability – użyteczność jako zestaw wizualnych aspektów oprogramowania
  • Reliability – niezawodność, będąca mierzona np. częstością występowania błędów
  • Performance – wydajność aplikacji określana również jako czas odpowiedzi lub użycie zasobów
  • Supportability – podatność na serwisowanie (“serwisowalność”), dająca się łatwo testować, naprawiać i rozwijać.

SMART to akronim od słów: Sprecyzowane, Mierzalne, Akceptowane, Realistyczne, Terminowe.

Jak widać maję one pewną wspólną cechę: to są oczekiwania w stosunku do specyfikacji wymagań. Dlaczego piszę o tym? Po pierwsze w FURPS są przemieszane wymagania funkcjonalne i poza-funkcjonalne: funkcjonalność vs. wydajność, niezawodność i podatność na serwisowanie. Do tego są one dość subiektywne  bo np. jak sprawdzić czy wymagania są użyteczne?

W kwestii SMART jest jeszcze gorzej: wszystkie pięć pojęć to subiektywne życzenia bez możliwości weryfikacji ich spełnienia.

Tak wiec jak ktoś powie, że jego wymagania są SMART to zadaj np. pytanie: Co to znaczy Sprecyzowane? Skąd wiemy, że one są sprecyzowane?  I tak po każdym z tych magicznych słów.

Zresztą każdy ważny dokument, tu dokument wymagań, warto tak przetestować, szczególnie jeśli opisuje coś wartego potencjalnie dziesiątki tysięcy złotych. Jak na te, widły, zareagują dokumenty opracowane metodami formalnymi? W prosty sposób:

Co to znaczy, że wymagania są zweryfikowane? To znaczy, że z powodzeniem przeprowadzono test polegający na wykonaniu wszystkich czynności modelu procesu biznesowego. Skąd to wiemy? Bo na wejściu modelu procesu “podano” prawdziwe dokumenty, udało się na modelu wskazać wszystkie czynności wymagane do obsłużenia tego dokumentu i nie było innych zbędnych, otrzymaliśmy taki sam rezultat (wynikowy dokument i jego stan)  jak w naturze oraz na liście przypadków użycia są wszystkie te i tylko te, które były potrzebne by ten proces bez błędu przeszedł do końca. Jak to się robi? Przeczytaj o tym tu.

Jeżeli dokument wymagań nie spełnia tych kryteriów, nie mieści się w tych widłach, to jak sam Hume twierdzi, jest on bezwartościowy, nie niesie żadnej wiedzy gdyż poszczególne wymagania są: albo niezrozumiałe, albo zrozumiałe lecz nie uzasadnione, albo zrozumiałe i zasadne lecz banalne (np. mają być Sprecyzowane). Tak więc wiemy co to znaczy FURPS i SMART (powyższe skróty). Odbierając dokumenty analiz zadawajcie pytanie: a skąd wiemy, że te wymagania (które ktoś spisał) są FURPS i SMART i co to oznacza?

Polecam:

Źródła

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: dostęp do treści Bloga jest bezpłatny, jednak wszelka pomoc oraz wyjaśnienia dotyczące treści artykułów autora bloga, udzielane są wyłącznie w ramach płatnych konsultacji.