rss

Lekarstwo na sklerozę

Zbieranie wymagań to trudny i żmudny proces, od którego później zależy przebieg całego projektu. Długie spotkania, męczące rozmowy, marudni klienci. Nazbyt łatwo jest jakiś aspekt przeoczyć, który później w najgorszym możliwym momencie o sobie przypomni. Jest sposób, żeby sobie w tym procesie pomóc.

Michał Paluchowski, 17 września 2009

Czy te strony mają być przystosowane do drukowania?” To świetne pytanie do zadania w trakcie zbierania wymagań do projektu aplikacji internetowej. Wtedy zapisujemy odpowiednie wymagania, planujemy funkcje i czas na ich wykonanie. Nieco gorzej jeśli takie pytanie pojawia się na dwa czy trzy tygodnie przed terminem oddania gotowego projektu.

Jeszcze gorzej kiedy klient stwierdzi: „rozumiem, że będziemy mogli te strony drukować?” Wtedy w pomieszczeniu może zapaść chwila niewygodnej ciszy, po czym pojawią się sugestie, że nie ujęto tego w początkowych wymaganiach i może trzeba będzie przesunąć termin oddania oraz podnieść cenę. Reakcję klienta łatwo sobie wyobrazić.

Zbierając wymagania do projektu zawsze coś „ucieknie”. Zawsze będą funkcje, o których nie pomyśleliśmy, wymagania, których nam nie przekazano i potrzeby, o których zapomniał klient. Agile radzi z tym sobie zakładając z góry, że takie nowe informacje będą się pojawiać w dowolnym momencie trwania projektu i kiedy się pojawią, mogą zostać opisane, a następnie wykonane, kosztem pominięcia innych.

Niezupełnie sprawdza się to jednak w przypadku projektów, w których klient akceptuje wyłącznie wcześniej ustaloną cenę za wykonanie, bez możliwości przesuwania terminów czy powiększania kwot. Wtedy planując projekt zakładamy jakiś bufor na nieprzewidziane zachcianki i liczymy na to, że nie zostanie przekroczony. Można sobie jednak podczas zbierania wymagań pomóc.

FURPS+

Robert Grady, mądry człowiek z firmy Hewlett Packard, autor książki Practical Software Metrics for Project Management and Process Improvement, opracował system klasyfikacji wymagań nazwany FURPS+, co jest skrótem od:

Dodatkowy „+” na końcu nazwy przypomina również o następujących kwestiach:

Każdy z powyższych obszarów podzielony jest na kategorie – łącznie 40, opisujących wszystkie możliwe aspekty wymagań wobec systemu komputerowego. Wydaje się, że taki system mógł być tworem jedynie Behemota pokroju Hewlett-Packard i tylko tam się może przydać pośród tomów opasłej dokumentacji projektowej, rządzonej modelem Waterfall.

Samą listę można jednak wykorzystać w dowolnie małym jak i dużym projekcie:

Wykres FURPS+

Wystarczy wydrukować taki diagram (lub jak kto woli przekształcić go na listę), powiesić koło biurka i korzystać za każdym razem gdy zbieramy wymagania. Czy program ma przesyłać pocztę? Sprawdzone. Jaki ma mieć panel administratora? Sprawdzone. Czy ma korzystać z konkretnych bibliotek? Sprawdzone.

Za każdym razem przechodzimy po tej liście punkt po punkcie i sprawdzamy czy każdy jej element jest zawarty w wymaganiach. Lokalizacja (wielojęzyczność) nie jest wymagana? Dobrze, to też należy explicite zapisać w dokumencie, który później ma zatwierdzić klient. Dobry zestaw wymagań zawiera zarówno te, które mają znaleźć się w systemie, jak i te, które tam się nie znajdą.

Czy chciałbyś powiększone frytki i napój?

Broń Boże nie wolno traktować takiej listy jako bezpośrednich pytań do klienta. Rozmowa zamieni się za chwilę w koncert życzeń:

Konsultant: Jakiej oczekuje pan dostępności?
Klient: Przez całą dobę, siedem dni w tygodniu. Żadnych przestojów.
Konsultant: Czy potrzebna jest pomoc kontekstowa?
Klient: Tak, na pewno się przyda.
Konsultant: Czy mamy zaimplementować interfejs wielojęzyczny?
Klient: Jak najbardziej – kiedyś możemy zechcieć wyjść na rynki zagraniczne.
Konsultant: Czy program ma podawać kawę i ciastka?

i tak dalej. Cokolwiek się nie spyta, klient zawsze powie „tak”. Wiadomo jednak, że nie wszystko warto robić, a niektórych elementów się wręcz nie da, biorąc pod uwagę ograniczony czas i środki. Lista kategorii ma nam pomóc zebrać wszystkie wymagania, ale my z kolei musimy pomóc klientowi zebrać te, których rzeczywiście potrzebuje.

Pamiętaj też by porozmawiać ze wszystkimi osobami, które mają mieć z systemem styczność. Nie tylko z szefem firmy ale i z pracownikami, którzy na co dzień będą go używać. To do nich później szef się zwróci z pytaniem, czy oddany system spełnia wymagania. Jeśli im się nie spodoba, powiedzą to szefowi i zaczną się problemy.

Tylko co to znaczy?

Na deser prezentuję wszystkie kategorie z krótkim tłumaczeniem która co zawiera. Tłumaczenie nazw jest moje i niektóre przyprawiłyby moją polonistkę z siódmej klasy o arytmię. Liczę jednak na to, że dla przeciętnej osoby zamieszanej w produkcję oprogramowania będą zrozumiałe.

Funkcjonalność
Audyt Funkcje zapisujące i udostępniające zapisy czynności wykonywanych przez system i użytkowników.
Licencjonowanie Funkcje zarządzania licencjami, ich pozyskiwania i monitorowania. Np. licencje jednostanowiskowe czy sieciowe.
Lokalizacja Możliwości wprowadzenia wielu języków interfejsu.
Poczta Wysyłanie i otrzymywanie poczty.
Pomoc Pomoc dostępna dla użytkowników wewnątrz programu – ogólna, kontekstowa itd.
Drukowanie Możliwości drukowania informacji w systemie.
Raportowanie Dostępność i rodzaje raportów, możliwości tworzenia własnych.
Bezpieczeństwo Ograniczenia dostępu do informacji i funkcji systemu.
Administracja Zarządzanie informacjami w systemie.
Mechanizmy Sekwencje pracy nad informacjami w systemie – np. kolejność tworzenia i zatwierdzania dokumentów przez wielu użytkowników.
Używalność
Dostępność Łatwość używania. Jakiej wiedzy wymaga system od użytkownika? Jakiego poziomu sprawności manualnej? Czy będą używać go niepełnosprawni?
Estetyka Estetyczne właściwości systemu – kolory, układy elementów itp.
Spójność Jakie mechanizmy muszą działać w identyczny sposób w całym systemie? Z jakimi innymi systemami nasz powinien być spójny?
Niezawodność
Dokładność Jak dokładne powinny być wszystkie obliczenia.
Dostępność Jak długo system powinien działać bezbłędnie, np. 99,9% czasu.
Mechanizmy naprawcze Z jakimi błędami system powinien sobie umieć poradzić? Na przykład niedobór pamięci, awaria dysku czy rozłączenie sieci.
Wydajność
Czas naprawy Jak szybko system powinien wrócić do stanu normalnego po awarii?
Czas odpowiedzi Jak szybko system powinien odpowiadać na zapytania?
Czas wyłączania Jak długo system powinien się wyłączać?
Czas uruchamiania Jak długo powinien się włączać?
Przepustowość Jak duże obciążenie (np. ilość użytkowników jednocześnie) system powinien obsługiwać?
Wsparcie
Adaptowalność W jaki sposób system powinien być możliwy do zaadoptowania do nowych warunków?
Audytowalność Dostępność zapisów operacji wykonanych przez system.
Kompatybilność Zgodność z poprzednimi wersjami.
Konfigurowalność Opcje konfiguracji parametrów systemu.
Instalowalność Łatwość instalacji – czy powinien być kompilowany, mieć instalator czy być spakowany w ZIP?
Lokalizowalność Czy i do jakiego stopnia system powinien obsługiwać wiele języków?
Utrzymywalność (Serwisowalność) Mechanizmy kontroli i naprawy systemu, np. dostępność informacji w logach, podłączanie debuggerów.
Skalowalność Sposoby zwiększania przepustowości systemu przy rosnącym obciążeniu.
Testowalność Możliwości testowania systemu – ręczne i automatyczne.
Projekt
Ogólna architektura systemu – na przykład wymóg wykorzystania relacyjnej bazy danych lub jej brak, interfejs graficzny lub linia poleceń.
Implementacja
Zewnętrzne komponenty i biblioteki Ograniczenia lub wymogi co do wykorzystywania gotowych bibliotek.
Języki implementacji Języki, w których ma zostać wykonany system.
Wsparcie dla platform Na jakich platformach i systemach operacyjnych powinien działać?
Ograniczenia zasobów Jakie zasoby ma mieć do dyspozycji? Pamięć, przestrzeń dyskową, przepustowość sieci itd.
Zgodność ze standardami Z jakimi standardami ma być zgodny system.
Interfejsy
Systemy zewnętrzne Z jakimi zewnętrznymi systemami ma się komunikować.
Format interfejsów Formaty danych, przez które system będzie się komunikował z innymi systemami.
Fizyczne
Kształt, rozmiar i waga mają zastosowanie jedynie w przypadku przedmiotów fizycznych, na przykład serwerów czy bibliotek taśmowych.