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

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

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