🚀 go-pugleaf

"yapann" <yapann@odwa.pl> writes:

> pytanie proste jak nanorurki: czy przypadek użycia JEST wymaganiem.

To zależy, jakie są wymagania dotyczące określenia wymagań.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

> To zależy, jakie są wymagania dotyczące określenia wymagań.
- kto tam?
- niezależna telewizja 'Piraci'
- niezależna od czego?
- to zależy.

proszę o odpowiedź w odniesieniu do tereminologii pokutującej inżynierii 
wymagań (wymaganie, specyfikacja wymagania, dokumentacja wymagania, etc), 
lub z załączeniem stosownych definicji.

"yapann" <yapann@odwa.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości
>
>> To zależy, jakie są wymagania dotyczące określenia wymagań.
> - kto tam?
> - niezależna telewizja 'Piraci'
> - niezależna od czego?
> - to zależy.
>
> proszę o odpowiedź w odniesieniu do tereminologii pokutującej
> inżynierii wymagań (wymaganie, specyfikacja wymagania, dokumentacja
> wymagania, etc), lub z załączeniem stosownych definicji.

Istnieją tzw. dobre praktyki określania wymagań.

Użytkownik ""Piotr Dembiński"" <pdemb@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ń. 

On 17 Maj, 12:05, "yapann" <yap...@odwa.pl> wrote:
> Użytkownik "ToJaJarek" <tojaja...@gmail.com> napisał w wiadomości
>
> > Mom zdaniem PU może być wymaganiem ale nie musi
>
> uściślam swoje pytanie: 'czy PU reprezentujący funkcjonalność jest
> wymaganiem'. Chodzi wyłącznie o poprawność sformułowań. Zdanie 'PU jest
> wymaganiem' to pochodzi z książki, podczas gdy ja raczej powiedziałabym
> 'jest specyfikacją wymagania', a nie wymaganiem. Potrzebuję wyjasnienia tego
> niuansu, gdyż piszę kilka zdań, które mogą czytać powazni ludzie i nie mogę
> pozwolić sobie na lamerskie sformułowania.
>
> > W tym przypadku PU są narzędziem
> > analizy i projektowania a nie określania wymagań.
>
> otóż to ('narzędziem' zamieniłabym na notacją, bądź jak wcześniej ktoś
> sugerował).
> mowa o PU jako o konkretne wystąpieniu PU, nie jako notacja.
>
> a więc jeszcze raz: czy sformułowanie:
>   'Przypadek użycia jest wymaganiem'
> może być poprawne.?

Moim zdaniem nie. Napisał bym: PU jest jedną ze spotykanych form
dokumentowania wymagań. Ja niegdy nie napisąłm bym, że 'Przypadek
użycia jest wymaganiem'.

rzecz w tym, że tworzenie przypadków użycia może być elementem
projektowania po zawariu umowy. Po tzrecie polecam ksiązkę Cocbourna :
"Jak pisac efektywne przypadki użycia", jest tam wiele wskazówek i
ciekawych opinii na temat PU.

Użytkownik "ToJaJarek" <tojajarek@gmail.com> napisał w wiadomości

> Po tzrecie polecam ksiązkę Cocbourna :
:-) właśnie w niej jest takie sformułowanie, które mi zgrzytło, więc 
zastanawiam się, czy dobrze je czytam:

"If you are writing use cases as requirements, you should keep two things in 
mind.
They really are requirements. You shouldn't have to convert them into some 
other form of
behavioral requirements."

btw - b. nietrywialna książka, szacuneczek.

"yapann" <yapann@odwa.pl> writes:

> Użytkownik "ToJaJarek" <tojajarek@gmail.com> napisał w wiadomości
>
>> Po tzrecie polecam ksiązkę Cocbourna :
> :-) właśnie w niej jest takie sformułowanie, które mi zgrzytło, więc
> zastanawiam się, czy dobrze je czytam:
>
> "If you are writing use cases as requirements, you should keep two
> things in mind.  They really are requirements. You shouldn't have to
> convert them into some other form of behavioral requirements."
>
> btw - b. nietrywialna książka, szacuneczek.

Rozumiem.  Autor potrafi tworzyć tautologie, czyli nietrywialna.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

> Rozumiem.  Autor potrafi tworzyć tautologie, czyli nietrywialna.
teraz ja nie rozumiem ..o ile tautologia będzie nietrywialna, to się zgadza 
:-). 

"yapann" <yapann@odwa.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości
>
>> Rozumiem.  Autor potrafi tworzyć tautologie, czyli nietrywialna.
> teraz ja nie rozumiem ..o ile tautologia będzie nietrywialna, to się
> zgadza :-).

Ale zgadzasz się z tym, że przytoczone przez ciebie zdanie jest
tautologią?

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

> Ale zgadzasz się z tym, że przytoczone przez ciebie zdanie jest
> tautologią?
nie. osobiście zdecydowanie nie zgadzam się.

przekształcam do tautologii:
'If you are writing use cases as requirements, you should keep two things in
mind.
They really are use case requirements'
:D

i przekształcając do sformułowania, które by mi nie zgrzytało:
"If you are writing use cases as requirements, you should keep two things in
mind.
They really represent requirements."

'represent' - można zastąpić: 'document', etc.

W zasadzie różnica nie jest rażąca, ale nadal uprę się, iż 'wymaganie' to 
rzecz abstrakcyjna i byłabym raczej uważna stosując ten termin wymiennie z 
'artefaktem ze specyfikacją wymagania', co tożsame dla mnie nie jest.
Ale chyba to już przynudzanie się zrobiło, więc dzięki za dyskusję.

"yapann" <yapann@odwa.pl> writes:

[...]

> W zasadzie różnica nie jest rażąca, ale nadal uprę się, iż
> 'wymaganie' to rzecz abstrakcyjna i byłabym raczej uważna stosując
> ten termin wymiennie z 'artefaktem ze specyfikacją wymagania', 
> co tożsame dla mnie nie jest.

IMO nie tyle 'artefaktem ze specyfikacją' co 'artefaktem będącym
specyfikacją lub jej częścią'.  Jeśli chodzi o sam dokument
określający wymaganie, to ten dokument nie musi być artefaktem.

-- 
http://www.piotr.dembiński.prv.pl