Temat: Dynamiczne role w przypadkach użycia

Witam.

Ostatnimi czasy zastawiałem się jak właściwie zamodelować przypadek użycia, a właściwie jak dobrać do niego rolę/aktora w przypadku, gdy role i możliwe realizowane przez nie przypadki użycia mogą się zmieniać w dowolnym czasie funkcjonowania systemu. Moją "zagwozdkę" opisze na przykładzie.

Załóżmy, że realizujemy przypadek w jakimś systemie finansowym, np - "autoryzuj transakcję". Przypadek ten jest realizowany przez aktora "główny księgowy". Ale nie jest powiedziane, że to ta rola musi realizować taki przypadek, nie jest powiedziane, że taka rola musi w ogóle istnieć w systemie. System umożliwia definiowanie ról i przypisywanie im odpowiedzialności za realizację przypadków już w momencie działania systemu (na przykład uprawnieniami do realizacji jakiś procesów biznesowych). I tak w trakcie działania systemu przypadek (proces biznesowy) możemy przypisać zarówno głównemu księgowymi, ale również np. "sekretarce" - wolna wola. Rola "główny księgowy nie musi istnieć w systemie.

Jak opisać przypadek "autoryzuj transakcję"? Jak go przedstawić na UCD? Myślałem, nad oznaczeniem aktora "główny księgowy" jako aktora abstrakcyjnego, ale w sieci zetknąłem się z opiniami, że takowi aktorzy owszem istnieją, ale z nich wywodzą się konkretni aktorzy (w opisywalnym systemie takowych nie znamy). W literaturze, która posiadam nie ma nawet wzmianki o takich aktorach.

Z góry dzięki za rady i dyskusję :-)

Temat: Dynamiczne role w przypadkach użycia

Nie wiem jak to będzie w UML-u ale gdybym to bardziej od strony implementacji projektował. To zaenkapsulował bym poszczególne procesy biznesowe w obiekty komend (command pattern). Wtedy można definiować sobie różne wirtualne role i przypisywać im prawa do poszczególnych procesów.

Temat: Dynamiczne role w przypadkach użycia

Jak opisać przypadek "autoryzuj transakcję"? Jak go przedstawić na UCD? Myślałem, nad oznaczeniem aktora "główny księgowy" jako aktora abstrakcyjnego, ale w sieci zetknąłem się z opiniami, że takowi aktorzy owszem istnieją, ale z nich wywodzą się konkretni aktorzy (w opisywalnym systemie takowych nie znamy). W literaturze, która posiadam nie ma nawet wzmianki o takich aktorach.

W UML są aktorzy a nie role ;)
Jeśli potencjalnie każdy rodzaj user'a może wywołać 'autoryzacja transakcji' to chyba nie ma innego wyjścia jak przypisać ten przypadek użycia do aktora 'user'.

Z drugiej strony - fakt, że w aplikacji może zajść sytuacja pt. 'każdy może wszystko', świadczy o tym, że jej analiza jest skopana a Ty rozwiązujesz(a właściwie propagujesz błąd analizy na cały system) nie swój problem.Jakub Wojt edytował(a) ten post dnia 30.09.11 o godzinie 13:35

Temat: Dynamiczne role w przypadkach użycia

To, czy zajdzie sytuacja "każdy może wszystko", zależy wyłącznie od tego jak system zostanie skonfigurowany już przez użytkowników. Sytuacja podobna jak z Windowsowymi uprawnieniami - to, że każdemu można dać Administratora systemu to nie wynik jego błędnego zaprojektowania.

Czy wobec tego, na diagramie przypadków użycia wszystkie przypadki przypisać pod jednego aktora? Ale czy wtedy będzie można wywnioskować jakoś, że dany przypadek może, ale nie musi być realizowany przez aktora "user"?Łukasz L. edytował(a) ten post dnia 30.09.11 o godzinie 12:52

Temat: Dynamiczne role w przypadkach użycia

To, czy zajdzie sytuacja "każdy może wszystko", zależy wyłącznie od tego jak system zostanie skonfigurowany już przez użytkowników. Sytuacja podobna jak z Windowsowymi uprawnieniami - to, że każdemu można dać Administratora systemu to nie wynik jego błędnego zaprojektowania.

Ale na co to jest argument ? :)
Windows ma trochę inne UC niż system do obsługi biura.

Czy wobec tego, na diagramie przypadków użycia wszystkie przypadki przypisać pod jednego aktora?

Tak. Ewentualnie (chociaż wtedy diagram będzie błędny - 'autoryzacja' to uprawnienie a nie rola) możesz zrobić aktora 'autoryzujący transakcję' i tylko jemu przypisać ten UC.

Ale czy wtedy będzie można wywnioskować jakoś, że dany przypadek może, ale nie musi być realizowany przez aktora "user"?

Tak. Ale taki diagram jest zbyt ogólny tzn. Jest zły.
Myślę, że najlepszym wyjściem jest udanie się do analityka wypersfadowanie mu zamiany uprawnienia ‘autoryzacja’ na rolę (podobnie jak sekretarka, dyrektor itd...) Gwarantuję, że to rozwiąże problem (i zaoszczędzi kilku w przyszłości).

Temat: Dynamiczne role w przypadkach użycia

Czemu nie dodać przypadku użycia np. "weryfikacja uprawnień" ,który byłby wykorzystywany przez inne UC na zasadzie <<include>>?

Od strony programistycznej podejście AOP (Aspect Oriented Programming) adresuje takie techniczne (tj. uprawnienia, logowanie, transakcyjność) problemy.

Temat: Dynamiczne role w przypadkach użycia

Paweł Grzegorz Kwiatkowski:
Czemu nie dodać przypadku użycia np. "weryfikacja uprawnień" ,który byłby wykorzystywany przez inne UC na zasadzie <<include>>?

Z dwóch powodów:
1. To zmasakruje diagram
2. "weryfikacja uprawnień"... najprawdopodobniej ... nie jest przypadkiem użycia.

Od strony programistycznej podejście AOP (Aspect Oriented Programming) adresuje takie techniczne (tj. uprawnienia, logowanie, transakcyjność) problemy.

Także Łukaszu, nie ma problemu - musisz zmienić paradygmat 'modelowania', a nie kiepskiego analityka ;)Jakub Wojt edytował(a) ten post dnia 30.09.11 o godzinie 20:28

Temat: Dynamiczne role w przypadkach użycia

Jakub Wojt:

Paweł Grzegorz Kwiatkowski:
Czemu nie dodać przypadku użycia np. "weryfikacja uprawnień" ,który byłby wykorzystywany przez inne UC na zasadzie <<include>>?

Z dwóch powodów:
1. To zmasakruje diagram
2. "weryfikacja uprawnień"... najprawdopodobniej ... nie jest przypadkiem użycia

"Najprawdopodobniej" jest pojęciem rozmytym i starałbym się unikać takich sformułowań, które każdy może odbierać inaczej (np. 'jest ciepło' ;-) ).

Najlepiej przytocz konkretny (może być zupełnie teoretyczny) przykład, gdzie zaproponowany UC według Ciebie nie jest UC.

Przykład na tak :

Aktorem w takim przypadku "weryfikacja uprawnień" mógłby być zewnętrzny system (np. jakiś mechanizm globalnego zarządzania uprawnieniami w przedsiębiorstwie) i fragment diagramu UC mógłby w ascii [s]art[/s] wyglądać tak:

User--<UC_biznesowy>--<<includes>>--<UC_weryfikacja_uprawnien>--SecuritySystem

User - serkertarka, dyrketor, ...
SecuritySystem - system posiadający wiedzę o grupach/pracownikach

Od strony programistycznej podejście AOP (Aspect Oriented Programming) adresuje takie techniczne (tj. uprawnienia, logowanie, transakcyjność) problemy.

Także Łukaszu, nie ma problemu - musisz zmienić paradygmat 'modelowania', a nie kiepskiego analityka ;)

Dodam, że:
- AOP nie jest paradygmatem 'modelowania'
- AOP jest komplementarne do OOP
- odniosłem wrażenie, że na tej grupie dyskutujemy o zagadnieniach z różnych dyscyplin związanych z OOP

Myślę, że pytanie można przeformułować do "Jak modelować wymagania pozafunkcjonalne".

@Jakubie: jak modelujesz wymagania pozafunkcjonalne?

Temat: Dynamiczne role w przypadkach użycia

Z dwóch powodów:
1. To zmasakruje diagram
2. "weryfikacja uprawnień"... najprawdopodobniej ... nie jest przypadkiem użycia

"Najprawdopodobniej" jest pojęciem rozmytym i starałbym się unikać takich sformułowań, które każdy może odbierać inaczej (np. 'jest ciepło' ;-) ).

Najlepiej przytocz konkretny (może być zupełnie teoretyczny) przykład, gdzie zaproponowany UC według Ciebie nie jest UC.

Podam powody, dla których uważam, że taki UC to zły pomysł :)
1. 'Weryfikacja uprawnień' nie spełnia definicji UC.
"A use case in software engineering and systems engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful."
Teraz pytanie - co użytecznego daje użytkownikowi weryfikacja ? Czy weryfikacja jest częścią funkcjonalności biznesowej czy raczej sposobem na jej realizację ?

2. Krawędź między aktorem A a przypadkiem użycia PU jednoznacznie wyraża fakt ‘A ma prawo wywołać PU’. Diagram UC nie posiada elementu ‘pod warunkiem, że ’ i nie należy takiego ‘symulować’.

3. Aktor to użytkownik po weryfikacji uprawnień (skąd wiadomo, że dany użytkownik jest tym a nie innym aktorem).

Przykład na tak :

Aktorem w takim przypadku "weryfikacja uprawnień" mógłby być zewnętrzny system (np. jakiś mechanizm globalnego zarządzania uprawnieniami w przedsiębiorstwie) i fragment diagramu UC mógłby w ascii [s]art[/s] wyglądać tak:

User--<UC_biznesowy>--<<includes>>--<UC_weryfikacja_uprawnien>--SecuritySystem

Może jest poprawne ale ... mi się nie podoba. :)

Od strony programistycznej podejście AOP (Aspect Oriented Programming) adresuje takie techniczne (tj. uprawnienia, logowanie, transakcyjność) problemy.

Także Łukaszu, nie ma problemu - musisz zmienić paradygmat 'modelowania', a nie kiepskiego analityka ;)

Dodam, że:
- AOP nie jest paradygmatem 'modelowania'

Racja. Mój błąd.

- AOP jest komplementarne do OOP

Jak najbardziej. Jak się okazuje moja metoda na architekturę to takie AOP na sterydach.…

- odniosłem wrażenie, że na tej grupie dyskutujemy o zagadnieniach z różnych dyscyplin związanych z OOP

Chodziło mi raczej o to, że zmiana metodyki nie rozwiąże problemu.

Myślę, że pytanie można przeformułować do "Jak modelować wymagania pozafunkcjonalne".
@Jakubie: jak modelujesz wymagania pozafunkcjonalne?

Czy to pytanie o notację jaką stosuję przy tworzeniu ‘dokumentacji’ ?Jakub Wojt edytował(a) ten post dnia 03.10.11 o godzinie 11:48

Temat: Dynamiczne role w przypadkach użycia

Jakub Wojt:
...
Podam powody, dla których uważam, że taki UC to zły pomysł :)
1. 'Weryfikacja uprawnień' nie spełnia definicji UC.
"A use case in software engineering and systems engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful."
Teraz pytanie - co użytecznego daje użytkownikowi weryfikacja ? Czy weryfikacja jest częścią funkcjonalności biznesowej czy raczej sposobem na jej realizację ?

To jest jakiś argument, jednak:
* definicja za OMG UML Superstructure V2.1.2, "A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system." częściowo pokrywa sie z definicją przytoczoną przez Ciebie.

* "użyteczność" to znowu pojęcie, które ma różne znaczenie dla różnych użytkowników, właściwie każdy użytkownik indywidualnie ocenia użyteczność. Zdaje się, że według definicji OMG, UC nie musi mieć wartości dla jednego wybranego użytkownika, a może mieć dla innych użytkowników systemu. Możliwe, że jednak nadinterpretuję tę definicję?

2. Krawędź między aktorem A a przypadkiem użycia PU jednoznacznie wyraża fakt ‘A ma prawo wywołać PU’. Diagram UC nie posiada elementu ‘pod warunkiem, że ’ i nie należy takiego ‘symulować’.

Nie rozumiem tej uwagi 'pod warunkiem, że'? Chodzi Ci o elementy, które mogą pojawić się na diagramie UC i <<include>> traktujesz to jako 'pod warunkiem, że'? Czy odnosisz się do realizacji UC?

Za OMG UML Superstructure "A use case can include possible variations of its basic behavior, including exceptional behavior and error handling."

3. Aktor to użytkownik po weryfikacji uprawnień (skąd wiadomo, że dany użytkownik jest tym a nie innym aktorem).
Może jest poprawne ale ... mi się nie podoba. :)

Właśnie pkt. 3 jest argumentem, który do mnie przemawia. Wcześniej źle rozumiałem, to że aktorzy modeluje różne aspekty jakiegoś bytu ("entity"), a że byt ma unikalną tożsamość ("identity"), to można tę tożsamość wykorzystać w UC. Wygląda jednak, że to dopiero występuje w realizacji UC.

Nie chodziło mi o wrażenia estetyczne, tylko o o konkretną odpowiedź, jest źle, bo <...> ;-)

@Jakubie: jak modelujesz wymagania pozafunkcjonalne?

Czy to pytanie o notację jaką stosuję przy tworzeniu ‘dokumentacji’ ?

Tak, ale tylko do wymagań pozafunkcjonalnych. Opis słowno-muzyczny? Może diagramy? A może inne rozwiązanie?

Pytanie autora postu dotyczyło tego jak na diagramie UC modelować kwestie związane z bezpieczeństwem. Spotkałem się tylko z opisem słowno-muzycznym.
Nie wiem czy to dobry pomysł, żeby przedstawiać takie wymagania na diagramach.

-- Edited: formatowaniePaweł Grzegorz Kwiatkowski edytował(a) ten post dnia 04.10.11 o godzinie 10:14

Temat: Dynamiczne role w przypadkach użycia

Można podejść do całości tak - możliwości to interfejs, np:

interface Fakturowanie {

    wystawFakture(tresc);

}



interface Magazynowanie {

    przyjmijDoMagazynu(produkt)

}

...

Użytkownik implementując interfejs nabywa uprawnienia do wykonania jakiejś operacji.

class WszystkoRobiącyPracownik extends Użytkownik implements Fakturowanie, Magazynowanie{

}

Zgodnie z takim rozumowaniem, można przedstawić modelowanie systemu kontroli dostępu za pomocą diagramu klas.Wojciech Soczyński edytował(a) ten post dnia 04.10.11 o godzinie 16:14

Temat: Dynamiczne role w przypadkach użycia

Teraz pytanie - co użytecznego daje użytkownikowi weryfikacja ?

To jest jakiś argument, jednak:
* definicja za OMG UML Superstructure V2.1.2, "A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system." częściowo pokrywa sie z definicją przytoczoną przez Ciebie.

* "użyteczność" to znowu pojęcie, które ma różne znaczenie dla różnych użytkowników, właściwie każdy użytkownik indywidualnie ocenia użyteczność. Zdaje się, że według definicji OMG, UC nie musi mieć wartości dla jednego wybranego użytkownika, a może mieć dla innych użytkowników systemu. Możliwe, że jednak nadinterpretuję tę definicję?

...

2. Krawędź między aktorem A a przypadkiem użycia PU jednoznacznie wyraża fakt ‘A ma prawo wywołać PU’. Diagram UC nie posiada elementu ‘pod warunkiem, że ’ i nie należy takiego ‘symulować’.

Nie rozumiem tej uwagi 'pod warunkiem, że'? Chodzi Ci o elementy, które mogą pojawić się na diagramie UC i <<include>> traktujesz to jako 'pod warunkiem, że'?

Tak.

Przecież "administrator niezweryfikowany" nie może np. 'dodać użytkownika', prawda ? Z drugiej strony - administrator niezweryfikowany to wciąż administrator i z diagramu wynika, że użytkownika dodać może.

Za OMG UML Superstructure "A use case can include possible variations of its basic behavior, including exceptional behavior and error handling."

Zgadza się, ale rozmawiamy o relacjach między przypadkami użycia (informacje zawarte na UML UC diagram) a nie o samych przypadkach użycia.

3. Aktor to użytkownik po weryfikacji uprawnień (skąd wiadomo, że dany użytkownik jest tym a nie innym aktorem).
Może jest poprawne ale ... mi się nie podoba. :)

Właśnie pkt. 3 jest argumentem, który do mnie przemawia. Wcześniej źle rozumiałem, to że aktorzy modeluje różne aspekty jakiegoś bytu ("entity"), a że byt ma unikalną tożsamość ("identity"), to można tę tożsamość wykorzystać w UC. Wygląda jednak, że to dopiero występuje w realizacji UC.

Nie chodziło mi o wrażenia estetyczne, tylko o o konkretną odpowiedź, jest źle, bo <...> ;-)

Syntax jest poprawny. Jak się okazuje, mogą istnieć (są zgodne z definicją) UC które nie są 'bezpośrednio wywoływalne (powiązanie Użytkownik->Weryfikacja nie ma sensu)' przez żadnego aktora.

@Jakubie: jak modelujesz wymagania pozafunkcjonalne?

Czy to pytanie o notację jaką stosuję przy tworzeniu ‘dokumentacji’ ?

Tak, ale tylko do wymagań pozafunkcjonalnych. Opis słowno-muzyczny? Może diagramy? A może inne rozwiązanie?

Projektuje tak architekturę systemu, żeby analiza sposobu jego działania (i rozszerzanie owego) była dla programisty czymś łatwym i przyjemnym.
Kod (a raczej jego organizacja) ma być tak oczywisty jak 'cios w nos'.

Diagramy UML (klas i flow) stosuję tylko w celach 'ilustracyjnych'. Mają doskonałe właściwości 'uspakajające' i jest na nie moda więc nie mam wyjścia.

Pytanie autora postu dotyczyło tego jak na diagramie UC modelować kwestie związane z bezpieczeństwem.

... chodziło o 'dynamiczne role' :)

Spotkałem się
tylko z opisem słowno-muzycznym.

I nie jest to przypadek.

Nie wiem czy to dobry pomysł, żeby przedstawiać takie wymagania na diagramach.

Diagramy UC .... najprawdopodobniej ... nie nadają się do tego :)Jakub Wojt edytował(a) ten post dnia 04.10.11 o godzinie 22:43

Temat: Dynamiczne role w przypadkach użycia

Widocznie, źle zrozumiałem znaczenie pojęcia "dynamiczna rola", wprowadzonego przez autora pytania ;-) Myślałem, że chodzi mu o zapewnienie możliwości:
- ograniczenie realizacji określonych czynności w systemie do użytkowników posiadających "uprawnienia"
- zdefiniowania "ról" w systemie (rozumianych jako grupy uprawnień)
- przypisania uprawnień do "ról"
- przypisania użytkownikom "ról"

... oraz o to jak modelować UC, tak by powyższe wymagania były uwzględnione na diagramie.

A co z wprowadzeniem stereotypu np. <<contains_security_check>>, który rozszerzałby diagram UC ? Czy takie rozwiązanie jest poprawne? Czy budzi wątpliwości?

Temat: Dynamiczne role w przypadkach użycia

A co z wprowadzeniem stereotypu np. <<contains_security_check>>, który rozszerzałby diagram UC ? Czy takie rozwiązanie jest poprawne? Czy budzi wątpliwości?

kombinowanie ... ;)

Temat: Dynamiczne role w przypadkach użycia

Jakub, Paweł - dzięki za dyskusje. Sledze na bieżąco :-)

Aktorem w takim przypadku "weryfikacja uprawnień" mógłby być zewnętrzny
system (np. jakiś mechanizm globalnego zarządzania uprawnieniami w
przedsiębiorstwie) i fragment diagramu UC mógłby w ascii [s]art[/s]
wyglądać tak:

>

User--<UC_biznesowy>--<<includes>>--<UC_weryfikacja_uprawnien>--SecuritySystem

W międzyczasie podobnie zamierzałem zrobić. Dyskusja potoczyła się dalej i bardzo przemawia do mnie to:

Krawędź między aktorem A a przypadkiem użycia PU jednoznacznie wyraża fakt > ‘A ma prawo wywołać PU’. Diagram UC nie posiada elementu ‘pod warunkiem, że > ’ i nie należy takiego ‘symulować’.

Alczkolwiek Pawle, Twoje domysły:

Myślałem, że chodzi mu o zapewnienie możliwości:
- ograniczenie realizacji określonych czynności w systemie do użytkowników > posiadających "uprawnienia"
- zdefiniowania "ról" w systemie (rozumianych jako grupy uprawnień)
- przypisania uprawnień do "ról"
- przypisania użytkownikom "ról"

są jak najbardziej słuszne. Takie coś chciałem opracować. Rozumiem po Waszych postach, aby pominąć wspomniane wcześniej "pod warunkiem, że".
Planuję wobec tego stworzyć jednego aktora User, a same przypadki użycia bardziej uogólnić /głownie dla czytelności diagramów/.

Oczywiście - jeśli ktoś ma coś do dodania - dyskusja nadal jest otwarta! :-) Chętnie poczytam dalej Wasze wypowiedzi.Łukasz L. edytował(a) ten post dnia 06.10.11 o godzinie 21:49

Temat: Dynamiczne role w przypadkach użycia

Dla zainteresowanych - propozycję modelowania wymagań pozafunkcjonalnych, można znaleźć w publikacji "Integrating FRs and NFRs: A Use Case and Goal Driven Approach" - Suppakul Sam, Chung Lawrence.

Temat: Dynamiczne role w przypadkach użycia

Załóżmy, że realizujemy przypadek w jakimś systemie finansowym, np - "autoryzuj transakcję". Przypadek ten jest realizowany przez aktora "główny księgowy". Ale nie jest powiedziane, że to ta rola musi realizować taki przypadek, nie jest powiedziane, że taka rola musi w ogóle istnieć w systemie. System umożliwia definiowanie ról i przypisywanie im odpowiedzialności za realizację przypadków już w momencie działania systemu (na przykład uprawnieniami do realizacji jakiś procesów biznesowych). I tak w trakcie działania systemu przypadek (proces biznesowy) możemy przypisać zarówno głównemu księgowymi, ale również np. "sekretarce" - wolna wola. Rola "główny księgowy nie musi istnieć w systemie.

przede wszystkim starał bym się zrozumieć jak to się odbywa w rzeczywistości, bo:
- istnieje jakaś reguła trzeba ją tylko odkryć
- nie ma reguły i trzeba pozostawić to ludziom (użytkownikom)

przypadek drugi świadczy o bałaganie w organizacji ale nie musi oznaczać braku możliwości implementacji :)

Jak opisać przypadek "autoryzuj transakcję"? Jak go przedstawić na UCD? Myślałem, nad oznaczeniem aktora "główny księgowy" jako aktora abstrakcyjnego, ale w sieci zetknąłem się z opiniami, że takowi aktorzy owszem istnieją, ale z nich wywodzą się konkretni aktorzy (w opisywalnym systemie takowych nie znamy). W literaturze, która posiadam nie ma nawet wzmianki o takich aktorach.

jeżeli potraktować przypadki użycia jako konkretne działania to nie wróżę sukcesu, jeżeli traktować przypadki użycia jak usługi systemu to taka logika będzie się poddawała implementacji.

Przykład: mamy skrzynkę narzędziową (system) i narzędzia (usługi systemu - przypadki użycia), i teraz: mam młotek, ma on konkretne operacje - w szczególności "uderz w (parametr)" (zakładam, że usługę implementuje jakaś klasa wykonawcza i scenariusze z nią powiązane polecam wzorzec strategii), w tym momencie mam dwa wyjścia:
- młotek mam prawo wydać tylko uprawnionym osobom ale nie panuje nad co z nim robią, nie mogę zablokować nikomu operacji uderz a kontrola parametru 9w co walnie) jest raczej trudna,
- daje młotek każdemu ale ściśle nadzoruje kto co robi (skutki), poza systemem mam władze w postaci "dam Ci po premii" itp...

próby algorytmizacji pracy ludzi moim zdaniem to czas stracony...

Tak więc nie ma "dynamicznych aktorów". aktorem jest kto się dorwie do młotka... możemy tym zarządzać w systemie lub poza nim ...Jarek Żeliński edytował(a) ten post dnia 07.10.11 o godzinie 12:07

Temat: Dynamiczne role w przypadkach użycia

Myślę, że pytanie można przeformułować do "Jak modelować wymagania pozafunkcjonalne".

Jako ograniczenia systemu...

Temat: Dynamiczne role w przypadkach użycia

Podczas naszego researchu frameworku BPMS na żywym organiźmie firmy, doświadczamy następujących zjawisk:
1) uprawnienie w ramach danego procesu modelujemy na stanowiska które w teorii mogą wykonywać dany proces (związany zawsze z dostępem do danych), jedynie dodatkowo flagujemy te, które mają i te które nie mają się pojawiać w ocenie okresowej (zatem to sobie funkcjonuje po stronie silnika procesów)
2) jeżeli ktoś chce coś wykonać, czego nie może, to jest to sygnał do aktualizacji systemu i dopisania kolejnego użytkownika do istniejącej roli lub jest to zadanie dla przemodelowania ról.

Temat: Dynamiczne role w przypadkach użycia

Arkadiusz B.:
Podczas naszego researchu frameworku BPMS na żywym organiźmie firmy, doświadczamy następujących zjawisk:
1) uprawnienie w ramach danego procesu modelujemy na stanowiska które w teorii mogą wykonywać dany proces (związany zawsze z dostępem do danych), jedynie dodatkowo flagujemy te, które mają i te które nie mają się pojawiać w ocenie okresowej (zatem to sobie funkcjonuje po stronie silnika procesów)

znacznie 'lepsze" podejście to uprawnienia kontekstowe: prawa do "danych" ma nie osoba a proces (sprawa)

2) jeżeli ktoś chce coś wykonać, czego nie może, to jest to sygnał do aktualizacji systemu i dopisania kolejnego użytkownika do istniejącej roli lub jest to zadanie dla przemodelowania ról.

lub do przemodelowanie struktura organizacyjna firmy... ;)