Specyfikację techniczną powinniśmy rozpatrywać pod kątem dokumentu techniczno-biznesowego.
W kwestii informatycznej, treści muszą być sformułowane precyzyjnie. Dzięki temu będą fundamentem do dalszej pracy programistycznej.
Biznesowo, specyfikacja będzie pomocna w oszacowaniu kosztów. Stanie się
również podstawą do konfrontacji wizji klienta w kontekście funkcjonalności tworzonego systemu.
Z doświadczenia, przed podjęciem się pracy nad specyfikacją, rekomenduję zrobić research branży, której dotyczy system. Wizualizacji treści pomaga naszkicowanie mapy myśli. Wpisuje się to w kanon dobrych praktyk, które gwarantują sukces podczas rozmów z klientem.
Kontrowersje dotyczące specyfikacji dotyczą podziału założeń na potrzeby analizy. Możemy rozpatrywać system pod kątem funkcjonalności. Wyróżniamy poszczególne funkcjonalności, a następnie opisujemy, jak realizują się w każdym z dostępnych profili. Drugą opcją jest wyróżnienie użytkowników i opisanie dostępnych opcji. Nie możemy jednoznacznie określić, który sposób analizy powinniśmy przyjąć. Należy go dobrać indywidualnie do projektu, w zależności od stopnia jego złożoności.
Żeby jednak ułatwić pracę na specyfikacją, proponuję przyjąć pięć głównych punktów takiego dokumentu i zadbać o staranne ich rozwinięcie.
Wspomniane punkty to:
- Informacje ogólne
- Specyfikacja techniczna i konfiguracja
- Założenia pozafunkcjonalne
- Założenia funkcjonalne
- Scenariusze funkcjonalności
W “Informacjach ogólnych” dobrze jest nakreślić zarys branży oraz zawrzeć kluczowe założenia systemu.
W punkcie drugim, należy wyróżnić wykorzystane technologie, szczegółowe informacje o wdrażaniu oraz utrzymaniu serwisu.
“Założenia pozafunkcjonalne” powinny określać wersje językowe i kwestie z nimi związane (przykładowo miejsce, z którego będzie możliwa edycja wersji).
W “Założeniach funkcjonalnych” zaczyna się analiza właściwa. Proponuję zacząć od określenia typów danych obsługiwanych przez system oraz określenia jego struktury. Kolejne informacje będą zależne od formy analizy, którą zdecydowaliśmy się przyjąć. Należy pamiętać, żeby sporządzać specyfikację z dbałością o szczegóły. Każdy niesprecyzowany element pozostawia pole do domniemywać, a tego staramy się unikać.
Punkt “Scenariusze funkcjonalności” służy podsumowaniu i opisaniu use casów, czyli przypadków użycia systemu. Pomocne mogą być diagramy oraz schematy, które ułatwią zrozumienie obsługi systemu osobie spoza branży informatycznej. Należy również wystrzegać się słownictwa specjalistycznego.
Podsumowując, podążanie według opisanego scenariusza pracy nad specyfikacją techniczną powinno zminimalizować ryzyko niepowodzenia. Oprócz strony teoretycznej, warto jest wziąć pod uwagę formatowanie, które nada tekstu przejrzystości i poprawi jego czytelność.
