Jak pisać specyfikację funkcjonalną?

niedziela, 16 maja 2010
Piszę ten artykuł, ponieważ gdy sam potrzebowałem wiedzy na ten temat, nie mogłem znaleźć w sieci jakichkolwiek konkretnych informacji.
Należy jednak pamiętać, że artykuł ten mówi o AKADEMICKIEJ WERSJI SPECYFIKACJI IMPLEMENTACYJNEJ, czyli takiej, która jest wystarczająca do projektów własnych i nie ma nic wspólnego z wersją Enterprise.
Otóż specyfikacja funkcjonalna to dokument zawierający wszystkie FUNKCJONALNE rozwiązania w danym programie/projekcie. Poprzez "funkcjonalne rozwiązania" mam na myśli po prostu czynności/rzeczy, które program będzie wykonywał. Opis danej funkcjonalności nie powinien zawierać nawet opisu algorytmu. Tak dokładnie specyfikacja funkcjonalna składa się z kilku rozdziałów i najprościej mówiąc jest informacją ogólną o programie, częściej przeznaczoną dla klienta/użytkownika (choć dla programisty również).

Rozdział 1: OPIS OGÓLNY
Podrozdział 1.1: Nazwa programu.
Informacja o nazwie programu, np.: "superProgramObliczający".

Podrozdział 1.2: Poruszany problem.
Czyli opis ogólny programu: jakie czynności będzie wykonywał i do czego będzie służył.

Podrozdział 1.3: Użytkownik docelowy.
Tu należy odpowiedzieć na pytanie: "Dla kogo dedykowany jest program i kto będzie jego użytkownikiem?"


Rozdział 2: OPIS FUNKCJONALNOŚCI

Podrozdział 2.1: Jak korzystać z programu?
Najczęściej kilku zdaniowy opis ogólny uruchamiania programu.

Podrozdział 2.2: Uruchomienie programu.
Na przykład treść polecenia(parametrów) do wywołania z linni komend, uruchamiające nasz program.

Podrozdział 2.3: Możliwości programu.
Wypunktowane zadania, jakim nasz program będzie mógł sprostać.


Rozdział 3: FORMAT DANYCH I STRUKTURA PLIKÓW

Podrozdział 3.1: Pojęcia i pola formularza (słownik).
Opisane pojęcia najczęściej używane w programie oraz pola formularza - co konkretnie oznaczają, czym są. Słownik pojęć dla klienta.

Podrozdział 3.2: Struktura katalogów.
Informacja o tym co będzie gdzie przechowywane. Np.: "Katalog z bazą będzie przechowywany w podkatalogu 'baza', a plik log.txt będzie umieszczony w tym samym katalogu co plik wykonywalny".

Podrozdział 3.3: Przechowywanie danych w programie.
Jest to bardzo ważny rozdział, ponieważ stanowi wstęp do struktury danych w naszym projekcie. Powinny się tu zawierać informacje podstawowe i ogólne na temat sposobu przechowywania danych zarówno na dysku jak i w programie (np. struktura, tablica struktur).

Podrozdział 3.4: Dane wejściowe.
Informacja o wszystkich danych/plikach wejściowych, na których operował będzie program.

Podrozdział 3.4: Dane wyjściowe.
Czyli to, co generował będzie program poprzez swoją pracę (np. plik logujący, przetwarzane pliki z danymi).


Rozdział 4: SCENARIUSZ DZIAŁANIA PROGRAMU.

Podrozdział 4.1: Scenariusz ogólny.
Wypunktowane główne kroki działania programu, czyli np.: -uruchomienie, -sprawdzenie czegoś, -wykonanie czegoś, -zakończenie działania programu,

Pozdrozdział 4.2: Scenariusz szczegółowy
. Wypunktowane praktycznie wszystkie etapy działania programu z uwzględnieniem sytuacji, gdy coś idzie nie tak, jak zostało założone, czyli np. jakiś warunek nie zostaje spełniony, użytkownik nie podaje jakichś danych, na co program musi być odporny. Ogółem jest to plan szczegółowy, razem z "pobocznymi wątkami" działania programu.

Podrozdział 4.3: Ekrany działania programu.
W przypadku, gdy nasz program ma GUI, należy ten rozdział rozbić na podpodrozdziały i opisać ekran GUI dla każdej z funkcji oraz zamieścić odpowiednie obrazki.

Rozdział 5: TESTOWANIE.

Podrozdział 5.1: Ogólny przebieg testowania.
Na przykład: Do przetestowania kodu użyję narzędzia JUnit, a GUI przetestuję ręcznie podczas tworzenia aplikacji. Jednym słowem informacja, czy za testowanie zapłacimy 3mln $$, czy zrobimy to w fajny, sprawny i mądry sposób podczas (lub przed, patrz Programowanie sterowane testami).

Wzór ten można dowolnie adaptować na potrzeby danego projektu, na przykład podrozdział o danych wyjściowych można wyciągnąć do oddzielnego rozdziału. Dodatkowo możemy opisać krótko w jaki sposób zamierzamy przetestować naszą aplikację.

15 komentarze:

Unknown pisze...

hehe jaki zbieg okoliczności, jesteś na pierwszym miejscu w google po wpisaniu "specyfikacja funkcjonalna". Jstar w tym roku na życzenie dał schemat jak to ma wyglądać http://wikidyd.iem.pw.edu.pl/index.cgi/Jimp2/Projekt?action=AttachFile&do=view&target=spraw.tgz . Z tego co widzę ty masz wersję rozbudowaną. Dzięki, przyda się.
Zając

Unknown pisze...

Cieszę się. Jeszcze rok temu ani wykładowcy nic nie udostępnili, ani w sieci nie było informacji na ten temat.
Pozdro :)

Anonimowy pisze...

Serdecze dzieki:)) Nic nie mogłem sensownego dotychczas znaleźć. A tu proszę:))
Rzeczowo i na temat.Thx.
Miro

Anonimowy pisze...

Ach ten J*.
Bardzo przydatne. Świetne opracowanie.
Pozdr.
-a;

Anonimowy pisze...

Rewelacyjny i prosty opis - bardzo dziekuję za uporządkowanie mojej wiedzy!

TeMPOraL pisze...

No nieźle... nie spodziewałem się, że trafię na Twój tekst szukając informacji o specach funkcjonalnych :). Gratuluję!

Anonimowy pisze...

Dziękuję :)

RF pisze...

Dzięki

Anonimowy pisze...

Dzięki wielkie za ten artykuł! Od dwóch godzin siedzę i myślę, jak się zabrać do mojej specyfikacji projektu na zaliczenie a mogłam od razu zajrzeć tutaj, dokładnie tego potrzebowałam!

Anonimowy pisze...

Kolejny rocznik od J* dziękuje za pomoc :D

Czarek pisze...

j* for life

Anonimowy pisze...

Ave j*

Anonimowy pisze...

Jeszcze dziś korzystam. Bardzo dziękuję!

Anonimowy pisze...

Czeladnik - uczeń j* też wymagania jak u mistrza

Anonimowy pisze...

Świetny artykuł, J* i Pawełek na pewno zadowoleni

Prześlij komentarz