W pisaniu specyfikacji jest masa dobrych praktyk. Głównie prezentowane jest to co taka specyfikacja powinna zawierać i można te praktyki stosować tak jak chcecklistę. Przebrnięcie przez opasłą specyfikację jest ciężkie i wymaga czasu a napisanie dobrej specyfikacji wymagań jest jeszcze cięższe i wymaga jeszcze więcej czasu. No i jako analitycy musimy być świadomi tego że dłuższa specyfikacja nie oznacza lepszej specyfikacji. Możemy się ostro napracować i ktoś stwierdzi że specyfikacja jest zbyt długa i nie chce mu się jej czytać. Dlatego gdy zobaczyłem ciekawe badanie gdzie przeprowadzono badanie ruchu oczu to stwierdziłem że warto jest o tym opowiedzieć na blogu.

Przedstawienie badania

Przed badaniem postawiono sobie 3 cele badania:

• zbadać potrzeby informacyjne czytelników w zależności od ich roli i środka prezentacji,
• które działy specyfikacji są najważniejsze i najmniej ważne w zależności od roli czytelnika,
• który rodzaj środka przekazu(papier czy monitor) jest lepszy do czytania dla czytelnika

Do badania wykorzystano urządzenia do śledzenia ruchu gałek ocznych. Przeprowadzono je na Uniwersytecie w Hannoverskim (Leibniz Universität Hannover) w spokojnym i cichym pokoju uniwersyteckim. Każdy badany był umawiany osobno.

Podczas badania uczestnik miał 20 minut na przeczytanie specyfikacji i rozwiązanie zadań do specyfikacji. Wprowadzono limit czasowy po to aby:

• Wprowadzić normalny klimat pracy z racji że programiści pracują głównie pod presją czasu.
• Przy limicie czasowym czytający musi się skupić na najważniejszych(w jego oczach) aspektach specyfikacji

Po przeprowadzeniu badania uczestnik otrzymywał ankietę gdzie oznaczał które sekcje dokumentu były dla niego najbardziej istotne. Następnie przeprowadzono kolejny test gdzie użytkownik otrzymywał kolejną specyfikację.

Specyfikacja była złożona z następującego spisu treści.

1. Misja projektu
   1. Cel projektu
   2. Potrzeby i priorytety klienta
   3. Opis domeny
   4. Metody analizy wymagań
2. Zakres projektu
   1. Ograniczenia i wskazania
   2. Użytkownicy
   3. Interfejsy oraz systemy współpracujące
3. Wymagania funkcjonalne
   1. Diagram przypadków użycia
   2. Przypadki użycia
   3. Wymagania techniczne
4. Wymagania niefunkcjonalne
   1. Cele jakościowe projektu
   2. Cele jakościowe klienta
   3. Metody realizacji celów jakościowych
5. Problemy oraz ryzyka
6. Środki rozwiązania problemów
   1. Prawdopodobne kompromisy
   2. Praca przyrostowa
7. Mockupy
8. Słownik

Wyniki

Kolumny powyższej tabeli przedstawiają sekcję dokumentacji oraz role jakie pełnili uczestnicy badania. Na każdą rolę są dwie kolumny. Jedna kolumna przedstawia ocenę istotności danego czytelnika a druga kolumna ocenia istotność względem tego co wskazywały urządzenia do śledzenia ruchu gałek ocznych. Oceny mamy ustawione od 1 do 4. Cztery(4) oznacza że dana sekcja była nieistotna a jeden(1) oznacza że sekcja była bardzo istotna.

Co widać od razu?

Na pierwszy rzut oka zobaczmy co jest najważniejsze. Najważniejsze to cel projektu i potrzeby klienta. Czyli to co zawsze wszyscy początkujący pomijają czyli odpowiedź na pytanie „A właściwie po co my to wszystko chcemy zrobić?” czyli to o czym mówię w wielu moich wpisach np. TUTAJ.

Ten nacisk na cel projektu jest bardzo ważny. To jest wręcz kluczowa rzecz jeśli chodzi o pracę analityka. Po to jest to stanowisko żeby o tym pamiętać. Za to Ci dana organizacja płaci pieniądze(coraz częściej niemałe) abyś o tym pamiętał. Więc PAMIĘTAJ i uwzględniaj to w swojej specyfikacji zawsze.

Niektóre wyniki są dość proste do przewidzenia(wiadomo że UI Designer będzie patrzeć na to jak wyglądają mockupy albo że dla testera najważniejsze będą przypadki użycia). Jednak są też rzeczy które mnie zaciekawiły w drugą stronę. Tymi rzeczami są:

• Totalne olanie słownika. Zawsze uważałem słownik za mega istotną rzecz dla osoby która czyta dany dokument pierwszy raz. Jak widać wcale tak nie jest bo nikt z badanych nie oznaczył go jako ważny a raczej jako mało istotny szczegół. Tutaj wydaje mi się że jest to trochę jak ze zdrowiem. Doceniamy swoje zdrowie w momencie gdy go nie mamy. I tak samo doceniamy słownik w momencie gdy mamy pojęcia których nie rozumiemy i brakuje dla nich objaśnienia.
• Bardzo niska ocena „ograniczenia i wskazania” przez Architektów. Też ciekawa kwestia. Zawsze mówi się że wymagania niefunkcjonalne mają bardzo duży a wręcz kluczowy wpływ na to jak wygląda architektura rozwiązania. A tu patrzymy i jest nisko. Dziwne. Może być tak że te ograniczenia były zbyt słabe i dlatego Architekci ocenili je tak nisko.
• Wysoko ocenione cele jakościowe przez architektów przy słabej intensywności czytania co wskazały przyrządy śledzące ruch gałek ocznych.

Podsumowanie

Badanie bardzo ciekawe. Celem badania było zbadanie co jest ważne dla każdej osoby czytającej i swoją rolę spełniło. Jednak chciałbym podkreślić jedną rzecz. Rolą tego badania nie było odkrycie które sekcje specyfikacji należy usunąć. Ja osobiście bym nie pomijał czegokolwiek.

A co zaciekawiło Ciebie? Daj mi znać! Zapraszam do dyskusji.

Źródła

(Lecture Notes in Computer Science 9619) Maya Daneva, Oscar Pastor (eds.) – Requirements Engineering_ Foundation for Software Quality_ 22nd International Working Conference, REFSQ 2016, Gothenburg, Sw-1 strona 301