Dokumentacja wewnętrzna może powstać, ale... kto będzie jej odbiorcą i jakie ma potrzeby? Nie produkuje się kwitów, żeby produkować. Musi być ku temu potrzeba :-)
Na pewno (chociaż nie wszystko widziałem ;) ) nie jest tak, że developer dostaje zadanie "weź zaimplementuj system X", tylko powinien dostać materiały wejściowe na podstawie, których ma pracować, do których będzie miał pytania/wątpliwości. Te materiały wejściowe powstają na wcześniejszych etapach prac różnych grup osób. Mogą być uszczegóławiane w dokumencie, na daily meetingach, rozmowie itd. Zależy od tego jak firma pracuje.
Ja często spotykam się z takimi grupami:
- Odpowiedź na RFP - koncepcja systemu
- High Level Design - rozwinięcie koncepcji opisanej w RFP (kamień milowy projektu) i urealnienie tego co się da, albo wypracowanie rozwiązań alternatywnych
- Low Level Design - doszczegółowienie JAK to zostanie zrobione - dla klienta
- internal LLD - dla zespołu, rozwianie wątpliwości
W strukturze takiego dokumentu odnosisz się do:
- Scenariuszy (procesów) biznesowych
- Wymagań funkcjonalnych
- Wymagań niefunkcjonalnych
- Integracji
- Konfiguracji
- Migracji
Osobiście nigdy nie widziałem RFP, w którym klient życzyłby sobie by prace prowadzone były w trybie "zwinnym". Zazwyczaj kontrakty przewidują płatności po osiągnięciu określonych kamieni milowych projektu i jak pracować zwinnie wobec waterfallowego harmonogramu? :)
Zdarza się też tak, że prace prowadzone są w trybie rozwojowo-utrzymaniowym, tzn. klient coś zleca w oparciu o umowę ramową i wówczas ścieżka jest krótsza, więc dokumentuje się tylko "delty".
Nie ma tak, że "zobacz kliencie jaki diagram klas zrobiłem, prawda że fajny?" (a klient, "po wuja mi ten diagram klas?"), tylko robi się minimum i poprawia na życzenie "weź drogi dostawco dodaj diagram sekwencji ilustrujący komunikację między systemami biorącymi udział w realizacji tego scenariusza, tylko bez zbytniej dbałości o szczegóły implementacyjne", albo kolega z zespołu "weź mi to rozrysuj zamiast opowiadać i pisać maile".