Nimeta tegutseja rollinimega c. Joonista Süsteemi kasutajate funktsionaalsetele eesmärkidele vastavad (põhi)kasutusjuhud Süsteemi ristküliku sisse d. Joonista kommunikatsiooniseosed tegutsejate ja kasutusjuhtude vahele (kui tegutseja osaleb kasutusjuhus aktiivselt (käivitajana) või passiivselt (info saajana)) e. Kirjelda põhikasutusjuhud (tekstiga ja/või teist tüüpi UML käitumisdiagrammiga) f. Vajadusel lisa alamkasutusjuhud ja extend/include seosed. Milline on praktiku jaoks kasulik skoop tarkvara kasutusjuhu jaoks? Millistele tingimustele tarkvara põhikasutusjuht peaks vastama? Tegutseja funktsionaalsele eesmärgile vastav põhikasutusjuht on "elementaarne äriprotsess" ehk Tegevus ning (potentsiaalselt iseseisev) "tarkvaraseanss". Inimene käivitab tarkvara eesmärgiga konkreetset kasutusjuhtu teha. Kuidas mudelid mõjutavad töötavat tarkvararakendust? Muudame mudelit (vt
● Ta ei kesta päevi, ega hõlma paljusid seansse nagu “hankelepingu läbirääkimised”. Ta on ülesanne, mis täidetakse ühe seansiga ning kestab mõned minutid kuni tund ● Viib süsteemi ja andmed stabiilsesse kooskõlalisse seisundisse, lisades jälgitava või mõõdetava äriväärtuse ● Tavaline viga on paljude use case-ide defineerimine liiga madalal tasemel, nagu EBP üksiks samm, alamfunktsioon, alamülesanne. 8. Alamkasutusjuhud Kuigi rakenduste puhul kasutusjuhud peaks järgima EBPd, siis vahel on ikkagi normaalsem luua eraldi “alam” (haha dom) use case-id, mis esindavad põhilise use case-i alamülesandeid või samme. Näiteks, alamülesannet või laiendust “maksmine krediitkaardiga” võib korrata erinevates põhilistes kasutusjuhtudes. Et ei peaks dubleerima teksti, siis on mõtekam eraldada ta omaette use case-iks (mis ei täida EBP juhtnööri) ning linkida (include seosega) see