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

 

Zamknij ten komunikat

Nasze strony wykorzystują pliki cookies.

Na naszych stronach używamy informacji zapisanych za pomocą cookies m.in. w celach reklamowych i statystycznych. Mogą też stosować je współpracujące z nami podmioty, takie jak firmy badawcze oraz dostawcy aplikacji multimedialnych. W każdej przeglądarce internetowej można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.