O wymaganiach Kilka słów o wymaganiach w projektach informatycznych

18lip/102

Lista kontrolna dla przypadków użycia

Dyskutowaliśmy już kiedyś nad wykorzystaniem list kontrolnych (ang. check list)  do podnoszenia jakości naszych wymagań. Dzisiaj natrafiłem na listę kontrolną dla przypadków użycia firmowaną przez pana Karla Wiegersa. Myślę, że warto się z tą listą zapoznać i spróbować wykorzystać ją przy następnej okazji, gdy będziecie robić mniej lub bardziej formalny przegląd swojej specyfikacji wymagań.

8cze/105

A najczęściej używana notacja to…

Patrząc przez ramię

Ile razy zastanawialiście się, w jaki sposób modelować Wasze wymagania? Która notacja będzie najlepsza? Który sposób modelowania powinienem\am wybrać? Ile razy zaglądaliście przez ramię koleżanki lub kolegi, żeby zobaczyć jak oni to robią? Czy nie fajnie by było spojrzeć przez ramię prawie 200 innych analityków i zobaczyć, z czego oni korzystają w swojej pracy z wymaganiami?

Ale jak to zrobić?

Na szczęście panowie Colin J. Neill oraz Phillip A. Laplante z Penn State University postanowili dowiedzieć się czegoś więcej na temat najczęściej stosowanych praktyk inżynierii wymagań. Stworzyli internetową ankietę, która składała się z 22 pytań i zaprosili do jej wypełnienia prawie 2000 osób (głównie absolwentów PennState University). Odpowiedzi udzieliły 194 osoby (m.in. z takich firm jak SAP, Boeing, Dupont, Simens Medical  Systems) i odpowiedzi te były podstawą artykułu "Requirements Engineering: The State of the Practice", który ukazał się w 2003 roku.

A zwycięzcą jest...

Jako, że cały dokument jest dostępny tutaj, to nie będę rozwodził się nad poszczególnymi wnioskami, tylko przedstawię najciekawsze (moim zdaniem) wyniki, i tak:

  • 60% osób biorących udział w ankiecie stosowało w jakimś stopniu prototypowanie.
  • 35% respondentów powiedziało, że wykorzystują podejście kaskadowe.
  • W projektach, które  trwały dłużej niż dwa lata najpopularniejsze było podejście iteracyjne.
  • 33% osób stwierdziło, że nie korzystają z żadnej metodologii
  • 51% respondentów powiedziało, że stosują nieformalne sposoby zapisu wymagań, 27% sposoby półformalne, a 7% stosują notacje formalne.
  • W 59% przypadków stosuje się inspekcje, jako sposób na podniesienie jakości wymagań.
  • 52% osób stwierdziło, że w ich firmach za mało uwagi poświęca się na inżynierię wymagań.
  • Ponad 50% osób wykorzystuje przypadki użycia i/lub scenariusze do zapisu wymagań.

Tak wyglądają wyniki badań po drugiej stronie oceanu, ciekaw jestem jak to wyglądałoby u nas? Bylibyście zainteresowani wzięciem udziału w takim badaniu? Dajcie znać w komentarzach lub mailowo.

23mar/102

5 x „C”

Firma IAG na swoim blogu proponuje zasadę pięciu "C", która pozwala zadbać o wysoką jakość wymagań. Oto one:

  1. Wyrażaj się jasno (be Clear)
    • prowadź dyskusje w logiczny sposób
    • używaj prostych słów
    • unikaj eufemizmów
    • używaj stwierdzeń pozytywnych
    • sprawdzaj, czy każdy punkt jest wystarczająco jasny i kompletny (w izolacji od pozostałej treści)
  2. Bądź spójny (be Concise)
    • twórz prostą specyfikację
    • korzystaj w wypunktowań
    • wykorzystuj słowa, których używasz na co dzień
    • używaj raczej określeń szczegółowych niż wyrażeń ogólnych
    • unikaj powtarzania treści
  3. Bądź konkretny (be Concrete)
    • wykorzystuj przykłady oraz scenariusze
    • unikaj jargonu
    • miej zawsze jasne przesłanki
    • miej zawsze jasno określony cel
    • unikaj mylących złożonych stwierdzeń
    • unikaj stwierdzeń negatywnych
  4. Bądź kompletny (be Complete)
    • używaj list kontrolnych oraz technik walidacji
    • dokumentuj wszystkie możliwe wyjątki, warunki oraz odpowiedzi
    • szukaj opisów operacji bez jasno i w pełni określonych wyników
    • szukaj opisów operacji bez określonych dla nich zdarzeń
    • specyfikuj wszystkie elementy danych
  5. Bądź konsekwentny (be Consistent)
    • nie używaj wielu określeń dla tej samej rzeczy
    • korzystaj z tych samych stylów i czcionek w całym dokumencie
3lis/090

Listy kontrolne dla wymagań

Po co nam listy kontrolne?

Zapisywanie wymagań, analiza problemu i rozwiązania wymaga często dużego skupienia oraz sporej ilości czasu - najlepiej jeśli uda nam się skoncentrować na kilka godzin i ze spokojem przelać na papier nasze myśli. Wiadomo - taka praca jest najefektowniejsza, szczególnie jeśli chodzi o czas, ma ona jednak również swoje wady - często zapominamy o niektórych istotnych informacjach, dochodzi do przeoczeń spraw oczywistych, skupiamy się wyłącznie na jednym aspekcie problemu, zapominając o pozostałych. Co wtedy zrobić? Jednym z rozwiązań jest skorzystanie z list kontrolnych (ang. checklist), które zawierają elementy, na które należy zwrócić uwagę przy swojej pracy (w naszym wypadku przy zapisywaniu wymagań). Listy takie mogą być wykorzystywane zarówno przez samych autorów dokumentów, jak również podczas zespołowych przeglądów (nie należy wówczas jednak ograniczać się jedynie do list kontrolnych).

Jak stworzyć listę kontrolną?

Powstaje pytanie skąd wziąć taką listę kontrolną? Najlepszym rozwiązaniem jest stworzenie listy przez siebie samego (lub wewnątrz zespołu/firmy) na podstawie zdobytego doświadczenia (sami wiemy najlepiej czego brakowało dokumentom w poprzednich projektach). Jako, że trudno jest zacząć tworzyć taką listę od podstaw, można na początku skorzystać w list już gotowych (np rozsianych po internecie -  tutaj, tutaj lub tutaj), które później poszerzamy o zdobyte przez nas doświadczenia. Należy jednak pamiętać o tym, że listy kontrolne powinny mieć rozsądną długość, gdyż zbyt duża liczba reguł powoduje, że lista staje się trudna do czytania i utrzymania, zatem jeśli widzisz, że któryś z punktów w Twojej specyfikacji wymagań jest zawsze spełniony to ze spokojem możesz go usunąć z listy.

Podstawowa lista kontrolna dla wymagań

Co powinno się znaleźć w każdej liście kontrolnej dla wymagań?

  • Czy wymagania są spójne? Czy żadne z wymagań nie zaprzecza innemu? Czy wszystkie terminy używane są zawsze w tym samym znaczeni?
  • Czy wymagania są kompletne? Czy występują sformułowania typu TBD (ang. to be determined)?
  • Czy każdemu wymaganiu nadany jest odpowiedni priorytet?
  • Czy wymagania są weryfikowalne?
  • Czy w wymaganiach pojawiają się elementy rozwiązania (np. szczegóły implementacji)?
  • Czy określone są założenia i zależności?
  • Czy nie występuje redundancja wymagań?
  • Czy wszystkie odnośniki są poprawne i aktualne?
  • Czy zostały wyspecyfikowane zarówno wymagania funkcjonalne jak i pozafunkcjonalne?
  • Czy każde wymaganie jest wyrażone w sposób precyzyjny?
  • Czy każde wymaganie jest wyrażone w sposób jednoznaczny?
  • Czy każde wymaganie wchodzi w zakres problemu?
  • Czy opisani są aktorzy systemu?
  • Czy opisani są użytkownicy końcowi systemu?
  • Czy wskazane jest źródło dla każdego wymagania?
  • Czy każde wymaganie ma nadany indywidualny identyfikator?
  • Czy każde zadanie jest możliwe do zapewnienia?
  • Czy jest (aktualny i poprawny) słownik terminów i skrótów?

A Wy korzystacie przy swojej pracy z list kontrolnych?

   
Get Adobe Flash playerPlugin by wpburn.com wordpress themes