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.
“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.
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:
Pobierz wykres w formacie FreeMind.
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ą.
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.
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. | |
