Jako doświadczona firma zajmująca się tworzeniem oprogramowania, wiemy, że pisanie dobrej specyfikacji wymagań systemowych ma kluczowe znaczenie dla sukcesu każdego projektu oprogramowania. Pracując z dziesiątkami firm z różnych branż, zgromadziliśmy wiedzę i stworzyliśmy wizję tego, jak powinna wyglądać idealna specyfikacja.
Co to jest właściwie specyfikacja techniczna?
Specyfikacja to dokument, który określa cele, taktykę i plan wykonania projektu. Powinien zawierać ograniczenia, takie jak budżet, terminy lub ograniczenia techniczne. Bardziej rozwinięta wersja może również zawierać szczegóły techniczne, takie jak zaangażowane osoby, na przykład interesariusze lub punkty kontaktowe. Specyfikacja powinna zawierać także opis logiki biznesowej oraz spis funkcjonalności systemu. Dodatkowym atutem jest załączenie projektów graficznych w przypadku projektów z interfejsem graficznym (np. aplikacje mobilne, aplikacje webowe)
Po co tworzyć specyfikację?
Taki dokument zazwyczaj służy do wyceny czasowej prac nad projektem, w wielu przypadkach jest wręcz niezbędny. Ponadto stanowi on często załącznik do umowy, mówiący o tym w jakim zakresie mają się odbywać prace. Prościej mówiąc, klient powinien oczekiwać tylko tego co zapisane jest w specyfikacji, dlatego to jemu także powinno zależeć na budowaniu rzetelnego dokumentu opisującego projekt, a nie tylko zespołowi developerskiemu. Oczywiście sytuacja zmienia się w przypadku projektu na zasadzie T&M (time and materials) gdzie to na cotygodniowych sprintach ustalane są zadania na najbliższy czas. Jednakowo, budowa specyfikacji w takim wypadku powinna odbywać się równocześnie z postępami projektu. A ponadto:
- - zwiększa dokładność szacunków czasowo/kosztowych
- - pozwala zawczasu dostrzec niewyjaśnione kwestie zachowania systemu
- - zapobiega przyszłym problemom wynikającym z niedoprecyzowania informacji
- - określa role członków zespołu w projekcie
Jak powinna wyglądać specyfikacja - na przykładzie aplikacji mobilnej
Specyfikacja na początku powinna posiadać strzeszczenie, czyli niedługi fragment (nie więcej niż 1/2 strony A4) opisujący projekt "z lotu ptaka" nie wdający się w szczegóły techniczne ani funkcjonalne, ale bardziej opisujący jakie funkcjonalności spełnia aplikacja i co użytkownik może w niej zrobić.
Dokument powinien zawierać opis ekranów (wraz z załączonymi grafikami lub makietami). Każdy z ekranów powinien posiadać opis funkcjonalny, czyli opis tego co w danej lokalizacji użytkownik może zrobić (np. kliknąć) oraz wyjaśnienie procesu w jaki sposób informacje pojawiają się na ekranie.
Na przykład w aplikacji do zamawiania taksówki ekran z mapą powinien mieć opis zawierający objaśnienie dotyczące tego jak użytkownik może zamówić przejazd ale także co bardzo istotne w jaki sposób dane dotyczące możliwych przejazdów pojawiają się na ekranie (np. za pomocą zapytania do API). Nalezy pamiętać także o przejściach w inne miejsce aplikacji które może dokonać użytkownik (np. przejście do ekranu ustawień) lub akcjach które mogą go spotkać, np. wyskakujące powiadomienie.
Jeżeli projekt dotyczy zarówno aplikacji jak i api (backend) z którego ma ona korzystać, warto w tym momencie zastanowić się czy nie warto rozdzielić specyfikacji na dwa dokumenty lub działy, osobno opisujące aplikację oraz api. Wszystko po to aby nie utonąć w szczegółach technicznych, gdyż mieszanie opisów ekranów ze skomplikowaną logiką wyliczania taryf przejazdowych może wręcz utrudnić czytanie.
Ponadto specyfikacja powinna zawierać wymagania techniczne, czyli opis obsługiwanych wersji urządzeń i systemów, zależności pomiędzy systemami zewnętrznymi (jeżeli takowe istnieją) oraz wykorzystanie zewnętrznych serwisów do działania (np. Google Maps)
Jak zabrać się do pisania, czyli od czego zacząć?
Zaczynając budowanie specyfikacji należy przygotować się na kilka iteracji. Nie musimy wymagać od siebie dokładnego opisania projektu już za pierwszym razem, gdyż na ten moment sami dopiero zaczynamy go materializować na kartce. Najlepszym sposobem jest zaczynanie od "ogółu do szczegółu". Zaczynamy najpierw opisywać po kolei główne punkty systemu np. w jednym zdaniu. Dobrym sposobem przy większych projektach jest podzielenie sobie projektu na moduły, np. w przypadku CRM moduł zamówień, wysyłki, call center i po kolei opisywać każdy z nich jak oddzielny projekt.
W momencie gdy mamy już gotowy szkic wysokopoziomowy możemy zacząć opisywać szczegóły funkcjonalności oraz zależności pomiędzy poszczególnymi modułami. To najczęściej w tym kroku pojawia się najwięcej wcześniej nie dostrzeżonych kwestii, które właśnie będą doprecyzowane.
Nie bójmy się kilkukrotnie iterować po dokumencie dokonująć jego przebudowy, na ten moment taka operacja jest dla nas "darmowa" i o wiele łatwiej jest modelować projekt operując tekstem niż zmieniać gotowy kod którego stworzenie nierzadko zajęło kilka tygodni.
Kiedy uznamy, że dokumentacja jest kompletna, nadszedł czas na pokazanie jej naszym współpracownikom w celu uzyskania uwag, zebrania pytań i wprowadzenia na ich podstawie zmian czy to stylistycznych czy całościowo opisu funkcjonalnego. Uważam, że ten krok jest niezbędny ponieważ to własnie oni stają się pierwszymi "użytkownikami" naszego systemu jeszcze w wersji projektowania! Spojrzenie z innego punktu na projekt często rzuca na niego zupełnie nowe światło i może się okazać że zapomnieliśmy o kilku ważnych kwestiach.
Co dalej?
Z tak przygotowaną specyfikacją możemy rozpocząć wycenę projektu. Oczywiście w trakcie napewno pojawią się pytania z naszej strony, które dodadzą szczegółów w dokumentacji. Lecz w tym wypadku im więcej tym lepiej.
Świadczymy usługę przygotowania specyfikacji dla klienta. Proces ten wygląda bardzo podobnie do wyżej przedstawionego z tą różnicą, że to my ją piszemy. Naszym zadaniem jest przeprowadzenie wywiadu z klientem i zadanie serii pytań na temat projektu. Jeżeli interesuje Cię nasza oferta zapraszam do odwiedzenia naszej strony oraz kontaktu poznaj jak pracujemy oraz jakie jest nasze doświadczenie.
