🚀 go-pugleaf

On 16 Maj, 14:41, "yapann" <yap...@odwa.pl> wrote:
> Użytkownik ""Piotr Dembiński"" <p...@gazeta.pl> napisał w wiadomości
>
> > Istnieją tzw. dobre praktyki określania wymagań.
>
> zatem, czy uznałbyś określenie: 'przypadek użycia jest wymaganiem' za
> niepoprawne, ze względu na którąś z wytycznych wspomnianych praktyk?
>
> Istotą mojego pytania jest uniknięcie rażących nieprawidłowości w
> nazewnictwie i merytoryce podczas posługiwania się terminologią dobrych
> praktyk określania wymagań.

Mom zdaniem PU może być wymaganiem ale nie musi. Słuszna uwaga
brzmiała: czego oczekuje zamawiajacy?

Wymagania na system można zamknąć stwierdzeniem: "system ma wspierać
proces wystawiania faktur zgodnie z obowiązujacymi przepisami,
pozwalać na sporządzanie wymaganych przepisami zestawień i raportów
dla urzędów.". Można jednak spisać serię interakcji z systemem
typu :logowanie, wprowadzanie danych kontrahentów ..........." i
zabrnąć w opasłe i pracochłonne (czytaj kosztowne) dokumenty plus
skomplikowana (czytaj kosztowna) procedura zmian w projekcie.

W obu przypadkach są to jednak przypadki użycia, kwestia ich
ogólności. Rzecz w tym, że im są one bardziej szczegółowe tym bardziej
ograniczają inwencję wykonawcy i podnoszą koszty zarządzania zmianami
w projekcie ale im są bardziej ogólne tym bardziej projekt narażony
jest na ryzyko, że klient nie odbierze produktu.

Ot moim zdaniem sztuka kompromisu. Dlatego ja jak określam wymagania
to nie opisuję ich od razu przypadkami użycia (czym czymkolwiek innym
takim) a spisuję cele jakie zamawiający chce tym programem
fakturowania osiągnąc a moga to być np.: skrócenie czasu wystawiania
faktur do 5 minut, minimalizacja błednych faktur do poziomu 1%, dostęp
do historii sprzedaży z ostatniego roku, generowanie danych do
deklaracji podatkowych. To są cele biznesowe, taki opis pozwala na
określenie zakresu projektu i odebranie go. Szczegóły interfejsu itp.
to etap projektowania i modelowania. W tym przypadku PU są narzędziem
analizy i projektowania a nie określania wymagań.