Забелешки од втората средба на 02.11.2017

Во табелите 3.3 и 3.4 треба да има исти stakeholders.
Да не пишуваме корисници - кои корисници? Може да ги наречеме пациенти, посебно доктори итн.
Во 3.5 и 3.6 посебен детален профил за секој корисник и stakeholder. Треба да бидат опфатени сите засегнати страни од системот, дури и оние кои не се директни корисници на системот (пр. хигиеничари кои добиваат распоред за чистење на соби според некоја пресметка што ќе ја прави системот).
Треба да се направи операциска анализа, за неа се потребни детални чекори од сите кориснички сценарија.
Во 3.6.7 Листа на потреби и во 3.7 решенија на тие потреби да се наведат за сите...
Во 3.8 да се објасни што имаат конкурентските софтвери и како сме ние подобри.
Во 4.1, а и никаде на друго место да не наведуваме модули. Потребно е до модулите да дојдеме преку оваа анализа.
Во 4.2 Capabilities што кој ќе добие, пр. на корисниците им треба да работи системот во одреден момент не им треба 24/7.
Во корисничките сценарија: во Description да ја нема првата реченица за модулот, да нема by clicking и др. имплементациски детали, само кои податоци треба да ги внесе корисникот. Не треба да се гледа замислата за структура, само комуникацијата на луѓето и системот, односно што ќе бара системот како влез и што ќе враќа како одговор.
Глаголот asks да се смени со нешто како sends request или initiates.
За почеток да се направи анализа за 2 кориснички сценарија. Не мора нацртани на лист.
Во опис на архитектура ќе влезат генералните описи на потсистемите, сите можни ИС.

Од претходните забелешки:

1.1. Категорија на решението, што е причина за проектот, во што сме подобри од конкуренцијата...
1.2. Дискусија на проблемот: што е за кого;
2.2. Problem statement: кои корисници какви проблеми имаат (positioning target customer);
3.1. Треба да се вклучи опис на конкурентни производи;
3.2. Опис на сите учесници (stakeholders): да се напишат одговорностите на секој stakeholder, пр. информации за подобрување на средства, за кого би се подобрило нешто или би се влошило...
3.3. Users summary: кој од тие stakeholders е реален корисник во системот и која е неговата функција за системот;
3.4. User environment: каде работат тие корисници, што некој stakeholder ќе ни даде (некој документ);
3.7. Key stakeholder: клучни потреби кои се, кои луѓе...
4.* Решение за задоволување на потребите: тука спаѓа и опис на постоечкиот софтвер (која била замислата тогаш, а кои се новите потреби, функционалности и корисници -> нова визија), врски меѓу потреби и функционалности (пр. за тоа и тоа има таква и таква функционалност - модул), всушност од тука произлегуваат use cases од кои потоа произлегува програмирањето use case по use case, бидејќи сѐ правиме за тие конкретни проблеми.