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

Во 3.2 табелата да стои само која е улогата на тие stakeholders во развивањето на системот, пр. какви податоци им требаат за пациентите (за да се знае каков изглед му треба на документот).
Во табелите 3.2 и 3.3 треба да има исти stakeholders.
Да не пишуваме „корисници“ - кои корисници? Може да ги наречеме пациенти, посебно доктори итн.
Во 3.5 и 3.6 посебен детален профил за секој корисник и stakeholder, use cases не детално опишани. Треба да бидат опфатени сите засегнати страни од системот, дури и оние кои не се директни корисници на системот (пр. хигиеничари кои добиваат распоред за чистење на соби според некоја пресметка што ќе ја прави системот).
Треба да се направи операциска анализа, за неа се потребни детални чекори од сите кориснички сценарија.
Во 3.6 Листа на потреби на секој корисник, тука use cases детално опишани - на кој што и зошто му треба
Во 3.7 главни проблеми - потреби кои се и секако за сите тие потреби да се наведат решенија...
Во 3.8 да се објасни што имаат конкурентските софтвери и како сме ние подобри.
Во 4.1, а и никаде на друго место да не наведуваме модули. Потребно е до модулите да дојдеме преку оваа анализа.
Во 4.2 Конкретни барања од корисничките профили, Capabilities што кој ќе добие, пр. на корисниците им треба да работи системот во одреден момент не им треба 24/7, или др. пр. пациент има закажан термин и тој треба да е резервиран за него (да се чува), решението на ова ќе биде софтверот да ограничува нови закажувања. Всушност, од сите овие customer benefits ќе произлезат use cases.
Во корисничките сценарија: во 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, бидејќи сѐ правиме за тие конкретни проблеми.