Temat: Scenariusze użycia w SRS czy jako osobny dokument

Scenariusze użycia, tak zwane przypadki użycia powinny być umieszczone w SRS czy stanowić osobny dokument? Czy zaś w przypadku dobrze opisanego SRS nie ma konieczności tworzenia scenariuszów użycia, jak to wygląda w praktyce?

Sam, dla swoich klientów mogę pisać SRS, a przypadki użycia umieszczać w osobnym dokumencie stricte dla programisty, ale chciałbym dowiedzieć się jak to wygląda w rzeczywistości, w korporacjach i mniejszych firmach.

Kolejne pytanie, scenariusze testowe (UAT) podobnie jak wyżej w SRS czy osobny dokument?

Trzecie, ostatnie pytanie, dokumentacja interfejsów w SRS czy też jako osobny dokument?

Ogólnie mówiąc SRS to dokumentacja wymagań oprogramowania, która zawiera w sobie trzy najważniejsze wymagania biznesowe, funkcjonalne, użytkownika, które są dalej rozdzielone na wymagania pozafunkcjonalne, wymagania systemowe, ...

Temat: Scenariusze użycia w SRS czy jako osobny dokument

Nie chciałem tworzyć już osobnego tematu (ostatnie cztery tematy w grupie to ode mnie ;))

Procesy takie jak BPA, BPR, BPI, BPM służące do analizy wewnątrz przedsiębiorstwa, czy można te procesy wykorzystać celem zrozumienia modelów biznesowych etc. wśród konkurencji (dla moich klientów). Rozpocząłem właśnie kształcenie się z kierunku tych procesów i takie moje podstawowe pytanie.

Temat: Scenariusze użycia w SRS czy jako osobny dokument

Straszny bałagan pojęciowy w tych pytaniach....

SRS to skrót, jego definicji jest tyle ilu ich autorów. Dopiero zdefiniowanie tego czym jest "wymaganie" pozwoli o czymkolwiek rozstrzygać. Dla jednego "wymaganiem" jest "schody muszą być ładne i funkcjonalne" a dla innego wymaganiem jest 'schody muszą wykonane zgodnie ze szkicem...".

Przypadek użycia także wymaga doprecyzowanie bo czym innym jest w UML a czym innym np. w książce A.Cokburna "Stosowanie przypadków użycia".

W UML mamy:

Z perspektywy zamawiającego "przypadek użycia" to: "fakturzysta (aktor) na podstawie zamówienia wystawia z użyciem systemu fakturę" i to jest wymaganie. Scenariusz interakcji aktor-system to już projektowanie rozwiązania.

Aktorem może być człowiek lub inny system, więc interfejs integracyjny oferowany to także przypadek użycia, interfejs wymagany to nasze wymaganie wobec innego systemu.

Poprawnie opisane przypadki użycia z zasady są testami akceptacyjnymi (ale należy do testów dostarczyć partie danych testowych).

Wymagania biznesowe nie są wymaganiami wobec oprogramowania. Biznes ma wymagania np. "podniesienie jakości obsługi klienta o 10% w ankiecie badania jakości", rozwiązaniem wspierającym ten cel biznesowy jest wdrożenie oprogramowania CRM, wymaganiem wobec CRM jest "fakturzysta (aktor) na podstawie zamówienia wystawia z użyciem systemu fakturę".

Do tego należy dodać ograniczenia, np. "psuje się nie częściej niż", "radzi sobie z pracą 200 fakturzystów jednocześnie", .....

Pojęcie (choć często stosowane) wymagania funkcjonalne, poza-funkcjonalne, itp. nie mają ścisłych definicji i należy jest sobie w dokumencie zdefiniować albo przestać nie używać.

BPA, BPR, BPI, BPM to nie są żadne procesy... a co najwyżej pewne podejścia do analizy i modelowania organizacji.