Cześć,
W dzisiejszym wpisie pogadamy o najczęściej używanej metodzie opisu wymagań biznesowych czyli o… Formie tekstowej.
Jest najczęściej używana bo:
- Jest łatwa
- Każdy ją rozumie
- Szybko się tworzy
No i wszystko byłoby fajnie tylko z formą tekstową pojawia się kilka problemów:
- Ciężko jest utrzymywać dokumentację napisaną w formie zwykłego tekstu
- Często popełniamy błędy pisząc dokumentację w formie tekstowej
- Często wymaganie w formie tekstowej tworzy kilka wymagań biznesowych w jednym i pojawia się problem z granulacją.
- Bardzo łatwo jest popełniać błędy
Jak widać z głowy potrafię rzucić minusów więcej niż plusów więc raczej to nie jest to za szczęśliwa forma prezentacji wymagań. Jednak często liczy się czas i wygoda… A skoro już tak piszemy wymagania to piszmy je dobrze. Bez głupich błędów.
No i o tych błędach dzisiaj.
- Ale przecież to oczywiste
Na pierwszy ogień idzie robienie założeń przez interesariuszy ale i przez analityków. Poznając dany kontekst systemu zaczynamy poznawać pojęcia używane przez interesariuszy. Tworząc dokument z wymaganiami chcąc lub nie wplatamy te pojęcia w dokumencie potem dodajemy je do słownika. Zdarzy się że pominiemy jakieś pojęcia i wychodzi klops.
„No bo przecież to oczywiste co to znaczy X.”, „Jak możesz tego nie wiedzieć?”.
Ano mogę.
Jak sobie z tym poradzić? Najprościej to poprzez checklisty czy tworzenie słownika na sam koniec przed przekazaniem do developmentu.
2. Brak możliwości stwierdzenia jaki ma być efekt końcowy
Często wymaganie jest napisane w taki sposób że nie jesteśmy w stanie odpowiedzieć jasno na pytanie.
„A co to ma dokładnie zrobić? Wyświetlić coś? Wyliczyć coś? Pobrać coś?”
Jak sobie tu poradzić? Najprościej to stosować prosty szablon.
DZIEJE SIĘ RZECZ X TO SYSTEM ROBI RZECZ Y
Czyli znany i lubiane podejście typu BlackBox.
3. Czasowniki opisujące proces
Często opisujemy cały proces za pomocą jednego słowa. Co jest karygodnym błędem.
Przykład:
„Po prawidłowym przekazaniu system powinien wyświetlić powiadomienie”
Dobra, tutaj mamy kilka błędów ale skupmy się na tym czasowniku(o reszcie później)
Przekazaniu – Czego? Skąd? Gdzie? W jaki sposób?
Nawet jeśli podczas innych wymagań napiszemy co to oznacza to może się zdarzyć że programiści podzielą się pracą i znając ludzkie lenistwo taka osoba nie zapozna się z całym dokumentem(a i nie musi bo wymagania powinny być „ładnie” podzielone).
4. Nieopisane kwantyfikatory
Kwantyfikatory czyli „wszystkie”, „dla każdego”.
Najczęściej widzę wymaganie które brzmi mniej więcej tak.
„Kafelek ma być widoczny dla każdego użytkownika poza XYZ”.
No to w końcu dla każdego czy dla XYZ? Pomijając kwestię tego że wymaganie się wyklucza to jaką mam pewność że jeszcze pominąłeś kogoś?
Nie używajmy takich uproszczeń.
5. Niekompletne warunki do spełnienia
Kolejną plagą jest określenie niekompletnych warunki do spełnienia.
Przykładowo
„Dla dorosłych system powinien wyświetlać słowa bez cenzury”.
A kto to jest dorosły? W różnych krajach mamy różnych dorosłych. Dorosły to może też być 16latek. Aczkolwiek tutaj też robię założenie że dorosły jest uzależniony od wieku. Przecież może tak nie być…
Abstrahując od cenzury która nie jest opisana 😉
6. Rzeczowniki bez objaśnienia
Bardzo często piszemy rzeczowniki bez objaśnienia co one oznaczają.
Przykład
„Dane powinny być przekazane w formie dokumentu w formacie pdf…”
Dane czyli co? Jakie wartości? Dokument czyli co dokładnie? Co ma ten dokument zawierać?
7. Niemierzalne wartości
Tutaj najprościej jak się da:
„System powinien umożliwić sortowanie po cenie, odległości, ilości materiałów.”
Jakiej odległości? Odległości od czego? Jaka jest jednostka ilości materiałów? Metry kwadratowe? Kilogramy?
8. Może ty mi podrzucisz jakieś typowe przykłady? Napisz w komentarzu.
