Jak napisać specyfikację funkcjonalną? [zamknięte]
Zawsze piszemy funkcje lub klasy, a ich logika jest bardzo skomplikowana. Jeśli nie ma specyfikacji dla tych struktur, później będzie trudno nawet nam zrozumieć idee.
Jak pisać specyfikacje dla skomplikowanych funkcji i klas?
Proszę opowiedz mi coś o własnych doświadczeniach, ale nie o jakimś linku, dzięki.
4 answers
Uważam, że największym wyzwaniem ze specyfikacjami funkcjonalnymi nie jest format bezpośrednio, ale utrzymanie ich w synchronizacji z rzeczami, które je napędzają (wymagania) i rzeczy, które na nich budują (przypadki testowe, dokumentacja).
Z tego powodu wolę zająć się tym problemem z podejściem opartym na modelu, a nie na papierze.
Używam narzędzia do modelowania UML (Enterprise Architect firmy Sparx Systems, ale wiele narzędzi również działa), aby uchwycić wszystkie artefakty projektu w jedno miejsce i stworzyć identyfikowalność między nimi. W programie Enterprise Architect mogę utworzyć identyfikowalność od artefaktu wymagającego do artefaktu projektowego (na przykład), umieszczając je na tym samym schemacie i tworząc złącze między sobą za pomocą przeciągnięcia myszką.
Moja "Specyfikacja funkcjonalna" jest w rzeczywistości zbiorem diagramów aktywności, po jednym na każdy przypadek użycia w systemie. Każdy przypadek użycia wiąże się z jednym lub kilkoma wymaganiami, które wymagają tego przypadku użycia. Nawet użytkownicy końcowi łatwo jest śledzić diagramy aktywności i sprawdzać je (jak łatwo jest skłonić użytkowników końcowych do przeczytania, nie mówiąc już o zrozumieniu i walidacji tradycyjnej, papierowej specyfikacji funkcjonalnej?)
W podobny sposób mogę tworzyć identyfikowalność od moich diagramów aktywności (przypadków użycia) do konkretnych artefaktów projektowych, takich jak diagramy klas.
QA może modelować przypadki testowe i tworzyć identyfikowalność od ich przypadków testowych do przypadków użycia. W ten sposób zobaczymy, czy są jakieś przypadki użycia, które nie ma przypadków testowych (lub nie ma wystarczającej liczby przypadków testowych).
Dobrą rzeczą w Enterprise Architect jako narzędziu jest to, że wszystkie te artefakty są przechowywane w bazie danych SQL, więc mogę po prostu uruchomić kilka zapytań, które zbudowałem w czasie, aby znaleźć artefakty bez śledzenia do/z nich.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-28 23:43:10
Sprawdź Joel on Software . I Tutaj . I tutaj . Istnieje nawet przykład ze świata rzeczywistego .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-28 23:39:54
Należy dokonać badań na następujące tematy (niekoniecznie w kolejności):
Są to najczęstsze podejścia do specyfikacji projektów oprogramowania.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-28 23:46:20
Widzę kilka skarg powyżej na posiadanie linków do rzeczy Joela, a nie tekstu w linii, więc oto moje podejście do tego, co mówi.
Na najwyższych poziomach specyfikacje funkcjonalne muszą komunikować się z konsumentem lub klientem, co program zamierza zrobić. Jestem w 100% z Joelem w tej kwestii: Angielski(no cóż!) język używany z rygorem jest bardzo potężnym narzędziem, które wszyscy twoi klienci będą ekspertami w trawieniu. Eksperci w UML nie są.
A top-level functional dokument specyfikacji (FSD) może zapewnić logiczną strukturę, która rejestruje wymagania systemu w modelu logicznym , że ludzie mogą łatwo zrozumieć.
Dokumenty Pure requirements-coś, co poprzedza FSD - są trudnymi rybami do opanowania. Bardzo niewiele osób jest w stanie umysłowo odróżnić, co jest wymogiem, a co jest częścią rozwiązania. Tak więc najlepiej utrzymać wymagania na bardzo wysokim poziomie i, jako analityk, skupić się na FSD.
FSD powinien być kompletnym modelem najwyższego poziomu systemu, a następnie procesem projektowania o bardziej szczegółowym udoskonaleniu hierarchii modeli. Ostatnim poziomem szczegółowości jest prawdziwy kod.
FSD powinien skończyć się zestawem prostych angielskich instrukcji. Użyj jednego poziomu nagłówka w dokumentach, trzymaj paras maksymalnie dwa zdania i Numeruj każdy para. Przejrzyj paras i upewnij się, że każdy z nich mówi coś użytecznego. Jeśli nie, usuń go. Krótkie jest dobre!
Myśl bardzo ciężko o język w Twoim FSD. Miej rygorystyczne definicje kluczowych rzeczowników w akapitach. Te rzeczowniki stają się Twoimi klasami. Czasowniki, których używasz, stają się Twoimi metodami klasowymi. To naprawdę takie proste!
Jak mówi Joel, pisz zdania, jakbyś miał je skompilować. Na przykład, napisz "If stuff happens thendo more" than If stuff happens, do more "or" do more when stuff happens".
Tego rodzaju pisane modele mogą korzystaj z użycia konkretnych diagramów, takich jak skończone diagramy stanu, ale uważaj na myślenie, że możesz uchwycić system za pomocą zestawu diagramów UML. Te rzeczy po prostu nie są potężne, elastyczne lub wystarczająco rygorystyczne, aby działać jako kompletny opis same w sobie. O wiele bardziej skuteczne jest rozpoczęcie od zarysu napisanego w rygorystycznym języku angielskim i uzupełnienie go w razie potrzeby.
Jeśli chodzi o problemy iteracji, w idealnym świecie należy tylko przerobić niższe poziomy model. Jeśli trzeba zmienić wysoki poziom, coś poważnego było nie tak. Jeśli chodzi o narzędzia UML, które są szybsze w umożliwianiu rewitalizacji-poppy-cock! Najważniejsze jest to, że wszystkie te opisy są krótkie i zwięzłe. Angielski jest dobrą drogą, ponieważ wszyscy praktykowaliśmy to od tak dawna.
Widziałem ludzi spędzających popołudnie starając się, aby wykresy jednostek wyglądały ładnie pod względem nakładających się linii. Na przykład dlaczego? Czy Twoje rozwiązanie ultimate jest dwuwymiarowe? Nie! I to jest problem z UML: diagramy stają się celem samym w sobie dla analityka i odcinają Cię od klienta, a nie wspomagają komunikację.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-11-14 14:46:36