Tym razem dość krótko ale znowu wzorce i dobre praktyki.
Bardzo często spotykam, pewnie nie ja jeden, specyfikacje wymagań zawierające zapisy “oczekiwań użytkowników”. Bardzo często słyszę także, że to przyszły użytkownik oprogramowania powinien być źródłem wymagań. Nic bardziej błędnego.
Co nam powie słownik j.polskiego o wymaganiach?
wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?
Jest to bardzo zgrabna definicja. Zgodnie z logiką jeżeli jakieś pojęcie zastąpimy jego poprawną definicją, zdanie nie powinno zmienić znaczenia. Gdybyśmy więc powiedzieli:
Kupimy wyłącznie oprogramowanie, które spełnia nasze wymagania.
to po takiej podmianie uzyskamy:
Kupimy wyłącznie oprogramowanie, które spełnia nasze warunki, którym musi ono odpowiadać.
Nie jest źle. Tak więc wymagania na oprogramowanie, to lista warunków, którym musi ono odpowiadać by było nam przydatne.
Najczęściej chyba można się spotkać w projektach z tak zwanymi wymaganiami funkcjonalnymi i poza funkcjonalnymi. Coraz częściej można spotkać też specyfikacje tak zwanych przypadków użycia.
Popatrzmy jednak najpierw na strukturę oprogramowania. Standardem architektury oprogramowania stał się wzorzec MVC ([[Model, View, Controller]]), tak go można ogólnie przedstawić:
Zanim zaczniemy spisywać wymagania, warto zrozumieć z czym walczymy. A walczymy z tym, że oprogramowanie to obecnie rozdzielone: wygląd i treść interfejsu użytkownika (View), logika biznesowa (Model), środowisko technologiczne (Controller).
To co nazywamy przypadkiem użycia to interakcja użytkownik (aktor systemu) z systemem (oprogramowanie). Tą metodą opisujemy wyłącznie jeden, raczej relatywnie mało znaczący w projekcie tworzenia nowego oprogramowania, komponent. Jest on, przypadek użycia, jednak bardzo ważny przy wyborze gotowego oprogramowani bo tu definiujemy konkretną wymaganą Usługę Systemu (w gotowym oprogramowaniu jej nie implementujemy, więc zbyt szczegółowy opis tu tylko zaciemnia problem).
Jeżeli tą usługą ma być np. “wystawianie faktur VAT” to czynność ta jest dość dokładnie opisana w przepisach i ryzyko, że nie otrzymamy potrzebnej funkcjonalności jest bliskie zeru. Jeżeli jednak opis wymaganej usługi systemu brzmi tak:
Wymaganie funkcjonalne: stosowanie funkcji wyszukiwawczych ? wyszukiwanie danych spełniających określone parametry, w tym według więcej niż jeden zadanych kryteriów jednocześnie. (cytat z dokumentu Opis Przedmiotu Zamówienia, w skrócie OPZ, jednego z przetargów publicznych)
to konia z rzędem temu, kto mi powie co ten system ma tak na prawdę robić i jak stwierdzić, że zakupiony system to robi (cytowany dokument OPZ jest w całości napisany w tym stylu).
Interfejsy: jeżeli napiszemy jedynie z czym się łączymy np. enigmatyczne: system ma pozwalać na wymianę danych z oprogramowaniem finansowo-księgowym, to tak na prawdę wskazaliśmy tylko, że taki transfer ma miejsce, ale nic ponad to, a tu kluczem są dane przekazywane, o których ani słowa, i może się okazać, że jakaś wymiana danych jest możliwa (w zasadzie prawie zawsze jest) ale nie takich, które są nam potrzebne… czyli tak na prawdę wymaganie nie będzie spełnione i odkryjemy to jednak za późno po po zakupie oprogramowania.
Uogólniając, cała niebieska część powyższego diagramu to środowisko technologiczne, z reguły predefiniowane jako tak zwany framework (szkielet oprogramowania), którego raczej się nie zmienia a używa.
Najciekawsze jest to, że oprogramowanie służy w głównej mierze do przetwarzania danych. Coś dajemy na wejściu i czegoś oczekujemy. Co tu jest istotne? Opis tego co jest przetwarzane ale przede wszystkim reguły tego przetwarzania! Przypadek użycia, poprawnie opisany, to także dane wejściowe i dane wyjściowe, ale gdzieś powinno być napisane “jak”?
Na powyższym diagramie kolorem zielonym oznaczono tak zwany model dziedziny (Model z wzorca MVC). To miejsce, w którym oprogramowanie “przetwarza”. To tu tkwi “sedno wymagań”. Co ciekawe, poprawnie (znowu dobre praktyki) zaprojektowane oprogramowanie całą logikę i przypadki użycia realizuje właśnie w tym komponencie. Reszta to tylko pozbawione logiki biznesowej (tak, tu ich nie powinno być) interfejsy (użytkownika i komunikacyjny).
Więc np. wymaganie “system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów” (także cytat z pewnej specyfikacji systemu CRM) jest pustym stwierdzeniem. Po pierwsze jak te rabaty są naliczane, po drugie czy aby na pewno mechanizm pozwala na “dowolne rabaty”… Jak to opisać? Tu powinny się pojawić np. tablice decyzyjne a nie lakoniczne “dowolne rabaty”.
Na zakończenie uwaga: jeżeli planujemy kupić gotowe oprogramowanie, to ono już (gdzieś tam) istnieje, i specyfikowanie szczegółów opisujących dokładnie elementy pracy z interfejsem użytkownika i enigmatyczne opisy tego jak “system liczy”, jest bezwartościowe. Raczej wywoła listę tak zwanych kastomizacji (zwanych gdzieniegdzie zabójcami projektów :)). Tak jednak właśnie wyglądają najczęściej specyfikacje pisane rękami przyszłych użytkowników: opiszą oni to z czym się stykają i co znają ale w ogóle nie opiszą wnętrza, którego najczęściej po protu nie rozumieją (i nie muszą bo to nie ich rola), wtedy specyfikacje systemów CRM pisane rękami przyszłych użytkowników – np. sprzedawców – zawierają właśnie bezwartościowe zapisy w rodzaju: “system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów” a nie zawierają opisu jak te rabaty wyliczać.
Odpowiadając na tytułowe pytanie: wymagania (funkcjonalne) realizują się w modelu dziedziny systemu, którego nie zawiera większość znanych specyfikacji wymagań… a warunkiem poprawnego wyboru oprogramowania są oczekiwania co do efektów przetwarzania.
Przed lekturą tego artykułu myślałem, że dobrym podejściem podczas analizy jest precyzyjne określenie celów, czyli, posługując się Pana przykładem, “system ma pozwolić na budowanie/obsługę dowolnych rabatów dla stałych klientów”. Fakt – może to rzeczywiście zbyt ogólne stwierdzenie, ale już “system ma umożliwić naliczenie dowolnej wartości rabatu podczas sprzedaży towarów do stałych klientów” już jest bliskie prawdy. Pana wcześniejsze artykuły jasno i wyraźnie nawoływały do unikania identyfikacji szczegółów rozwiązań na poziomie analizy. Tutaj raptem Pan pisze o budowaniu tabel decyzyjnych (które i tak w mojej opinii nie pozwoliłyby na opisanie wszystkich wariantów matematycznych naliczania rabatów w procesie sprzedaży) i opisywaniu atomowych szczegółów.
No i teraz pytanie: jak powinno być?
Czy opisać cel, którym jest umożliwienie obsłużenia w systemie dowolnej konfiguracji rabatów podczas sprzedaży (przy założeniu, że są one tak naprawdę policzalne i skończone, przynajmniej te zdroworozsądkowe).
Czy żmudnie opisywać wszystkie możliwe konfiguracje rabatów (wraz z ich akceptacjami, przedziałami kwotowymi itp, itd.)? Czy udało się Panu kiedyś sporządzić taką tabelę, po lekturze której klient powiedział “super, uwzględnił Pan wszystkie możliwe przypadki :)”?
A może od czegoś zależy dobór ziarna analizy? Jeżeli tak, proszę o wskazanie drogi 🙂
Jak powinno być?
– jeżeli w planie jest zakup gotowego oprogramowania to nie ma sensu zbyt szczegółowe jego opisywanie bo szukamy gotowca a nie projektujemy,
– jeżeli planujemy zlecenie wykonania dedykowanego oprogramowania musimy bardzo dokładnie wyspecyfikować co i jak ma ono robić – tu projektujemy.
I teraz wstępne wymagania powinny być ogólne ale bardzo dokładnie musimy wykonać analizę biznesową: musimy wiedzieć czy ów system rabatowy buduje naszą przewagę na rynku czy nie. Jeżeli nie, to dostosowujemy się do tego co oferuje znalezione gotowe oprogramowanie. Jeżeli tak, specyfikujemy dokładnie nasze firmowe know-how i zamawiamy w tym obszarze dedykowane oprogramowanie.
Faktem jest, że pominąłem w tym artykule ważny wcześniejszy etap: analiza motywacji biznesowej. Do póki nie wiem czy system rabatów jest dla nas ważny, nie ma dobrej odpowiedzi na pytanie czy i jak szczegółowo go opisać. Tu chyba tkwi to “ziarno analizy”.
Innymi słowy celem biznesowym może być “nagradzanie klientów jakimiś rabatami” i nie ma problemu, albo celem może być “nasz konkretny super system rabatowy” i to są dwa różne projekty.
Podałem ten przykład, bo firmy często traktują rabaty bardzo “osobiście” a bardzo ogólnie je opisują w wymaganiach…
Dziękuję za odpowiedź.
Rzadko bywa chyba jednak tak, żeby klient chciał kupić COTSa. Jest to znikomy odsetek projektów (poza tym co to za projekt…:)). W dalszym ciągu nie zgodzę się z Pana stwierdzeniem, że w przypadku zakupu dedykowanego softu, należy bardzo szczegółowo wyspecyfikować sposób realizacji wymagań w systemie. Pamiętam podawane przez Pana przykłady lekarza, którego chory nie pyta w jaki sposób będzie operował skalpelem albo producenta samochodów, którego klient nie będzie pytał w jaki sposób będzie montowany drążek skrzyni biegów (nawet przy drogich produkcjach na zamówienie). Zarówno lekarz jak i producent samochodu mają zapewnić swoimi produktami realizację założonych celów.
Odnośnie analizy motywacji biznesowej, to widzę tu trudność w określeniu priorytetów (chyba, że priorytet rabatów jest ustalany przez jednostkę nie korzystającą z rabatów – w każdym innym przypadku to czysto umowna ocena). Jeżeli nawet udałoby się to zrobić, to chce Pan powiedzieć, że mniej ważne elementy powinny zostać opisane ogólnie, a te ważniejsze bardzo szczegółowo? Nie jestem przekonany, czy to słuszne podejście.
A propos Pana przykładu, czy widział Pan/sporządził Pan kiedyś kompletny opis polityki rabatowej dla jakiejkolwiek firmy?
Co do COTS, to jest to ponad 80% wszystkich sprzedanych systemów IT na rynku :).
Oprogramowanie dedykowane. Nie zapominajmy o dwóch odrębnych rzeczach: projektowanie “konstrukcji” to praca developera ale logika biznesowa to biznes. Nie ma sensu by zamawiający “rozwiązywał” problemy techniczne i tu faktycznie wystarczy napisać, że oprogramowanie ma być szybkie, wygodne, dostępne przez sieć, i cała masa elementów leżących w gestii developera. Ale, np. “wzór na wyliczenie podatku VAT” to coś za co developer nie może odpowiadać (analityk biznesowy tak), to musi dostać programista “na tacy” na tyle szczegółowo i jednoznacznie by nie było możliwości pomyłki i by było możliwe do testowania.
Oprogramowanie, podobnie jak np. budowlanka, to dziedzina techniczna. Zamawiając dom nie ma sensu bym dyktował architektowi szczegóły konstrukcji stropu i ścian, wystarczy że podam planowane obciążenie stropu, ale ma głęboki sens podanie koloru ścian w postaci numeru farby z katalogu, bo to gwarantuje mi, że dostane “to czego chcę”. Jak zamieszkam, konstrukcja ścian być może będzie dla mnie tajemnicą do końca życia ale na kolory będę się gapił codziennie.
Dajmy na to, z analizy biznesowej dla systemu CRM wynika, że rejestr klientów i notatki ze spotkań są ważne ale ich postać nie jest krytyczna. Tu spokojnie wystarczy ogólnie opisane wymaganie w rodzaju: “możliwość notowania treści spotkań z klientem wraz z terminem początku i końca oraz miejscem spotkania”. Jeżeli jednak firma zdobywa swoich nowych klientów, odbiera ich konkurentom, bardzo atrakcyjnym systemem rabatów z tytułu promocji i programów lojalnościowych, to musi to opisać jednoznacznie bo developer nie ma prawa nic tu mieszać ani tworzyć po swojemu, to jest kluczowy wymóg biznesowy.
Na ostatnie pytanie odpowiem tak: robię to właśnie już trzeci raz.
Z własnego doświadczenia wiem, że im oprogramowanie jest bardziej dedykowane, tym zamawiający częściej są skłonni podrzucać przypadki, które niespodziewanie “przynosi życie”. A większość z nich naprawdę można przewidzieć. Przy kastomizacji komercyjnego oprogramowania apetyt na modelowanie “po fakcie” najczęściej ukrócają koszty tej kastomizacji. W przypadku dedykowanej twórczości brak doprecyzowanego modelu, tablic decyzyjnych, czy przypadków użycia prowadzi niejednokrotnie do konfliktów i ostudzenia weny twórczej mogących coś konkurencyjnego na rynku zaproponować. W niestandardowym produkcie wystarczy pracy nad tym, co niestandardowe. Szkoda marnować czasu na pomyłki przy realizacji standardowych procesów. To powinno być dobrze opisane przez dobrze znających swoją pracę “rzemieślników”, by nie marnować sił “wirtuozów”, którzy w tym czasie może odkryliby coś wyjątkowego.
Oczywiście zaliczam się do “rzemieślników” 🙂
Ogólnie nie nie ma prostej odpowiedzi na pytanie, kiedy istotne są szczegóły i które. To zawsze zależy od tego w jakim celu oprogramowanie jest kupowane oraz od tego do czego zamawiającemu ono posłuży. Jeżeli kupowany jest system ERP/CRM itp. “taki jaki ma każdy inny” bo bez tego trudno funkcjonować, to wymagania opisujemy poprzez definiowane celu jego zakupu.
Jeżeli jednak nasza specyfika polega na realizowaniu specyficznych zadań w specyficznych sposób i za pomocą specyficznych treści, to ta specyfika musi być dogłębnie zrozumienia i wręcz algorytmicznie udokumentowana.
To dlatego tak ważna jest analiza biznesowa poprzedzająca specyfikowanie wymagań…i nie raz dokumentowanie wręcz algorytmów dokonywanych przekształceń danych.
Pozostanę z tą refleksją…
Dziękuję za odpowiedzi.
Między innymi pod wpływem Pana pytań powstał kolejny artykuł:
http://it-consulting.pl/autoinstalator/wordpress/2013/02/07/analityk-to-nie-dyktafon/