See on õige, et kliendid võiksid saada teenuse tarbimiseks aja kinni panna (teenuse broneerida). Infosüsteemi kui terviku seisukohalt on see vajalik funktsionaalsus.

Mõelge sellele, millised oleksid võimalikud broneerimisega seotud kasutusjuhud.

• Broneeri teenus (Klient)
• Vaata oma broneeringuid (Klient)
• Tühista oma broneering (Klient)
• Broneeri teenus (Broneeringute haldur) (võib registreerida mistahes kliendi broneeringu)
• Vaata kõiki broneeringuid (Broneeringute haldur) (võib vaadata mistahes kliendi broneeringut)
• Tühista broneering (Broneeringute haldur) (võib tühistada mistahes kliendi broneeringu)
• Teavita broneeringuga kliente (Broneeringute haldur) (erakorralise teate saatmine ühele või mitmele kliendile)
• Vaata broneeringute kokkuvõtet (Juhataja)
• ...

Nagu näete, siis kasutusjuhte on palju. Küsimus on, millise funktsionaalse allsüsteemi alla need koondada. Kui "Teenuste funktsionaalse allsüsteemi" alla, siis selle kasutusjuhtude arv vähemalt kahekordistuks ja see allsüsteem kasvaks liiga suureks.

Miks see on halb? Samal põhjusel miks liiga suure meetodite arvuga klassi tegemine (tuntakse nime all "plekk" või "jumal-klass"). Sellisest allsüsteemist oleks raskem aru saada, seda oleks raskem arendada ja arenduse tulemusi taaskasutada. Seetõttu oleks õige paigutada eelnimetatud kasutusjuhud "Broneeringute funktsionaalse allsüsteemi" alla (vastab põhiobjektile Broneering). Seda allsüsteemi Te projektis detailselt ei käsitle. Seega pole ka vaja vastavaid kasutusjuhte kirja panna.