Czy tego chcemy, czy nie – każdy z nas jest inżynierem wymagań. W sferze prywatnej i zawodowej wymagania oraz ich konsekwencje towarzyszą nam praktycznie przez cały czas. Kiedy zamawiamy coś w restauracji – tworzymy wymagania, które zazwyczaj są realizowane na podstawie standardowej procedury i dokumentacji, np. wybór pozycji z menu, ustne zamówienie u kelnera. Z kolei gdy nasz partner prosi nas o pomoc, np. przy zakupach, stajemy się odbiorcami takich wymagań.
Powyższe czynności wykonujemy w zasadzie automatycznie, bez większego zastanowienia, i jest to zupełnie naturalne. Wymienione sytuacje są nam dobrze znane i doskonale wiemy, jak intuicyjnie budować ramy do realizacji celu w określonych realiach.
W pracy staje się to już bardziej widoczne i klarowne. Wymagania, które otrzymujemy, to, w dużym uproszczeniu, zadania i cele, które stawia nam przełożony. Oczywiście, bardzo rzadko operujemy w tak ograniczonym środowisku, więc złożoność zazwyczaj jest zdecydowanie większa – dochodzą współpracownicy, silosy organizacyjne w postaci różnych działów oraz inne zależności.
Nie trzeba być analitykiem, aby musieć radzić sobie z wymaganiami. Wręcz przeciwnie, każdy, kto pracuje w firmie o rozbudowanej strukturze i projektowym trybie działania, powinien znać chociaż podstawowe zasady inżynierii wymagań.
W tym wpisie chciałbym się skupić na jednym z aspektów tego obszaru – źródłach wymagań – oraz na powodach, dla których ich skrupulatna identyfikacja i analiza są tak istotne. Szczególnie w kontekście ryzyk pojawiających się wtedy, gdy pewne wymagania pozostają niezidentyfikowane.
Źródła wymagań
Pierwszym źródłem, które przychodzi na myśl, są ludzie – przełożeni, współpracownicy. To oni stanowią pierwszy punkt kontaktu w pracy i najczęściej od osób osadzonych w konkretnym kontekście biznesowym otrzymujemy cele i zadania.
W przypadku codziennej pracy, procesów powtarzalnych i dobrze zdefiniowanych, jest to zupełnie wystarczające. Sytuacja komplikuje się jednak w projektach związanych z wdrażaniem lub rozbudową złożonych systemów. W takich przypadkach pojawiają się źródła wymagań, które nie są przekazywane wprost, a momentami wręcz pozostają „ukryte”.
Kategorie wymagań
Według IREB możemy wyróżnić trzy główne kategorie źródeł wymagań:
- Interesariusze: osoby lub organizacje, które mają wpływ na wymagania systemu lub na które ten system ma wpływ. [1]
- Dokumenty: wewnętrzne regulacje, regulaminy, opisy procesów, dokumenty prawne lub regulacyjne (np. ustawy, rozporządzenia). [2]
- Systemy: takie z którymi tworzone rozwiązanie będzie wchodzić w interakcję oraz takie, z których będzie czerpać inspirację. [2]
Każda z powyższych kategorii jest istotna z punktu widzenia projektu jako całości. Intuicyjnie zazwyczaj na pierwszym miejscu stawiani są główni interesariusze, sponsorzy projektu, gdyż realnie to oni stoją na czele, reprezentując cel i potrzeby biznesowe. Wyznaczają (pośrednio, ale czasami także bezpośrednio) kierunek i tempo rozwoju danego projektu. Finalnie to im najbardziej zależy na dostarczeniu gotowego produktu.
Dokumenty i systemy to takie źródła, które mogą wpływać na kształt przedsięwzięcia na różnych jego etapach. Wyznaczają ramy wdrożeniowe (np. ograniczenia techniczne i technologiczne) we wczesnym stadium, ale też mają realny wpływ na to, co dzieje się już po zakończeniu projektu.
W praktyce bardzo często zdarzają się sytuacje, w których jedna z podstawowych zasad inżynierii wymagań jest pomijana – „zmieniające się wymagania nie są wyjątkiem, a regułą”. [2] Kontekst, w którym operuje system, nie jest nieruchomym monolitem. Procesy, regulacje, technologia i priorytety nieustannie ewoluują, wywierając presję na produkt. Dlatego tak ważne jest monitorowanie otoczenia systemu oraz reagowanie na zmiany wpływające na jego działanie.
W dalszej części przytoczę dwa przykłady z mojego doświadczenia zawodowego, pokazując, jaki wpływ mogą mieć źródła wymagań oraz same wymagania, które pozostają nieodkryte lub są odkryte zbyt późno.
Modele danych w aplikacji do ewaluacji klientów bankowości detalicznej
Wyobraźmy sobie system projektowany i wdrażany przez kilka lat. Rozwiązanie wymaga wielu integracji z aplikacjami wewnętrznymi, a jednocześnie współpracuje z zewnętrznym systemem SaaS.
Głównym celem systemu jest ewaluacja klientów bankowości detalicznej podczas składania wniosków o kredyty i pożyczki, np. konsumenckie. Istotnym elementem tego case study jest fakt, że na początkowym etapie system jest zintegrowany wyłącznie z jednym produktem bankowym. W planach znajdują się jednak kolejne integracje, wskroś regionów oraz innych produktów bankowych.
Workflow takiego produktu odbywa się przy użyciu prostego API, które wysyła dane do ewaluacji i w czasie rzeczywistym zwraca rekomendację. Jest to podstawowy i powszechny mechanizm, który możemy zaobserwować w wielu instytucjach finansowych.
W dużym uproszczeniu przepływ danych wygląda następująco (Ryc. 1):
Produkt bankowy jako system źródłowy wysyła zapytanie do aplikacji wewnętrznej pełniącej rolę warstwy pośredniczącej (middleware). Middleware transformuje dane i przesyła je do zewnętrznego systemu SaaS. Po przetworzeniu wynik wraca tą samą ścieżką do systemu źródłowego.
Budowa dodatkowego modelu
Kluczowym etapem w tym przykładzie jest pierwsza transformacja danych. System zewnętrzny posiada własny model danych, którego nie można było dostosować do wszystkich wymagań. Konieczne było zbudowanie dodatkowego modelu na poziomie „middleware”, tak aby zapytania pochodzące od produktów bankowych mogły zostać poprawnie obsłużone. W rezultacie pomiędzy systemem wewnętrznym banku a aplikacją SaaS mamy drobną, dodatkową warstwę mapującą dane między dwoma modelami.
Na etapie projektowania wewnętrznego modelu danych (inaczej zwanego domenowym) nie zostały rozpoznane inne źródła wymagań poza tymi, które pochodziły od interesariuszy oraz wynikały z integracji systemów.
Intuicja może podpowiadać, że w dużych korporacjach o mocno regulowanym charakterze (np. bankach) powinny istnieć wytyczne dotyczące budowania modeli danych oraz ich przetwarzania. I rzeczywiście – udało się sprostać wszystkim wymaganiom regulacyjnym wynikającym z przepisów prawa (np. RODO).
Nie uwzględniono jednak wymagań odnoszących się bezpośrednio do standardów modelowania danych ustanowionych w organizacji. W tamtym czasie takie wymagania jeszcze nie istniały – były na etapie rozwoju. Jak wspomniałem wcześniej – środowisko i otoczenie, regulacje i wymagania nieustannie ewoluują.
Ciąg dalszy
Po dwóch latach od rozpoczęcia projektu pierwszy produkt bankowy był w pełni zintegrowany i nadszedł czas na wdrażanie kolejnych. Wtedy okazało się, że następny system stawia wymagania, które bezpośrednio odnoszą się do modelu danych wymiany informacji pomiędzy domenami i serwisami.
Na przestrzeni tych dwóch lat w firmie został sfinalizowany i ustanowiony taki standard zwany kanonicznym modelem danych. Ma on na celu zunifikowanie oraz uproszczenie definicji danych, a to ma realną szansę wpłynąć na przyspieszenie integracji oraz zwiększenie zrozumienia semantyki przez poszczególne strony. Jest to istotna zmiana, gdyż dotychczasowy model domenowy został zbudowany w pełni, bazując na zupełnie innych założeniach, często wynikających z doświadczenia projektujących czy też interesariuszy.
Gdyby nie wprowadzenie modelu kanonicznego, każdy nowy produkt wymagałby tworzenia dodatkowych mapowań, powrotu do starych powiązań i ich ponownej analizy.
W efekcie konieczne stało się dostosowanie istniejącego modelu domenowego do tego kanonicznego, w ścisłej kooperacji z centralnym zespołem architektury danych. Przełożyło się to bezpośrednio na konieczność „zainwestowania” dodatkowego wysiłku – czasu pracy analityków, architektów oraz finalnie deweloperów. Bieżąca obserwacja rozwoju tego kanonicznego modelu mogłaby ułatwić i usprawnić zmianę.
Wniosek, jaki z tego płynie, jest prosty – istnieje konieczność ciągłego monitorowania otoczenia systemu i jego kontekstu, analizowania zmian i pozostawania „na czasie” w temacie rozwiązań i standardów obowiązujących w danej firmie. Analiza i inżynieria wymagań nie kończą się na wdrożeniu aplikacji.
Jeżeli zignorujemy powyższe przesłanki, powstanie ryzyko pominięcia istotnych wymagań, ich ewolucji. W skrajnych przypadkach konsekwencją jest nawet ryzyko czasowego wyłączenia systemu produkcyjnego w celu wprowadzenia zmian lub aktualizacji.
System do komunikacji z klientem końcowym
Drugim przykładem jest system wykorzystywany w bankowości detalicznej, mający za zadanie obsługiwać komunikację z klientem w celu przeciwdziałania kradzieży oraz defraudacji środków pieniężnych.
Założenie jest stosunkowo proste: jeżeli określone parametry transakcyjne wzbudzają podejrzenie systemów monitorujących, do klienta wysyłane jest pytanie: „Czy to na pewno Twoja transakcja?”. Następnie system oczekuje odpowiedzi i na jej podstawie podejmuje odpowiednie działania. Na pierwszy rzut oka rozwiązanie wydaje się proste i przejrzyste.
Wysokopoziomowy diagram opisujący ten układ mógłby wyglądać następująco:
Tak zaprojektowany system spełni swoje podstawowe zadanie – odpowiedź od klienta zostanie przekazana, a w rezultacie potencjalne przestępstwo może zostać powstrzymane.
Branże regulowane
W wysoce regulowanych branżach (jaką jest bankowość) to zdecydowanie za mało. Zbudowanie rozwiązania wyłącznie w oparciu o wymagania funkcjonalne zebrane od interesariuszy prowadzi do powstania systemu niekompletnego.
Aplikacja będzie działać, ale organizacja naraża się na ogromne ryzyka związane z niewykryciem wymagań, które dotyczą głównie kategorii „dokumentów”. Szczególnie wtedy, gdy w grę wchodzi bezpośredni kontakt z klientem. Banki są zobowiązane do przestrzegania regulacji zewnętrznych, które pochodzą od instytucji nadzorczych oraz takich, które bezpośrednio wynikają z przepisów prawa. Dodatkowo należy uwzględnić wewnętrzne regulacje i obostrzenia, regulaminy i polityki, standardy, np. logowanie zdarzeń oraz retencję danych.
Kiedy uzupełnimy powyższy diagram (Ryc. 2) o wymagane elementy, stanie się bardziej rozbudowany i może wyglądać tak:
Pojawiają się tutaj elementy regulacji wewnętrznych, np. logowanie zdarzeń systemowych (kto, jak i kiedy wykonał daną operację), oraz zewnętrznych, np. zachowanie historii komunikacji z klientem w systemie CRM.
Dodatkowo należy upewnić się w fazie projektowania, że system spełnia wymagania RODO. Klient ma prawo żądać np. usunięcia swoich danych z systemów bankowych.
Inne wewnętrzne polityki, które będą mieć wpływ na zachowanie aplikacji, to np. regulacje dotyczące dozwolonej częstotliwości wysyłania komunikacji do klienta końcowego (chodzi o nieprzeciążanie użytkownika nadmierną ilością wiadomości w krótkim czasie, gdyż powstaje ryzyko zignorowania istotnych komunikatów przez klienta).
Najważniejszy wniosek z tego przykładu – należy mieć „oczy szeroko otwarte” w fazie odkrywania wymagań, tak aby nie przeoczyć żadnego elementu. Bardzo łatwo jest wpaść w pułapkę pozostania w ograniczonym zbiorze tychże, polegając wyłącznie na wkładzie głównych interesariuszy projektu.
Ważne jest, aby zidentyfikować wszystkie aspekty, które mogą wpływać na funkcjonowanie danego systemu. Poprawnie zebrane i udokumentowane wymagania zgrabnie wyznaczą nam ramy projektowanego rozwiązania oraz wskazują dodatkowe elementy, które powinniśmy w nim uwzględnić.
Data & Analytics
Dzięki naszym usługom analizy i przetwarzania danych będziesz podejmować trafne decyzje, zbudujesz skuteczne strategie i znajdziesz nowe źródła przychodów.
Oferta Data&AnalyticsPodsumowanie
Warto rozejrzeć się za wymaganiami poprzez analizę podobnych projektów (tzw. inspiracja) oraz dokładnie zapoznać się z obowiązującymi standardami i regulacjami (zarówno w firmie, jak i w branży, do której ona należy).
To właśnie te działania ułatwią nam uniknięcie ryzyka pominięcia istotnych wymagań – tych, które na pozór wydają się być „ukrytymi”.
Źródła
[1] A Glossary of Requirements Engineering Terminology, wersja 2.0.0, 2021, cyt. za R. Grębski, J. Kalabińska „Certyfikowany Inżynier Wymagań, na podstawie IREB CPRE, Poziom podstawowy”
[2] R. Grębski, J. Kalabińska „Certyfikowany Inżynier Wymagań, na podstawie IREB CPRE, Poziom podstawowy”
Zostaw komentarz