Mina 04 - NFR: Wymagania Niefunkcjonalne

Wymagania niefunkcjonalne (ang. Non-Functional Requirements - NFR) są to wszystkie wymagania opisujące ograniczenia systemu lub wymogi jakie produkt musi spełniać, aby sprostał określonej klasyfikacji. W szczególności to tych aspektów zaliczamy możliwość śledzenia wymagań funkcjonalnych przez cykl życia projektu do kodu źródłowego (ang. traceability), dostępność (ang. availability) czy jakość interfejsu użytkownika (ang. usability).

Z punktu widzenia sukcesu projektu są to zwykle elementy projektu nie mniej ważne jak sama dostarczana funkcjonalność. Czym będzie system bankowy, który nie obsłuży 100 klientów na raz, albo edytor tekstu z kompletnie nieprzemyślanym interfejsem użytkownika.

W metodykach lekkich skupienie jest na iteracyjnym dostarczaniu funkcjonalności. Emfaza położona jest na to jak klientowi dostarczyć kawałki funkcjonalne coraz lepiej dopasowane do jego rzeczywistych potrzeb. Rodzi to naturalne pytanie co z elementami niefunkcjonalnymi? Pytanie to nie jest bezzasadne, bo parę razy udało mi się o nich zapomnieć, na szczęście zawsze ktoś życzliwy z boku odpowiednio wcześnie zadał parę mądrych pytań i uratował sytuację.

Jedną z rad jakie się spotyka to próba przekształcenia wymagań niefunkcjonalnych w wymagania funkcjonalne. Pytanie więc czy rozwiązuje to wszystkie problemy i pozwala kompleksowo podejść do problemu wymagań niefunkcjonalnych, moim zdaniem nie. Jest to mina przez którą można doznać znacznych opóźnień w projekcie, a czasem i poważnych problemów architektonicznych.

Pytania jakie stawiam, by zbadać naturę tej miny to:

Jakie są mechanizmy w metodykach lekkich zapewniające tracebility?
O ile śledzenie ścieżek od wymagania do kodu źródłowego jest wpisane wręcz w takie metodyki jak RUP, to XP czy Scrum nie zawiera jawnie żadnych elementów, które pozwalałyby na to. Wręcz przeciwnie, inicjalna dokumentacja jest z definicji tylko na początek i powinna być wyrzucona jak tylko przejdzie przez iterację i zastąpiona testami akceptacyjnymi oraz jednostkowymi, gdzie zapisane są szczegóły ustaleń funkcjonalnych, które następują w trakcie iteracji dzieki aktywnej współpracy klienta (lub jego proxy).
Dla ścisłości dodam, że Kent Beck w eXtreme Programming Explained 2nd Edition na samym końcu wspomina krótko o tym problemie, ale proponowane rozwiązanie sprawia wrażenie dopisanego do całości na kolanie w parku przed biurem wydawcy w przeddzień publikacji. Wniosek raczej taki, że radzić sobie trzeba z tym jak kto umie. Póki co na szczęście nie spotkałem się z takim wymaganiem w swoich projektach.

W jaki sposób zautomatyzować testy jakości interfejsów użytkownika (usability)
O ile można napisać kartę wymagań o treści "graficzny interfejs użytkownika jest intuicyjny i przyjemny" o tyle kata karta nie spełnia podstawowych wymagań jakie stawiamy kartom. Nie jest automatycznie weryfikowalna. A przynajmniej takie metody nie są mi znane. Zrzucenie tego na testy manualne w obliczu tygodniowych iteracji (czyli zmian w interfejsach GUI) podczas wielomiesięcznego projektu raczej graniczy z obłędem. Nie twierdzę, że automatyzacja jest jedynym wyjściem, bo moim celem nie jest sama automatyzacja. Patrząc zaś na cel jaki dzięki automatyzacji osiągam dostrzegam inne rozwiązania takie jak segmentacja obszarów funkcjonalnych i uszeregowanie dewelopmentu zgodnie z nimi, to pozwoli już ograniczyć zakres manualnych cykli testowych. Wyprzedzająca analiza i podstępujący projekt graficzny wyprzedzający o kilka iteracji dewelopment. I inne tego typu rozwiązania, niektóre nie do końca agile'owe, ale orderów tu nikt raczej rozdawać nie będzie, a królowa jest tylko jedna :P.

Czy jest wsparcie do testowania dostępności w metodach iteracyjnych?
Testy dostępności są oczywiście automatyzowalne, ale w niektórych przypadkach niestety kompletnie nie dają się zastosować w ciasnych agile'owych iteracjach, bo na przykład zajmują kilka dni. Więc by-the-book już postępować nie można. Każda zaś iteracja potencjalnie może nieść zmiany, które będą miały wpływ na pożądaną dostępność systemu. Problem nie występuje w prostych przypadkach, gdy np chcemy przetestować współbieżną dostępność serwisu dla kilku użytkowników. Z drugiej strony testy dostępności typu "pięć dziewiątek" (99,999%) już raczej nie będą dały się tak zgrabnie ogarnąć. Podejście jakie bym w tym przypadku przyjął jest analogiczne do poprzedniego problemu, czyli segmentacja funkcjonalności i uruchamianie testów w tle. Kiedy się skończą to się skończą, jeśli nie możemy poznać ich wyników wcześniej, to trudno, hope for the best i jedziemy dalej z projektem. Jak się testy zakończą to najwyżej będziemy musieli coś poprawić z poprzednich iteracji. Moje podejście jest proste w tym wypadku, jak się nie ma co się lubi, to się lubi co się ma. Jeśli ktoś ma mądrzejsze pomysły to bardzo chętnie posłucham.


Podsumowując tę minę, to jak widać za wiele świetnych rozwiązań do niej nie mam opatentowanych, poza jednym - pamiętać o tych wymaganiach, bo obracając się w świecie feature-driven można je łatwo pominąć. Próbować je przebranżowić na wymagania funkcjonalne i przemycić do backloga projektu w takim płaszczyku. Jeśli się to nie uda to nie płakać tylko spisać je na wiki i zarządzać nimi jak każdym innym ryzykiem projektowym i dla konkretnego przypadku świadomie rozważyć najwłaściwszy model postępowania.