Swego czasu pisałem na temat granic systemu i o analizie systemowej (analiza systemowa). Rzecz w tym, że pojęcie "analiza systemowa" jest używane najczęściej (jak obserwuję, prawie zawsze) w znaczeniu analizy i projektowania oprogramowania (systemy IT) co jest błędem.Tak zwane "całościowe myślenie" (holistyczne) to uznanie, że system to nie tylko oprogramowanie. Literatura przedmiotu, praktyka moja i nie tylko, potwierdza jedno: wymagania biznesowe to całościowe spojrzenie na biznes i cele biznesowe, wymagania wobec oprogramowania to dopiero "wymagania wobec rozwiązania" (polecam [[BABoK]] z IIBA). Jakiś czas temu zamówiłem książkę Systems Thinking. Potwierdza, że…
Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu.
UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań.
Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.
