en

Trudno przecenić znaczenie dobrze zdefiniowanych wymagań w procesie realizacji projektu informatycznego. Warto też mieć świadomość jak wielkie ryzyko pojawia się, gdy wymagania są źle zdefiniowane. W naszej firmie proces analizy wymagań traktujemy jako wyjątkowo ważny i podchodzimy do niego ze szczególną uwagą.

W trakcie wielu lat naszej pracy stworzyliśmy wiele specyfikacji wymagań dla tworzonych przez nas aplikacji i nieustannie udoskonalaliśmy warsztat. Niektóre ze stworzonych przez nas specyfikacji miały ponad 200 stron i były punktem odniesienia w projektach realizowanych przez ponad rok przez kilkudziesięcioosobowe zespoły. Do przygotrowania analizy wymagań wykorzystujemy sprawdzone szablony dokumentów oraz techniki prototypowania, co pozwala na sprawne i precyzyjne określenie jaki kształt ma mieć tworzony system.
Specyfikacje wymagań tworzymy zarówno jako jeden z etapów realizacji projektu jak również jako autonomiczną usługę.

Analiza wymagań (analiza przedwdrożeniowa)
Nasi analitycy na podstawie dostarczonych dokumentów definiujących wymagania biznesowe (BRS) stworzą szczegółowe wymagania względem tworzonego oprogramowania (SRS). Mogą też pomóc w najwcześniejszym etapie przy tworzeniu dokumenty wymagań biznesowych w ramach konsultacji.

W trakcie ostatnich kilku lat stworzyliśmy wiele specyfikacji wymagań względem oprogramowania (SRS). Niektóre z nich zawierały ponad 200 stron i opisywały dziesiątki funkcjonalności i procesów wymaganych przez biznes. Opisane przez nas wymagania stanowią zazwyczaj załączniki do umów na wykonanie i wdrożenie oprogramowania. Dokument wymagań jest też produktem samym w sobie. 
Realizowaliśmy dokumenty SRS zarówno w ramach samodzielnych projektów tylko na dostarczenie wymagań, jak i w ramach pełnych projektów (braliśmy udział w dalszych fazach: implementacja, wdrożenie, utrzymanie).
Wszystkie dokumenty wymagań tworzymy w oparciu o sprawdzony szablon opisany w znakomitej książce Software Requirements, 2nd Edition, by Karl E. Wiegers (Microsoft Press, 2003).
 
Proces zbierania wymagań
Poniższy graf dobrze obrazuje proces tworzenia dokumentu SRS przed rozpoczęciem projektu.
 

Proces zbierania wymagań rozpoczyna się od zebrania wymagań biznesowych (BRS - Business Requirements Specification). Są to opisane cele biznesowe firmy, które mają być osiągnięte dzięki tworzonemu oprogramowaniu. Taki dokument jest pisany z perspektywy biznesu i zawiera tylko ogólne wymagania jakie ma spełniać nowy system. Zazwyczaj jest tworzony przez Klienta przed rozpoczęciem projektu.

O ile jest taka potrzeba (dla większych projektów) na podstawie dokumentu BRS nasi analitycy przygotowują Dokument Wizji. Jest to zwięzły dokument inicjujący projekt. Ma on następującą strukturę [wzorowaną na przykładach Karla E. Wiegersa]:

  • Wymagania biznesowe
    • kontekst biznesowy projektu,
    • cele biznesowe,
    • kryteria sukcesu projektu,
    • potrzeby użytkowników,
    • ryzyka biznesowe,
  • Wizja rozwiązania
    • ogólny opis systemu,
    • listę jego cech,
    • założenia i zależności
  • Zakres i ograniczenia
    • zakres funkcjonalności w poszczególnych wersjach
    • opis czego system nie będzie zawierał
  • Kontekst biznesowy
    • opis wszystkich interesariuszy w projekcie
    • opis priorytetów projektu

Po zatwierdzeniu dokumentu przez wszystkich uczestników projektu następuje przejście do fazy zbierania wymagań użytkowników. Odbywa się to zazwyczaj poprzez serwie spotkań-warsztatów/wywiadów na których przechodzi się przez kolejne funkcjonalności systemu wpisane w analizowany proces biznesowy.
Podczas tych warszatów analitycy tworzą przypadki użycia lub historie użytkownika. Takie dokumenty opisują szczegółowo proces interakcji użytkownika z aplikacją (możliwe są też interakcje pomiędzy systemami). Czasmi tworzone są makiety (prototypy) interfejsu użytkownika w formie obrazu formularza. Taki obraz czasami pozwala na lepsze wyobrażenie sobie zachowania systemu. Pozwala też na podwyższenie ergonomii interfejsu użytkownika.
Projektując interfejsy użytkownika kierujemy się wypracowanymi zasadami użyteczności oraz zasadami dotyczącymi rozsądnego dostępu do danych – tak aby znaleźć kompromis pomiędzy wymaganiami użytkownika, a obciążeniem systemu.

Wraz z wymaganiami użytkownika zbierane są inne wymagania w tym niefunkcjonalne (np. określenie poziomu dostępności aplikacji, czas przechowywania danych w bazie danych).
Wszystkie wymagania są razem zbierane do finalnego dokumentu Specyfikacji Wymagań (SRS - Software Requirements Specification).

Jego szablon zawiera m.in.:

  • Wprowadzenie
    • Cel dokumentu
    • konwencja dokumentu
    • dla kogo jest dokumentu
    • zakres projektu
    • odwołania do innych dokumentów
    • Ogólny opis projektu
  • Perspektywa produktu
    • cechy produktu
    • klasy użytkowników i ich charaktetrystyka
    • środowisko operacyjne w jakim będzie funkcjonował produkt
    • wymogi względem koncepcji i implementacji
    • wymagania względem dokumentacji użytkownika
    • założenia i zależności
  • Funkcjonalności systemu
    • Szczegółowy opis każdej funkcjonalności systemu (m.in. wykorzystanie przypadków użycia)
    • Wymagania względem interfejsów
    • interfejs użytkownika
    • Wymagania Interfejsu użytkownika
    • Wymagania niefunkcjonalne
    • Wymagania wydajnościowe
  • Inne wymagania

 

RODO

Wyrażam zgodę, aby 3e sp. jawna zbierała, katalogowała, analizowała i podejmowała automatyczne decyzje o adresach internetowych połaczonych z urządzeniem, którego używam a także informacji o samym urządzeniu, w tym jego typie, wersji zainstalowanego oprogramowania w celu obserwacji moich aktywności w internecie (stworzenia profilu użytkownika). Automatyczne podejmowanie decyzji nie dotyczy danych wrażliwych. Zgoda pozostaje w mocy tak długo, jak długo istotne pozostają dane, dla których została wyrażona, lub do czasu, gdy któraś ze Stron zgodę wycofa. Cofnięcie zgody będzie skutkować usunięciem danych.