top of page
  • Zdjęcie autoraKarolina Zmitrowicz

Jak nie "pisać” wymagań? Krótka instrukcja.


  1. Równoważnik zdań to nie jest opis wymagania. “Wymaganie” o brzmieniu "Dodawanie produktów" może być co najwyżej skróconym opisem wymagania, ale na pewno nie kompletną specyfikacją.

  2. Dostarcz informacje – kto, co, robi, na jakim obiekcie, pod jakimi warunkami? W powyższym przykładzie dodawanie produktów brakuje informacji o tym, kto lub co dodaje produkty, jakie produkty, gdzie dodaje, jakie są warunki dodawania produktów (Czy można dodać produkty o tych samych nazwach, na przykład?).

  3. Zapewnij mierzalność. Przytoczę w tym miejscu i mój ulubiony przykład "system ma być wystarczająco szybki". Wystarczająco to znaczy jak szybki? W jakich warunkach? Jak tę “szybkość” mierzyć? Jaka jest skala pomiaru? Co w ogóle rozumiemy pod pojęciem “szybki” – czas odpowiedzi systemu na pewne działania użytkownika, czas przetwarzania danych?

  4. Unikaj porównań. "System ma być bardziej użyteczny". Bardziej niż co? W tym momencie pewnie kusi cię, aby uzupełnić wymaganie o stwierdzenie “...bardziej użyteczne niż dotychczasowy system”. Brawo, właśnie stworzyłeś specyfikację wymagania, które nie jest mierzalne. Nie idźmy tą drogą. Jeżeli chcesz określić użyteczność, wydajność, jakikolwiek inny aspekt funkcjonowania systemu – określ go mierzalnie, używając skali i konkretnych wartości (patrz punkt wyżej).

  5. Używaj szablonów. Tak, wiem, że szablony to nie jest to, co tygryski lubią najbardziej, jednak rozsądnie dobrany szablon eliminuje ryzyko pominięcia istotnej informacji.

  6. Unikaj słów, które nic nie znaczą. Takimi słowami są: zarządzanie, obsługa, zwiększenie, optymalizacja, usprawnienie, jak najlepiej, jak najszybciej. Są to ładnie brzmiące słowa, które nie wnoszą żadnej informacji. Chcesz opisać wymaganie dotyczące "zarządzania produktami"? To w pierwszej kolejności zastanów się, co rozumiesz pod słowem zarządzanie – dodawanie produktu, usuwanie, edycja (czyli standardowe operacje CRUD), aktywacja?

  7. Zapewnij atomowość wymagań. Jeżeli opisujesz wymagania w formie "system ma umożliwiać dodawanie produktu i jego edycję", to tak naprawdę opisujesz dwa wymagania. Rozbij więc ten opis na dwa indywidualne wymagania. W przeciwnym wypadku sam generujesz potencjalne problemy z zarządzaniem informacją i śledzeniem powiązań. Wyobraź sobie chociażby sytuację, w której część wymagania jest zaimplementowana, a część nie... Jak oznaczysz to wymaganie? Zaimplementowane częściowo?

  8. Używaj słownika. Słownik to jeden z tych legendarnych artefaktów, o których wspominają między innymi standardy do zarządzania projektami. Uwierzcie na słowo, słowniki potrafią znakomicie ułatwić życie, dostarczając standardu w zakresie używanej w projekcie nomenklatury. Dlaczego słownik jest istotny? Ano zasadniczo dlatego, że w komunikacji z interesariuszami posługujemy się językiem. Język to zestaw symboli, które mogą być interpretowane w różny sposób w zależności od doświadczenia i wiedzy odbiorców, kontekstu, szumów komunikacyjnych.

13 wyświetleń0 komentarzy
Post: Blog2_Post
bottom of page