當開發者想象中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到“客戶總是對的”的陷阱中去，對他們百依百順�，F實中，客戶并不總是對的�？蛻艨偸浅钟凶约旱挠^點，開發者必須理解并尊重這一觀點。人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上采集信息，然后由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。
用例圖適于表達交互，之所以上面使用了電信系統，是因為用例最早來自于Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson 初步建立了用例圖的概念，并于1994 年提出了 OOSE方法，其最大特點是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的用于對功能進行描述。每個用例代表了系統與外部ACTOR的交互�？梢圆扇№樞驁D來表達用例的具體操作程序。ACTOR用于確定系統的邊界。
ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：