Jak napisać dobrą specyfikację projektu informatycznego?

Stworzenie dobrej specyfikacji projektu informatycznego znacząco zwiększa szansę na uzyskanie produktu, który będzie zgodny z potrzebami. Wiele osób ma jednak sporo trudności, aby stworzyć specyfikację, która będzie zrozumiała i klarowna dla zespołu IT zaangażowanego w temat. Jak zatem napisać dobrą specyfikację projektu informatycznego?

Specyfikacja projektu informatycznego – co to jest?

Specyfikacja projektu programistycznego to bardzo ważny element dokumentacji projektowej. Opisane są w niej podstawowe założenia tj. cele projektu oraz cechy mającego powstać oprogramowania. Jest to dokument, za pośrednictwem którego wykonawca zapoznaje się z oczekiwaniami klienta. Rangę specyfikacji potrzeb podnosi fakt, że zwykle klient spodziewa się, że po jej przeanalizowaniu dostawca przedstawi choćby przybliżoną wycenę projektu. To swoista koncepcja i zaczątek przyszłego produktu, którym może być dowolna aplikacja, system, strona internetowa itp. W specyfikacji powinny być zawarte kluczowe założenia projektu IT, umożliwiające stworzenie oczekiwanego rozwiązania. Dokument nie powinien zawierać luk, zostawiając możliwie mało miejsca na interpretację analityka czy programisty. Warto podkreślić, że chociaż specyfikacja przypomina oficjalną instrukcję stworzoną dla wykonawcy, to w pierwszej kolejności nie powinna opisywać przyszłego rozwiązania, a przede wszystkim potrzeby i cel, na jakich klientowi zależy.

Przede wszystkim potrzeba, niekoniecznie rozwiązanie

Wiele osób zabierających się za pisanie specyfikacji funkcjonalnej ma już jakiś pomysł na docelowe rozwiązanie. Jest dość naturalne, że wyobrażenia takie istotnie wpływają na finalny dokument. Jednak nierzadko zlecający stara się opisać w dokumentacji produkt, który chce otrzymać, gubiąc przy tym podstawę dokumentu, czyli potrzebę, na którą system ma odpowiadać. Jest to potencjalne źródło problemów. Może się bowiem okazać, że wytworzony produkt jest zgodny z opisem, ale niestety nie zaspokaja potrzeby, z myślą o której powstawał. Dlatego warto podkreślić, że jakkolwiek specyfikacja może obejmować konkretne propozycje rozwiązania, nie powinna nigdy pomijać podstawowej potrzeby. Jest dość prawdopodobne, że doświadczony dostawca usług programistycznych sam przygotuje bardzo dobrą, a czasami nawet lepszą koncepcję rozwiązania. Wszak można oczekiwać, że firma zajmująca się realizacją systemów informatycznych ma nie tylko szereg doświadczeń z wcześniejszych projektów, lecz również dysponuje szeroką wiedzą w zakresie dostępnych rozwiązań technicznych, o których klient może nie mieć pojęcia. Rzecz jasna dostawca taki powinien także wydobyć źródłową potrzebę, nierzadko dobrze ukrytą w opisie wymyślonego przez klienta rozwiązania.

Język

Specyfikacja projektu IT powinna zawierać wymagania, które określają funkcjonalność zamawianego produktu. Warto pamiętać, że będąc klientem możemy używać nazewnictwa i terminologii branżowej niezrozumiałych dla wykonawcy. Dlatego też bardzo istotne jest wyjaśnienie nieoczywistych, a czasem wręcz wprowadzających laików w błąd terminów.

Jednocześnie warto pamiętać, że jeśli nie mamy kompetencji programistycznych, lepiej nie próbować posługiwania się językiem technicznym. Nasza niepełna znajomość tematów może prowadzić do sporych nieporozumień. Najlepiej posługiwać się językiem naturalnym, pamiętając o wyzbyciu się branżowego slangu i wyjaśniając co istotniejsze sformułowania i zwroty. W specyfikacji projektowej warto zawrzeć słowniczek pojęć branżowych z działalności klienta. Pozwoli to uniknąć późniejszych nieporozumień. Przydaje się też podstawowy słowniczek pojęć technicznych tak, aby czytelnik nietechniczny mógł zapoznać się z uproszczonymi definicjami. Często istnieje też konieczność stworzenia kilku pojęć na potrzeby systemu, które nie zostały jeszcze nazwane w działalności klienta, a których nazwanie jest konieczne do zaprojektowania aplikacji. W takim przypadku najlepiej, żeby obie strony przedyskutowały nazewnictwo. Z doświadczenia wiemy, że takie nazwy z systemu bardzo szybko przenikają do codziennego języka w firmie, więc dobrze poświęcić chwilę na ich odpowiednie dobranie i jednoznaczność. Tutaj jest też kolejne ryzyko. Przy tworzeniu systemów często trzeba zmienić obecną nomenklaturę używaną w firmie klienta. Może być tak, że np. dwa działy w firmie używają tej samej nazwy na określenie zupełnie różne rzeczy. Wtedy najlepiej rozdzielić te nazwy i zamienić je na odpowiednie synonimy. Posłużmy się przykładem. Dział analizy może używać pojęcia „raport” na określenie raportu dla zarządu np. wykresów, raportu zysku kwartalnego itp. W systemie umieszczamy, więc moduł raportów. W dziale operacyjnym też cały czas mówi się o raportach, ale tam chodzi o coś trochę innego. Raporty są dla nich są ankietami wykonywanymi codziennie przez pracowników ze stanu liczby osób i dostępnego sprzętu w danym mieście. Dział operacyjny też chce mieć swój modułów raportów. Najlepiej porozmawiać z przedstawicielami obu działów i nakłonić ich do zmiany nazewnictwa - w jednym systemie nie będzie miejsca na taki stopień wieloznaczności. Dział analizy może używać modułu raportowego, a dla działu operacyjnego najlepiej stworzyć moduł ankiet i posługiwać się w systemie pojęciem ankiety, a nie raportu dla pracy wykonywanej przez dział operacyjny.

Spójna wizja projektowa

Czasem specyfikacja systemu jest współtworzona przez wiele osób, często o różnych oczekiwaniach. Często zdarza się, że specyfikacje realizowane przez zespoły wieloosobowe są zwyczajną zbitką „list życzeń” różnych osób, przez co pewne wymagania się duplikują lub co gorsza, są ze sobą wzajemnie sprzeczne. Dlatego niezmiernie istotne jest, by końcowa postać dokumentu była oceniona i zredagowana przez jedną osobę, której zadaniem jest określenie jednej spójnej wizji celu, który ma realizować system. Tutaj rola analityka jest bardzo istotna. To on musi zebrać wszystkie wymagania i opracować je. Nie wystarczy tylko spisanie potrzeb wszystkich stron. Analityk musi zaproponować rozwiązanie, które zrealizuje wymagania wszystkich lub prawie wszystkich stron. Czasami też jego rolą jest wytłumaczenie zainteresowanym stroną, że nie wszystkie wymagania warto realizować za pomocą systemu. Klasycznym przykładem jest tutaj próba umieszczenia wyrafinowanej walidacji w systemie. Dużą przewagą aplikacji nad „papierem” i Excelem jest to, że możemy użytkownikom zabronić wprowadzenia niepoprawnych danych. Nie ma tutaj wątpliwości, jeżeli chodzi o takie wymagania jak sprawdzanie poprawności daty, liczb itp. Są to podstawowe wymagania, które bez problemu można zaimplementować w systemie. Ostrożniej należy podchodzić do wymagań typu: maksymalna liczba produktów w paczce, czy minimalny czas dostawy. Szczególnie, jeżeli nie funkcjonują one teraz w naszej firmie. Może się okazać, że dla niektórych odbiorców jednak zgadzamy się na przekroczenie maksymalnej liczby produktów albo, ze dla tych, którzy mieszkają w naszym mieście nasi pracownicy regularnie dostarczają paczki poniżej minimalnego czasu dostawy.

Rozmiar dokumentu

Jednym z najczęstszych „grzechów” twórców specyfikacji jest zbytnia rozwlekłość treści. Aby specyfikacja była zrozumiała powinna być krótka i skupiać się na głównych problemach/procesach. Oczywiście nadal powinna pokrywać w całości wymagania funkcjonalne, jednakże lepiej jest, gdy nie wchodzi zbytnio w szczegóły. Popularnym podejściem jest np. opisanie wymagań jako przypadków użycia tj. konkretnych scenariuszy interakcji pomiędzy użytkownikiem a systemem. Gwarantujemy, że każdy analityk woli dopytać o brakujące detale niż przedzierać się przez dziesiątki, czy setki stron opisów nieistotnych szczegółów.

Ograniczenia technologiczne w specyfikacji

Poza pewnymi szczególnymi przypadkami specyfikacja potrzeb nie powinna narzucać konkretnych technologi rozwiązania. Pomijając fakt, że jest to opisane wyżej wchodzenie w domenę rozwiązań zamiast trzymania się potrzeb, dodatkowo stwarza to niepotrzebne ograniczenia, często niekorzystne dla klienta. Jeśli nic nie warunkuje wyboru konkretnej technologii, lepiej będzie zostawić tę decyzję doświadczonemu dostawcy, który uwzględni nie tylko specyfikę systemu, lecz również bieżące trendy na rynku IT, które mogą wpływać np. na możliwość rozwoju oprogramowania za kilka lat. Z drugiej strony jednak, jeśli ograniczenia technologiczne są dobrze uzasadnione, należy je koniecznie przedstawić, nie pomijając przyczyn ich wystąpienia.

Cel i kontekst biznesowy projektu

Poza określeniem problemu, który ma rozwiązać system informatyczny, warto w specyfikacji ująć także aspekt biznesowy. Wielu klientów zapomina, jak ważny jest szeroko pojęty kontekst: kto będzie systemu używał, w jakich okolicznościach, jakie korzyści system ma przynieść, itp. Często właśnie pytanie o kontekst jest pierwszym, jakie zadajemy naszym klientom. Odpowiedź na nie zwykle wyjaśnia wszelkie niejasności specyfikacji.

Ograniczenia systemu

Przy tworzeniu specyfikacji aplikacji zazwyczaj bardzo dużo mówi się o tym, czego nie będzie w aplikacji. Na spotkaniach analitycznych dyskutuje się różne pomysły, które potem okazują się niemożliwe do wdrożenia, zbędne lub sprzeczne z ostateczną wizją projektową. Odchodzi się od wielu spostrzeżeń, które sprawiłyby, że nie zmieścilibyśmy się w czasie, czy budżecie. Potem powstaje dokument analityczny. Jego czas życia to kilka miesięcy do kilku lat. Z czasem zaciera się pamięć o tym, czego miało nie być i dlaczego niektóre funkcjonalności zostały porzucone. Pomysły wracają i nierzadko ciężko ze specyfikacji wyczytać, czy zamysł twórców był taki, żeby danej funkcjonalności nie tworzyć, czy mamy do czynienia z zaniedbaniem albo po prostu niedowiedzeń. Dlatego warto spisywać takie ustalenia. Specyfikacja przy opisie konkretnych funkcjonalności może zawierać wzmianki o tym, czego ma nie być i jak zaadresować te potrzeby np. że zostało ustalone, że w interfejsie nie będzie przycisku „Drukuj”, a użytkownik może i tak wydrukować stronę przez funkcję drukowania przeglądarki. W tym przykładzie mamy określone, czego nie ma i podane jak użytkownik może rozwiązać swój problem i obejść ograniczenie aplikacji.

Kompletność wymagań

W pracy analityka jedną z ważniejszych rzeczy jest dotarcie i zebranie wszystkich aspektów wymagań klienta. Wymaga to współpracy obu stron. Wyzwaniem jest stworzenie kompletnej specyfikacji wymagań. Kompletnej w tym sensie, że gotowy system będzie aplikacją, która pozwoli klientowi przenieść całość swojej pracy do systemu. Problemem może być pominięcie części działalności, pracowników, przypadków, produktów, odmian itp. Posłużmy się znowu przykładem. Firma mieści się w jednym biurze i zatrudnia pracowników biurowych. Naturalnym jest, że na pytanie analityka o to, czy w firmie pracownicy pracują w systemie zmianowym odpowie „Nie, u nas pracownicy przychodzą do biura od poniedziałku do piątku od dziewiątej do siedemnastej”. Dopiero potem okazało się, że są jeszcze pracownicy ochrony, którzy pracują w systemie zmianowym. Doświadczony analityk będzie zadawał więcej pytań dziedzinowych, które wgłębiają się w specyfikę pracy klienta i które pomogą wyciągnąć na wierzch przypadki szczególne, ale potrzebna jest tutaj współpraca obu stron. Dobre zamodelowanie obszaru firmy i zadań, które mają być przeniesione do systemu może być długi i złożonym procesem.

Podsumowanie

Całość powyższego wywodu można by streścić kilkoma słowami: specyfikacje piszmy treściwe, rzeczowe, uwzględniające wszystkie ważne informacje. Zdajemy sobie jednak sprawę, że nie jest to łatwe zadanie. Dlatego jeśli zachodzi taka potrzeba, sami przeprowadzamy analizę potrzeb i przygotowujemy specyfikację dla naszych klientów. Innych błędów możesz uniknąć czytają o tym dlaczego opóźniają się projekty informatyczne.