| | 1 | |
| | 2 | == Име == |
| | 3 | |
| | 4 | ''Кратко име на use-case-от.'' |
| | 5 | |
| | 6 | |
| | 7 | == Актери == |
| | 8 | |
| | 9 | ''Имиња на улогите на лицата или надворешните системи кои го извршуваат use-case-от.'' |
| | 10 | |
| | 11 | |
| | 12 | == Контекст == |
| | 13 | |
| | 14 | ''Опис на моменталната состојба на системот и актерот и краток опис на use-case-от.'' |
| | 15 | |
| | 16 | |
| | 17 | == Ниво == |
| | 18 | |
| | 19 | ''Дали use-case-от е од ниво на преглед (summary), јадро (core) или поддршка (supporting)?'' |
| | 20 | |
| | 21 | == Предуслови == |
| | 22 | |
| | 23 | ''Значајни делови од системот кои мора да бидат исполнети. Се изразуваат како клучни концепти или состојби.'' |
| | 24 | |
| | 25 | == Постуслови == |
| | 26 | |
| | 27 | ''Промени во системот кои ќе влијаат на идните одзиви на системот како резултат на успешното извршување на use-case-от. Се изразуваат како клучни концепти или состојби.'' |
| | 28 | |
| | 29 | == Бизнис правила == |
| | 30 | |
| | 31 | ''Правила кои важат во реалното изведување на процесот (независно од апликацијата која ќе го имплементира use-case-от), кои важат цело време и кои системот мора да ги спроведува.'' |
| | 32 | |
| | 33 | == Апликациски правила == |
| | 34 | |
| | 35 | ''Ограничувања во начинот на однесување на апликацијата.'' |
| | 36 | |
| | 37 | == Сценарио == |
| | 38 | |
| | 39 | ''Листа од редоследни чекори кои доведуваат до исполнување на use-case-от. Под сценарио спаѓаат чекорите при нормалното проектирано извршување.'' |
| | 40 | |
| | 41 | == Алтернативи == |
| | 42 | |
| | 43 | ''Девијации на некој чекор кои се појавуваат заради исклучоци или одлуки направени од страна на системот или актерот. Алтернативата може да биде или варијација или исклучок. Задолжително се наведува чекорот од сценариото на кој се однесува алтернативата.'' |
| | 44 | |
| | 45 | === Варијации === |
| | 46 | |
| | 47 | ''Опционални дејства за чекор кои се нормални варијации (не се грешки).'' |
| | 48 | |
| | 49 | === Исклучоци === |
| | 50 | |
| | 51 | ''Грешки кои се појавуваат при извршувањето на некој чекор.'' |
| | 52 | |
| | 53 | == Спорни прашања == |
| | 54 | |
| | 55 | ''Прашања кои треба да бидат разрешени, а се однесуваат на use-case-oт.''[[BR]] |
| | 56 | Забелешка: Бидејќи проектот се дефинира од самите аналитичари (студентите кои го прават дизајнот), спорни прашања нема да има. |
| | 57 | |
| | 58 | == Забелешки за дизајнот == |
| | 59 | |
| | 60 | ''Одлуки за дизајнот кои се појавуваат при опишувањето на употребата.''[[BR]] |
| | 61 | Забелешка: Нема да се употребуваат, бидејќи дизајнот на апликацијата не е предмет на овој курс. |
| | 62 | |
| | 63 | == Екрани == |
| | 64 | |
| | 65 | ''Референци кон прозорци или web страници кои ќе бидат прикажувани при извршувањето на овој use-case.''[[BR]] |
| | 66 | Забелешка: Ќе се користи за референци кон прозорците на SugarCRM кои се соодветни на опишуваниот use-case. |
| | 67 | |
| | 68 | == Приоритет == |
| | 69 | |
| | 70 | ''Колку е важен use-case-oт?''[[BR]] |
| | 71 | Забелешка: Бидејќи нема реални ограничувања при имплементацијата на проектот, сите use-case-и ќе бидат од еднаква важност, па приоритетот нема да биде наведуван. |
| | 72 | |
| | 73 | == Фреквенција == |
| | 74 | |
| | 75 | ''Колку често се употребува use-case-от?''[[BR]] |
| | 76 | Забелешка: Бидејќи не постои конкретна организација за која системот се дизајнира, а фреквенцијата е директно зависна од активноста и големината на организацијата, оваа ставка ќе се употребува само таму каде што може да се изрази релативно, према некој друг use-case (пр. 5 пати за секој регистриран проект). |
