3.1. Specyfikowanie środowiska systemu

Aby zrozumieć daną organizację biznesową powinniśmy stworzyć jej model. Definicję zakresu biznesu zaczynamy od definicji jego otoczenia. Otoczenie biznesu definiujemy jako zbiór wszystkich jednostek współpracujących z biznesem. Jeśli skupiamy się tylko na wybranym fragmencie biznesu, otoczeniem dla niego stają się też pozostałe działy przedsiębiorstwa. Na rysunku 3.1 widzimy odpowiedni przykład. Organizacją biznesową jest firma prowadząca sieć salonów sprzedaży samochodów. Jej otoczenie stanowią klienci oraz producenci oprogramowania, a dokładniej – systemy informatyczne tych producentów (tu np.: „System firmy Opal Polska”). Otoczenie może komunikować się z firmą na trzy sposoby. Pierwszy sposób jest sposobem tradycyjnym i polega na kontaktach międzyludzkich. Drugi kanał jest kanałem elektronicznym, gdzie firma udostępnia (tu np. klientowi) odpowiedni interfejs użytkownika (GUI). Ostatni kanał jest również kanałem elektronicznym, w którym firma udostępnia zewnętrznym systemom odpowiedni interfejs programistyczny (API).

Rysunek 3.1: Określenie otoczenia biznesu oraz otoczenia systemu informatycznego

Aby opisać współpracę powinniśmy przede wszystkim zidentyfikować i opisać przebieg procesów biznesowych. Żeby zrozumieć pojęcie procesu biznesowego należy zrozumieć samo pojęcie procesu. Jego ogólna definicja określa go jako serię wzajemnie powiązanych zadań, które przekształcają dane wejście w wyjście. Należy zwrócić uwagę na dwa osobne aspekty wynikające z tej definicji. Pierwszy związany jest z samym wyróżnianiem danego procesu oraz jego potencjalnymi interakcjami z innymi procesami. Z tego punktu widzenia proces posiada wejście, wyjście oraz określone granice wyznaczające co konkretnie on obejmuje. Drugi aspekt dotyczy wewnętrznej struktury procesu. W celu jej pokazania trzeba dokładnie określić w jaki sposób tworzące go zadania są ze sobą powiązane i w jaki sposób prowadzi to do uzyskania oczekiwanego wyjścia na podstawie wejścia. Typowo w tym celu poszczególne zadania przedstawiane są w postaci sekwencji uporządkowanej w czasie. Proces biznesowy jest szczególnym rodzajem procesu, który wytwarza wartość dla jego odbiorcy. Innymi słowy wartość wyjścia z procesu jest większa niż jego wejścia z punktu widzenia danego biznesu. Podsumowując, można powiedzieć, że proces biznesowy:

• posiada jasno określone granice, wejście i wyjście,
• składa się z sekwencji uporządkowanych na przestrzeni czasu czynności,
• tworzy wartość dodaną dla określonego odbiorcy (beneficjenta procesu).

Istnieje wiele sposobów modelowania procesów biznesowych, w tym dedykowane do tego notacje. Często stosowanym podejściem jest zastosowanie języka uniwersalnego, jakim jest język UML (Unified Modeling Language). W celu określenia zakresu modelowanych procesów biznesowych możemy wykorzystać diagramy przypadków użycia. Przykładowy taki diagram widzimy na rysunku 3.2. Model ten jest analogiczny do modelu przypadków użycia systemu, który omawiamy w dalszej części podręcznika. Różnica polega na tym, że modelowanie dokonywane jest na poziomie systemu biznesowego.

Rysunek 3.2: Procesy biznesowe modelowanie jako przypadki użycia biznesu

Przypadek użycia biznesu możemy opisać w języku UML, wykorzystując diagram czynności. Przykładowy diagram modelujący proces biznesowy „Zakup części zamiennych on-line” przedstawiony jest na rysunku 3.3. Pokazuje on przebieg obsługi zakupu z punktu widzenia modelowanej organizacji, ilustrując wszystkie konieczne do tego kroki. Przedstawiamy tutaj dosyć prosty proces, gdyż szczegółowe omówienie zasad modelowania biznesu leży poza zakresem niniejszych materiałów.

 

 

Rysunek 3.3: Diagram czynności opisujący proces biznesowy

Alternatywnym sposobem zapisu procesów biznesowych jest wykorzystanie języka BPMN(Business Process Modeling Notation). Jest to specjalizowany język służący głównie definiowaniu przebiegu procesów biznesowych. Na rysunku 3.4 widzimy odpowiedni przykład.

Rysunek 3.4: Przykład procesu biznesowego zapisanego w języku BPMN

3.2. Specyfikowanie wizji systemu

Wizja systemu oprogramowania jest opisem potrzeb zamawiającego, dotyczącego systemu oprogramowania, przedstawiona na stosunkowo wysokim poziomie ogólności. Specyfikacja na poziomie wizji zbiera w jedną całość opis najważniejszych problemów będących rezultatem analizy biznesu (np. problemy dotyczące klientów firmy, określone przez dział marketingu) oraz wynikających z nich cech produktu software’owego. Wizja systemu powinna dawać przede wszystkim odpowiedzi na następujące pytania:

• Po co budujemy nowy system?
• Jakie problemy biznesu zamawiającego ten system rozwiąże?
• Dla kogo jest ten system, jakie są ograniczenia w środowisku odbiorcy systemu?
• Jakie cechy ma mieć ten system, aby pokonać zidentyfikowane problemy?

Odpowiedzi na powyższe pytania szukamy przede wszystkim poprzez analizę modelu biznesu. Dokument wizji będzie efektywny, jeśli scharakteryzuje system z różnych perspektyw, w skróconej, czytelnej i zrozumiałej dla wszystkich uczestników przedsięwzięcia formie. Wizja systemu jest przedmiotem zainteresowania we wczesnych etapach realizacji przedsięwzięcia. Na jej podstawie odkrywane są bardziej szczegółowe wymagania dotyczące zakresu, pozwalające dokładnie wyznaczyć zakres przyszłego systemu.

Wizja systemu, mimo swej ogólności, powinna posiadać konkretną strukturę. Typowo, wizja zawiera stwierdzenie problemu, opis interesariuszy (grup zainteresowanych), podstawowe cechy systemu i ograniczenia ze słownikiem pojęć, a także – niekiedy – motto definiujące zasadniczy cel budowy systemu.

Pierwszym krokiem podczas analizy zasadności budowy systemu oprogramowani powinno być zdefiniowanie problemów, które ewentualny system mógłby rozwiązać. Opis problemu możemy sformułować w postaci stwierdzenia problemu (ang. problem statement). Powinno ono odpowiadać na pytanie „dlaczego potrzebujemy nowego oprogramowania?”. Stwierdzenie problemu ma postać zwięzłego i jednoznacznego opisu, który identyfikuje zagadnienie biznesowe stawiane przed budowanym systemem a także wskazuje ogólną metodę jego rozwiązania oraz potencjalne korzyści płynące z wprowadzenia takiego rozwiązania.

Dla wyrażenia stwierdzenia problemu możemy na przykład skorzystać ze wzorca: "Problem polegający na …., dotyczący ….., którego rezultatem jest …., można rozwiązać budując system …., co spowoduje (korzyści) …." .

Kolejnym elementem wizji systemu powinna być specyfikacja interesariuszy. Interesariuszami są wszystkie te osoby, na których wdrożenie nowego systemu będzie miało bezpośredni lub pośredni wpływ. Możemy wyróżnić kilka typowych grup interesariuszy:

• Użytkownicy sytemu
• Klienci organizacji biznesowej
• Inwestorzy (np. akcjonariusze)
• Zamawiający
• Dział IT

Podobnie jak dla stwierdzenia problemu, dla opisu grup interesariuszy możemy wykorzystać wzorzec, składający się np. z następujących elementów:

• Nazwa interesariusza i typ
• Opis interesariusza
• Zakres obowiązków
• Kryteria zadowolenia
• Zadania w projekcie

Po zidentyfikowaniu problemu i interesariuszy możemy zająć się określaniem cech systemu. Cechy systemu stanowią odpowiedź na potrzeby poszczególnych grup zainteresowanych systemem. Cechy systemu określają dwa rodzaje wymagań: wymagania funkcjonalne i jakościowe.  Cechy są stwierdzeniami na wysokim poziomie abstrakcji i formułujemy je przy pomocy krótkich zdań w języku naturalnym.

Ważne jest, aby formułując cechy systemu korzystać ze słownictwa używanego przez interesariuszy. Definicje poszczególnych pojęć powinniśmy umieścić w słowniku. Słownik na poziomie wizji nie musi być rozbudowany. W słowniku (np. w porządku alfabetycznym) umieszczamy używane w definicji cech systemu pojęcia, które mogą budzić wątpliwości. Poniższy przykład ilustruje wykorzystanie słownika do wyjaśnienia pojęć występujących w opisie cech systemu.

• Cecha F007: System musi umożliwiać zarządzanie modelami samochodów.
• Cecha J023: System powinien przyspieszyć przyjmowanie samochodów na stan o co najmniej 30%.
• Model samochodu – specyfikacja obejmująca nazwę producenta i nazwę modelu (np. „Fiak Tipi” lub „Opek Astal”) oraz wszystkie parametry techniczne serii samochodów.
• Samochód – konkretny egzemplarz danego modelu samochodu, posiadający unikany numer pojazdu oraz określony zestaw dodatkowego wyposażenia.

Warto też zauważyć, że w powyższym przykładzie cechy systemu zostały oznaczone identyfikatorami. Przykładowo, cechy funkcjonalne są oznaczone identyfikatorem z przedrostkiem „F”, a cechy jakościowe – z przedrostkiem „J”.

Podczas specyfikowania wizji systemu należy również wziąć pod uwagę ograniczenia. Ograniczenie oznacza zmniejszenie stopnia swobody, którą mamy podczas tworzenia i dostarczania systemu. Można wyróżnić wiele źródeł ograniczeń: techniczne, ekonomiczne, polityczne, prawne, środowiskowe i inne.

Ostatnim, opcjonalnym lecz często użytecznym elementem wizji systemu jest motto. Motto ma postać jednego czy dwóch zdań, które prosto i efektownie prezentują korzyści płynące z realizacji projektu.

3.3. Techniki pozyskiwania wymagań

Można wyróżnić dwa podstawowe źródła pozyskiwania wymagań: dokumenty oraz ludzie. Zawsze jednak najważniejszym źródłem wymagań są ludzie, gdyż dopiero bezpośrednie rozmowy pozwalają odkryć rzeczywiste potrzeby klienta. Uzyskanie od klienta wiedzy pozwalającej na napisanie poprawnej specyfikacji wymagań nie zawsze jest proste i często wymaga zastosowania odpowiednich technik współpracy z klientem.

Zacznijmy od technik współpracy z dokumentami, które stanowią punkt wyjścia do rozmów z klientem. Wiedzę o przyszłym systemie, można czerpać m.in. z instrukcji stanowiskowych, regulaminów, istniejących podręczników użytkownika systemów odziedziczonych, a także przez analizę specyfikacji procesów biznesowych. Najbardziej podstawową techniką jest technika podkreślania pojęć. Polega na podkreślaniu fraz rzeczownikowych oraz czasownikowych w analizowanym dokumencie. Dla podkreślonych fraz szukamy definicji w tekście lub próbujemy taką definicję sformułować sami. W każdym przypadku, nazwę pojęcia oraz jego definicję uzgadniamy z klientem stosując techniki podane w dalszej części tej sekcji.

Inną technika pracy z dokumentami jest wyróżnianie wymagań. Polega ona na zaznaczaniu fragmentów tekstu, które stanowią kandydatów na wymagania. Po znalezieniu konkretnego fragmentu, zaznaczamy jego treść i dokonujemy klasyfikacji wymagania (funkcjonalne, jakościowe, definicja słownikowa, ograniczenie) zgodnie z klasyfikacją piramidy wymagań. Fragment dodatkowo uzupełniamy o atrybuty – w pierwszej kolejności nadajemy mu identyfikator. Tak zaznaczony fragment przenosimy następnie do repozytorium wymagań.

Szczególnym przypadkiem wyróżniania wymagań jest poszukiwanie opisów interakcji z użytkownikiem w dokumentacji zastanych systemów oprogramowania. Instrukcje użytkownika systemów, które będą zastępowane nowym systemem stanowią cenne źródło informacji. Analiza dokumentacji takich systemów pozwala na ustalenie, która część funkcjonalności poprzedniego systemu jest warta przeniesienia do nowego. Jednocześnie, pozwala ona na zidentyfikowanie tych funkcjonalności, które wymagają usprawnienia lub rozszerzania. Poszukujemy szczególnie scenariuszy mogących stanowić podstawę do sformułowania przyszłych przypadków użycia systemu lub historii użytkownika (patrz następne rozdziały).

Techniki pracy z dokumentami stanowią punkt wyjścia dla zastosowania technik współpracy z ludźmi. Techniki te mają na przede wszystkim na celu ustanowienie efektywnych kanałów komunikacji między klientem a wykonawcą. Muszą one zapewnić porozumienie między ekspertami w dziedzinie problemu, inżynierami oprogramowania, analitykami biznesowymi, analitykami systemowi i przyszłymi użytkownikami.

Najważniejszą i najczęściej stosowaną techniką współpracy z ludźmi jest wywiad. Jest to forma rozmowy między reprezentantem wytwórcy oprogramowania, a osobą zainteresowaną powstaniem systemu informatycznego. Celem przeprowadzenia wywiadów z klientem, podobnie, jak innych technik omawianych w tym rozdziale, jest opisanie pewnego fragmentu rzeczywistości, który ma zostać przedstawiony w specyfikacji wymagań. Rozmowa w formie wywiadu może być mniej lub bardziej sformalizowana czy ukierunkowana.

Wywiad typu sesja pytań i odpowiedzi to najbardziej elementarna forma wywiadu. Obie strony powinny być do niego przygotowane i znać wcześniej tematykę rozmowy. Osoba odpowiedzialna za zbieranie wymagań powinna przygotować listę pytań, które zostaną zadane podczas wywiadu. Od reprezentanta odbiorcy systemu wymagamy zorientowania w kontekście wywiadu. Bardzo istotnym elementem sesji pytań i odpowiedzi jest wyjaśnianie terminologii. Każde pojęcie użyte przez klienta powinno być dokładnie wyjaśnione i opisane w sposób zrozumiały dla wszystkich.

Rozwinięciem wywiadów z użytkownikami jest terminowanie (ang. tutoring). Polega ono na wspólnej pracy analityków z zamawiającymi przez okres niezbędny do zrozumienia ich zadań. Terminowanie jest jedną z najlepszych metod na poznanie sposobu działania danej dziedziny poprzez opis i analizę czynności wykonywanych przez przyszłych użytkowników systemu. Jest to również metoda najmniej kosztowna dla klienta, gdyż nie jest konieczne wydzielanie osobnego czasu na rozmowę.

O ile podczas „tradycyjnego” wywiadu osoby wcielają się w role „pytającego” i „udzielającego odpowiedzi”, to podczas terminowania role te można określić odpowiednio jako „uczeń” i „mistrz”. W przypadku inżynierii wymagań, uczeń jest reprezentantem wytwórcy oprogramowania, a mistrz jest potencjalnym przyszłym użytkownikiem systemu. Uczeń poznaje pracę mistrza poprzez obserwację wykonywanych czynności i zadawanie pytań w trakcie pracy. Pytania powinny być częste i dotyczyć wszelkich szczegółów pracy mistrza. Należy przyjąć zasadę, że każde pytanie jest „na miejscu”. Uczeń pyta: „po co to zrobiłeś?”, „jak często się to dzieje?”, „jak to uzyskać”, „a co jeśli…” itp. Pytania mają źródło w obserwacji pracy mistrza, ale powinny opierać się o wypracowany wcześniej model działania danego stanowiska pracy.

Wywiady z użytkownikami, niezależnie od ich przyjętej formy, są często jedyną metodą zbierania wymagań. Może to prowadzić do problemów, szczególnie w sytuacji, kiedy reprezentanci klienta mają różne zdanie na omawiane tematy. O wiele skuteczniejszą metodą uzgadniania sprzeczności jest praca w grupie. Takie warsztaty wymagań umożliwiają konfrontację wielu punktów widzenia wynikających z różnych kompetencji i poglądów.

Ciekawą technika pracy grupowej jest organizacja sesji JAD (ang. Joint Application Development – wspólne wytwarzanie aplikacji). Sesje takie możemy organizować podczas całego procesu wytwarzania i rozwoju oprogramowania. Tutaj skoncentrujemy się na sesjach dotyczących zbierania i dokumentowania wymagań – na różnych poziomach piramidy wymagań. Są one prowadzone w formie warsztatów, w których uczestniczą reprezentanci klienta (głównie przyszli użytkownicy systemu), oraz reprezentanci wykonawcy – analitycy wymagań. Ogólnie, w wyniku przeprowadzonych warsztatów powinien powstać uzgodniony fragment specyfikacji wymagań. Uczestnicy powinni się przede wszystkim koncentrować na uzgodnieniu wspólnego stanowiska, które znajduje odzwierciedlenie w tekście i modelach wymagań.

Format sesji JAD wymaga podziału zadań między kilka podstawowych ról:

• Sekretarz – osoba nie uczestnicząca w dyskusjach, a jedynie rejestrująca ich przebieg
• Moderator – kieruje  warsztatem – jego przebiegiem i podziałem czasu poświęcanego na konkretne punkty planu dyskusji
• Lider projektu – osoba zarządzająca zespołem rozwijającym system
• Kierownik reprezentujący sponsora – osoba na stanowisku kierowniczym z organizacji sponsora projektu
• „Zwykły” uczestnik – reprezentant zespołu klienta
• Obserwator - członek zespołu rozwijającego system

Główną korzyścią z sesji JAD jest swobodna (jednakże ukierunkowana) wymiana informacji między uczestnikami projektu. Sesje są bardzo dobrą metodą na włączenie użytkowników w formułowanie wymagań, które bezpośrednio będą się przekładać na działanie budowanego systemu. Wadami korzystania z warsztatów wymagań są dość wysokie koszty. Często problemy poruszane na warsztatach dublują tematy poruszane podczas wywiadów. W innych przypadkach materia biznesu jest zbyt skomplikowana, nawet jeśli dyskutuje się ją podczas serii kilku wielodniowych spotkań.

Na koniec omawiania technik współpracy z klientem warto wspomnieć o burzach mózgu. Jest to interesująca technika pracy grupowej, której celem jest wspomaganie procesów twórczych – zwiększenie kreatywności. Podczas takich sesji powstaje bardzo dużo pomysłów stanowiących ślepe uliczki. Jednakże, niektóre pomysły, po odpowiednim przetworzeniu czy też połączeniu z innymi mogą znacznie zwiększyć jakość wytworzonych wymagań. Uwolnienie kreatywności uczestników wspomagane jest poprzez odpowiedni format sesji: w pierwszej fazie każdy uczestnik może zgłaszać dowolne pomysły, zadawać pytania i wymieniać z innymi poglądy dotyczące danego tematu sesji. Na tym etapie istnieje zakaz wygłaszania sądów nt. stwierdzeń uczestników sesji. Druga część burzy mózgów polega na wskazaniu i ocenie przez ekspertów dziedzinowych pomysłów zgłoszonych na początku sesji.