Ja tak z pozoru offtopicznie:

On Thu, 27 Dec 2012, boryspower wrote:

> Przykład: Stworzenie aplikacji do fakturowania

1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
2. Spytać "fachowca" jak ma być
3. Stwierdzić że coś nie pasuje
4. Sprawdzić to i owo w internecie
5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)

Potem można zabrać się za rozważania jak program ma działać.

Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
na to jak można wtopić na błędach założeń :)
Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
podatek który musi być ujawniany na dokumencie) jest dopuszczalne
na wiele sposobów, w tym takich trudniejszych do wymyślenia,
ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
się do któregoś spośród tych wielu) i wtedy na .podatki pojawia
post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
bo twierdzą że system nie pozwala" :P

Nie, nie mam na myśli stawki itede :)

Obstawiam że takich przypadków jest sporo - coś co wydaje się
proste zawiera pułapki które później trudno usunąć.
Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
"24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
poprawienie wszystkich pól, bo nie sposób przewidzieć która
z kombinacji "metod" może wyskoczyć.
Uczciwie - przewidziałbyś?
Nie ma to nic wspólnego z tym co opisałeś - co wykonawca może
zrobić doskonale po stworzeniu własnego opisu.

> - jak przygotować dokumentację/opis projektu

Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
(patrz p.1 :), polecam osobiście zajrzeć do treści)

pzdr, Gotfryd