Właściwa dokumentacja projektowa składać powinna się z:
- Dokumentacji wymagań oprogramowania SRS,
- Dokumentacji interfejsów,
- Przypadków użycia,
- Testów akceptacyjnych UAT.
W dokumentacji powinny (ale nie muszą) zostać zawarte notacje UML, a czasami także BPMN choć tych zazwyczaj stosuje się w procesach biznesowych, aczkolwiek osobiście lubię stosować te notacje w projektach IT. Przed rozpoczęciem prac nad powyższymi dokumentami, stworzony powinien zostać podstawowy dokument biznesowy Wizja i Zakres stanowiący bazę odniesienia dla późniejszych prac.
Jedna z najlepszych w Polsce książek o specyfikowaniu wymagań to "Specyfikacja oprogramowania. Inżynieria oprogramowania" wydana przez Helion, gdzie dostępne masz przykłady jak powinny wyglądać powyższe struktury dokumentów: http://helion.pl/ksiazki/specyfikacja-oprogramowania-inzynieria-wymagan-wydanie-iii-karl-e-wiegers-joy-beatty,speop3.htm#szczegoly (pobierz przykłady FTP).
Jak powinien wyglądać proces projektowania? Powinny zostać zastosowane najlepsze praktyki z zakresu inżynierii oprogramowania. Przede wszystkim powinny zostać zaangażowani docelowy interesariusze w prace nad wymaganiami, bo to dla nich będzie tworzona gra, powinni wziąć udział w prototypowaniu. Praca nad wymaganiami to złożony proces wiem to jako analityk biznesowy, architekt systemów informatycznych. Jeżeli jest budżet warto pomyśleć o sesjach JAD, grupach fokusowych, wywiadach.
Jeżeli tworzysz projekt w celach komercyjnych i ważny jest dla Ciebie poziom, chętnie podejmę się przeprowadzenia procesu projektowania i specyfikowania wymagań.
Pomyśl też nad Customer Developemt, aby zbudować skalowalny, powtarzalny i zyskowny model biznesowy.