Co powinniśmy zapamiętać

Co to są i skąd się biorą wymagania użytkownika?

Specyfikacja wymagań użytkownika dostarcza odpowiedzi na kluczowe w procesie zarządzania projektem pytania: Jak obszerna będzie funkcjonalność systemu? Jakie dane będzie przetwarzał system? Kto będzie się posługiwał systemem? Jakie zasoby (ludzie, czas, pieniądze) są potrzebne do zbudowania systemu? Punktem wyjścia dla analityków oraz odbiorców przyszłego systemu przy formułowaniu wymagań użytkownika jest wizja sytemu. Odkrywane wymagania powinny umożliwiać rozwiązanie zidentyfikowanych problemów i pokrywać niezbędne cechy systemu. Jeśli planowany system jest zamawiany na rzecz organizacji biznesowej, to dobrym źródłem wymagań funkcjonalnych na poziomie wymagań użytkownika mogą być opisy procesów biznesowych. Dzięki odniesieniu do szczegółowych czynności procesów biznesowych możemy łatwiej określić konkretne wymagania mieszczące się z zakresie budowy systemu.

Rodzaje wymagań użytkownika

Zgodnie ze strukturą piramidy wymagań, na poziomie wymagań użytkownika formułujemy cztery rodzaje wymagań: funkcjonalne, jakościowe, słownikowe oraz ograniczenia. Jednym z najczęściej spotykanych sposobów zapisu wymagań funkcjonalnych są przypadki użycia systemu. Notacja przypadków użycia jest oparta na bardzo prostych modelach graficznych. Zasadniczo składa się ona z dwóch elementów – aktorów (ikona człowieka) i przypadków użycia (elipsa). Alternatywnym do przypadków użycia sposobem formułowania wymagań funkcjonalnych są historie użytkownika. Opisują one oczekiwania klienta w stosunku do tworzonego systemu za pomocą krótkich zdań mieszczących się np. na kartkach z notesu. Wymagania jakościowe mogą w bardzo znaczącym stopniu wpłynąć na architekturę systemu, a tym samym – na koszt jego wykonania. Bardzo istotne jest zatem, aby zachować zgodność tych wymagań z określoną taksonomią, dzielącą je na rodzaje, np.: Przydatność funkcjonalna, Efektywność wydajnościowa, Kompatybilność, Użyteczność, Niezawodność, Bezpieczeństwo, Łatwość utrzymania i Przenośność. Podobne do wymagań jakościowych są ograniczenia techniczne i środowiskowe. Zawężają one możliwości odnośnie do projektowania i implementacji danego systemu oprogramowania. W słowniku umieszczane są wszystkie pojęcia, stanowiące elementy dziedziny problemu, którą będzie wspierał tworzony system oprogramowania. Pojęcia w słowniku docelowo przekładają się na dane, które będzie musiał przechowywać oraz przetwarzać system.

Organizowanie i dokumentowanie wymagań użytkownika

Najbardziej efektywnym sposobem organizowania wymagań jest zastosowanie odpowiednich narzędzi CASE, posiadających funkcjonalność dla zarządzania wymaganiami. W narzędziu takim możemy stworzyć model wymagań z odpowiednimi diagramami i podzielić go na mniejsze pakiety. Jeśli nie dysponujemy narzędziem CASE, specyfikację wymagań możemy zorganizować w zwykłym procesorze tekstu. Oczywiście, podstawą jest podział dokumentu na sekcje oraz jednostki wymagań. Struktura takiego dokumentu może być podobna do struktury specyfikacji tworzonej przy użyciu narzędzia CASE. Niezależnie od narzędzia, które jest wykorzystywane do zapisywania i zarządzania wymaganiami, klient najczęściej wymaga utworzenia specyfikacji w formie dokumentu podlegającego akceptacji. Wzór takiego dokumentu może być ustalony przez organizację zamawiającą system lub może być elementem warsztatu pracy analityków. Zachowanie spójności i jednoznaczności specyfikacji wymagań znacznie ułatwia określanie zależności między wymaganiami. Takie zależności obejmują ślady łączące wymagania różnego poziomu i różnego rodzaju oraz odniesienia do centralnego słownika dziedziny.

Identyfikacja jednostek funkcjonalnych systemu

Na poziomie wymagań użytkownika potrzebujemy jednostek, które pozwolą dobrze określić zakres systemu oraz ułatwią zarzadzanie projektem. Najczęściej stosowanymi jednostkami funkcjonalnymi są historie użytkownika oraz przypadki użycia. Dobrze określone jednostki funkcjonalne powinny być niezależne, negocjowalne, cenne dla klienta, szacowalne, testowalne oraz mieć małe rozmiary. Identyfikację przypadków użycia lub historii użytkownika może nam ułatwić wstępne zidentyfikowanie grup użytkowników systemu – aktorów lub ról użytkowników. Poszukując aktorów należy pamiętać, że aktor nie odpowiada konkretnej osobie, ale definiuje zakres odpowiedzialności grupy osób w stosunku do systemu. Identyfikując jednostki funkcjonalności systemu należy zawsze pamiętać, że są to przede wszystkim wymagania opisujące funkcjonalność z punktu widzenia użytkowników (ogólnie: obiektów spoza systemu).

Historie użytkownika

Koncepcja historii użytkownika powstała w latach 90-tych XX wieku i jest często wykorzystywana w metodykach zwinnych (agile). Treść historii użytkownika zawiera jedynie najważniejszą informację o zachowaniu się systemu z punktu widzenia przyszłego użytkownika. Odpowiada ona na pytania: Kto? Co? Dlaczego? Najbardziej typowe historie użytkownika mieszczą się na jednej niewielkiej karcie i dotyczą pojedynczego, elementarnego celu osiąganego na rzecz użytkownika. W momencie, kiedy konieczne jest oszacowanie kosztu wykonania, historia użytkownika może być opisana nieco bardziej szczegółowo. Czasami przydatne w trakcie wstępnych rozmów z klientem może być zaproponowanie stworzenia eposów, czyli historii użytkownika, które obejmują pewien szerszy zakres funkcjonalności systemu dotyczący danej roli użytkownika.

Przypadki użycia i aktorzy

Model przypadków użycia został po raz pierwszy wprowadzony w połowie lat 90-tych XX wieku i jest jednym z podstawowych modeli języka UML. Podstawową notacją aktora w języku UML jest ikona człowieka narysowana prostymi kreskami. Aktor definiuje pewną klasę obiektów o jednakowym sposobie zachowania w stosunku do systemu. Możliwe jest stosowanie relacji generalizacji między aktorami. Zbiór aktorów określa granicę między światem zewnętrznym a modelowanym systemem. Przypadek użycia definiujemy jako klasę zachowań modelowanego systemu (tzw. podmiotu), prowadzących do osiągnięcia obserwowalnego, istotnego rezultatu dla jakiegoś aktora (lub aktorów). Przypadek użycia najczęściej definiuje różne warianty zachowania, czyli jego wykonania mogą przebiegać w różny sposób.  Podstawową notacją dla przypadków użycia w języku UML jest ikona elipsy. Na diagramach przypadków użycia umieszczamy aktorów i przypadki użycia wraz z łączącymi je relacjami. Przypadek użycia powinien mieć co najmniej jednego aktora głównego oraz może mieć aktorów pomocniczych. Rodzaj aktora zaznaczany jest poprzez nawigowalność (skierowanie) relacji asocjacji między aktorem a przypadkiem użycia.

Relacje między przypadkami użycia

Standardowymi relacjami między przypadkami użycia są relacje «include» i «extend». Relacja «include» oznacza bezwarunkowe włączenie w treść scenariuszy jednego przypadku użycia, treści scenariuszy innego. Jest ona skierowana w kierunku przypadku użycia włączanego. Relacja «extend» oznacza możliwość wplecenia treści scenariuszy przypadku użycia rozszerzającego w treść scenariuszy przypadku użycia rozszerzanego. Jest ona skierowana w kierunku przypadku użycia rozszerzanego. Wplatanie treści następuje w punktach rozszerzenia, przy czym wplecenie następuje pod określonym warunkiem przypisanym do relacji. Alternatywną do powyższych relacji jest relacja «invoke». Relacja ta ma semantykę podobną do semantyki wywołania procedury. Zawsze jest skierowana od przypadku wywołującego do przypadku wywoływanego.

Opisy historii użytkownika i przypadków użycia

Na poziomie wymagań powinniśmy dokonać opisu poszczególnych jednostek wymagań funkcjonalnych, który jest bardziej szczegółowy niż tylko nazwy tych jednostek funkcjonalnych. Opis ten powinien pozwolić na ocenę złożoność każdej z nich. Opis historii użytkownika nie podlega w istny sposób formalizacji. Mimo to, przyjmuje się, że kompletna historia użytkownika powinna składać się z trzech zasadniczych elementów: karty, konwersacji i konfirmacji. Karta stanowi nazwę historii użytkownika w formie pojedynczego zdania mieszczącego się na niedużej powierzchni (karcie katalogowej). Konwersacja zawiera wynik dyskusji nad szczegółami funkcjonalności w ramach historii użytkownika. Może ona być wyrażona w formie małych historyjek. Konfirmacja zwiera krótki opis możliwych testów. Opis przypadków użycia jest najczęściej nieco bardziej sformalizowany. Może on zawierać krótki akapit tekstu podobny do konwersacji. Ponadto, można uzupełnić opis przypadku użycia o warunek rozpoczęcia i warunki zakończenia. Taki sformalizowany opis może być podstawą do zawarcia kontraktu na budowę systemu.

Sposób opisu wymagań jakościowych

Wymagania jakościowe (pozafunkcjonalne) weryfikujemy poprzez sprawdzenia „jak system robi to, co ma robić”. Istnieją różne klasyfikacje wymagań jakościowych, które dzielą je na różne typy. Z uwagi na wielość klasyfikacji i typów wymagań jakościowych nie istnieje jednolity, sformalizowany sposób ich zapisu. Najczęściej wymagania tego typu tworzone są jako fragmenty tekstu wyrażone w języku naturalnym. Nazwy wymagań jakościowych najczęściej formułuje się w postaci prostych zdań zawierających orzeczenia modalne oparte o czasowniki takie jak musieć, być, zawierać. Na poziomie wymagań użytkownika konieczne jest dokonanie znacznie szerszego opisu. Istotnym elementem tego opisu jest zobiektywizowana metryka. Metryka powinna określać sposób walidacji spełnienia wymagania oraz definiować możliwie obiektywne kryteria akceptacji. Typowa fiszka opisu wymagania jakościowego zawiera: nazwę, standardowe atrybuty, rodzaj wymagania, opis zawierający dokładniejsze informacje oraz metrykę.

Rodzaje wymagań jakościowych

Dwa podstawowe ujęcia klasyfikacji wymagań jakościowych dotyczą kwestii wykonywania programu oraz kwestii ewolucji systemu. Przy pierwszym podejściu wymienia się najczęściej wydajność, użyteczność, bezpieczeństwo oraz przenośność. Druga perspektywa identyfikuje parametry związane z utrzymaniem systemu, takie jak koszt zmian, skalowalność, testowalność, łatwość analizy, stabilność czy dojrzałość. Różne klasyfikacje (taksonomie) wymagań mogą stanowić swego rodzaju listy kontrolne zapewniające kompletność wymagań. Jedną ze starszych, a jednocześnie powszechnie do tej pory stosowanych klasyfikacji wymagań jest model FURPS. Dzieli on wymagania na funkcjonalne (F), użyteczności (U). niezawodności (R), wydajności (P) oraz utrzymania (S). Model FURPS+ dodaje ograniczenia dotyczące procesu projektowania, implementacji, a także związane z interfejsami oraz fizycznym otoczeniem systemu. Norma ISO 9126 dzieli wymagania na dotyczące funkcjonalności (nie mylić z wymaganiami funkcjonalnymi), niezawodności, użyteczności, wydajności, łatwości utrzymania oraz przenośności. Każda z tych kategorii jest dodatkowo podzielona na kilka podkategorii. Pozwala to na znacznie bardziej szczegółową analizę wymagań jakościowych. Rozwinięciem standardu ISO 9126 jest standard ISO 25010. Dzieli on wymagania jakościowe na wymagania przydatności funkcjonalnej, efektywności wydajnościowej, kompatybilności, użyteczności, niezawodności, bezpieczeństwa, łatwości utrzymania oraz przenośności.

Formułowanie metryk dla wymagań jakościowych

W przypadku wymagań jakościowych, sformułowanie obiektywnych miar ich spełnienia nie jest zadaniem łatwym. Wynika to przede wszystkim z dużej różnorodności wymagań tego typu oraz braku precyzyjnego sposobu ich formułowania. Na poziomie wymagań potrzebujemy dobrze określonych metryk wraz z opisem sposobu pomiaru i oczekiwanymi wynikami. Metryki wymagań określają sposoby dokonywania pomiarów oraz weryfikacji spełnienia określonych parametrów jakościowych systemu. Metryki powinny mieć trzy elementy: przedstawienie sposobu pomiaru, określenie zbioru możliwych wartości pomiaru oraz określenie oczekiwanych wartości pomiaru. Istnieje kilka klas procedur pomiarowych dla wymagań jakościowych: dokonanie bezpośredniego pomiaru parametrów systemu (eksperyment), przeprowadzanie audytów, wykonanie ankietyzacji, przeprowadzenie sprawdzianów oraz symulowanie zdarzeń. Stosunkowo oczywistymi do zmierzenia są wymagania wydajności. W przypadku wymagań użyteczności, najczęściej chcemy zmierzyć wysiłek jaki użytkownicy systemu wkładają w korzystanie z jego funkcjonalności. Użyteczność podlega najczęściej weryfikacji poprzez ocenę użytkowników systemu oraz ekspertów ergonomii systemów informatycznych. Ocenie podlegają m.in. różne aspekty „doświadczeń użytkownika”  (user experience). Testowanie wymagań bezpieczeństwa systemów często polega na przeprowadzeniu audytów przez wyspecjalizowane organizacje (np. kontrolowana próba „włamania” do sytemu), czego efektem jest uzyskanie certyfikatu bezpieczeństwa. Wymagania kompatybilności i przenośności możemy weryfikować korzystając ze środowisk-emulatorów, co pozwala zbadać działanie systemu w różnych konfiguracjach sprzętowych i programowych. Testowanie cech oprogramowania związanych z ich utrzymaniem polega często na oszacowaniu kosztu (wysiłek, czas) różnych czynności związanych z utrzymaniem – poprawienia błędu, rozszerzenia o nową funkcję czy też bieżącej obsługi systemu.

Ograniczenia techniczne i środowiskowe

W przypadku ograniczeń technicznych i środowiskowych nie mamy określonych procedur weryfikacyjnych, gdyż ograniczenia są narzuconymi cechami warsztatu deweloperskiego lub otoczenia systemu. Są to zatem rządzące procesem wytwarzania danego systemu oprogramowania. Ograniczenia techniczne dotyczą technologii, jakie zespół deweloperski musi zastosować podczas budowy systemu. Ograniczają one stopień swobody w wyborze architektury, sprzętu czy narzędzi programistycznych. Najważniejsze typy ograniczeń technicznych to: ograniczenia dotyczące języków programowania, ograniczenia dotyczące środowiska deweloperskiego, ograniczenia dotyczące stosowanego sprzętu, oraz ograniczenia dotyczące stosowanych komponentów programowych. Najważniejsze typy ograniczeń środowiskowych to: ograniczenia dotyczące parametrów fizycznych środowiska, ograniczenia dotyczące zachowań i możliwości użytkowników, oraz ograniczenia dotyczące infrastruktury nieinformatycznej. Należy zwrócić uwagę na to, że zgodność z normami prawnymi najczęściej nie jest ograniczeniem, lecz wymaganiem jakościowym określonego rodzaju. Nałożone ograniczenia mogą powodować sytuacje, kiedy spełnienie wymagań jakościowych będzie niemożliwe.