5 x „C”
Firma IAG na swoim blogu proponuje zasadę pięciu "C", która pozwala zadbać o wysoką jakość wymagań. Oto one:
- 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)
- 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
- 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
- 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
- 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
15 pytań
Na blogu firmy IAG można znaleźć ciekawy post z piętnastoma pytaniami, które warto zadań podczas sesji zbierania wymagań. Oto one:
- Czy mógłbyś podać więcej szczegółów, tak abym mógł lepiej Cię zrozumieć? Dzięki temu uzyskami więcej danych oraz lepiej zrozumiemy punkt widzenia rozmówcy.
- Czy mógłbyś podzielić się ze mną swoim rozumieniem tego, o czym przed chwilą mówiliśmy? Unikniemy dzięki temu nieporozumień wynikających z błędnego rozumienia drugiej osoby.
- Czy mógłbyś pomóc mi i zaklasyfikować te punkty? Pomoże nam to zorganizować fakty dotyczące wybranego tematu.
- Czy moglibyśmy porównać to stwierdzenie do tego, o czym mówiliśmy wcześniej? Pozwoli nam to lepiej zrozumieć rozmówcę, a także odkryć podobieństwa oraz różnice w wymaganiach.
- Czy mógłbyś zdefiniować ten termin, abym mógł go lepiej zrozumieć? Pomoże nam to utworzyć słownik pojęć i ustanowić wspólny język.
- Czy mógłbyś opisać przykładową sytuację, w której miałoby to zastosowanie? Dzięki odpowiedzi na to pytane możemy odkryć procesy, scenariusze kierujące naszym oprogramowaniem oraz warunki, jakie musi ono spełniać.
- Czy możemy porozmawiać o ograniczeniach oraz konsekwencjach tego rozwiązania? Pozwoli nam to lepiej zrozumieć omawiane wymagania.
- Możesz mi wyjaśnić, jak doszedłeś do takiego wniosku? Wyjaśnimy dzięki temu stopień wspólnego zrozumienia tematu.
- Czy możesz mi podać przykład, w jaki miałoby to działać? Dzięki przykładom lepiej zrozumiemy wymagania.
- Co jeszcze? Żeby o niczym nie zapomnieć.
- Jak rozumiesz (...)? Aby sprawdzić, czy myślimy w taki sam sposób.
- Dobra uwaga! Czy możemy ją dodać do listy spraw otwartych? Pozwoli nam to wrócić do głównego wątku rozmowy.
- Innymi słowy chodzi o to (...), tak? W taki sposób sprawdzisz, czy wszystko dobrze zrozumiałeś.
- Czy moglibyśmy przejrzeć punkty, które do tej pory przerobiliśmy? Pozwoli nam podsumować dotychczasową rozmowę.
- W jaki sposób możemy zweryfikować, czy na pewno o to chodzi? Uzyskamy dzięki temu informację, o źródle wymagania i dowiemy się, czy na pewno ma ono sens.
Spróbujcie wykorzystać te i podobne pytania podczas swoich kolejnych spotkań z klientami. Jestem ciekawe efektów, które uzyskacie.
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?