Jak napisać dobrą specyfikację projektu informatycznego?

Tworzenie klarownej i zrozumiałej dla zespołu IT specyfikacji 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ę, pogrzebaną pod opisem wymyślonego przez klienta rozwiązania.

Jak stworzyć dobrą specyfikację projektu programistycznego?

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.

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.

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.

Podsumowanie

Całość powyższego wywodu można by streścić kilkoma słowami: specyfikacje piszmy krótkie, 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.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *