Stosowanie reguł (seman­ty­ki i syn­tak­ty­ki) UML pozwa­la utrzy­mać spój­ność mode­li zależ­nych (pod­le­głe temu dia­gra­mo­wi uszcze­gó­ło­wie­nia Projektu Systemu, reali­za­cja Aktorów, przy­pad­ki uży­cia itp.) oraz zacho­wać spój­ność logicz­ną i poję­cio­wą całej doku­men­ta­cji. To zaś jest warun­kiem wery­fi­ka­cji popraw­no­ści całe­go projektu. 

UML to nota­cja, któ­rej klu­czo­wym poję­ciem jest kla­sy­fi­ka­tor (opar­ta jest na defi­nio­wa­nych poję­ciach i rela­cjach mię­dzy nimi) dla­te­go war­to prze­strze­gać (zawsze war­to) zasad nota­cji i np. nie utoż­sa­miać Aktora System CRM (jest to jakaś abs­trak­cja sys­te­mu inte­gro­wa­ne­go) z kon­kret­nym Jakimś Systemem CRM. Aktor ma kon­kret­ne zna­cze­nie na dia­gra­mie UML (zde­fi­nio­wa­ne wyżej) i kon­kret­ny sys­tem tak­że. Zachowanie tego podzia­łu (abs­trak­cja i jej reali­za­cja) pozwa­la zde­fi­nio­wać oddziel­nie wyma­ga­nia i oddziel­nie kon­kret­ne roz­wią­za­nia je speł­nia­ją­ce co jest isto­tą roz­dzia­łu wyma­gań od speł­nia­ją­cych je rozwiązań. 

Diagramy przy­pad­ków uży­cia są bar­dzo waż­ny­mi dia­gra­ma­mi, gdyż sta­no­wią ​„korzeń” mode­lu reali­za­cji sys­te­mu zaś łama­nie zasad nota­cji pro­wa­dzi prak­tycz­nie zawsze do utra­ty moż­li­wo­ści ich, mode­li, weryfikacji.