zły model to złe oprogramowanie.... Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią. Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".