2. Tehnička dokumentacija

2.1. Specifikacija zahtjeva

Specifikacija zahtjeva je izrađena na osnovu zahtjeva naručitelja, prikupljene dokumentacije, te analize slučajeva korištenja.

2.1.1. Softverski zahtjevi

2.1.1.1. Opis

Specifikaciju softverskih zahtjeva u projektu ćemo opisati koristeći IEEE Std 830-1998 standard (Software Requirements Specifications). Ovaj standard opisuje kako bi se programski sustavi trebali razvijati. Specifikacija softverskih zahtijeva predstavlja temelj uspješnog dogovora proizvođača i kupca oko toga kako će programski proizvod izgledati. Također, specifikacija softverskih zahtjeva predstavlja realistične temelje, pomoću kojih možemo procijeniti troškove proizvodnje, rizike poslovanja te sam raspored aktivnosti potrebnih za provedbu projekta. Glavni cilj ove metode je reduciranje kasnijeg redizajna aplikacije te smanjenje vjerojatnosti provedbe neuspješnog projekta. Svrha ove metode je opis funkcijskih i nefunkcijskih zahtjeva, uključujući i slučajeve korištenja koji opisuju koje funkcionalnosti softver mora omogućiti kako bi korisnik ostvario kvalitetnu interakciju s aplikacijom.

2.1.1.2. Opseg

Namjena aplikacije za prodaju lijekova je modernizacija poslovanja apoteka. Aplikacija će pojednostaviti nabavu i praćenje zaliha te bolje povezati ljekarne s liječnicima (nema više papirnatih recepata). Uz to, aplikacija će podržavati široku bazu kupaca u koju će bilježiti njihove podatke. Također, aplikacija će podržavati različite konfiguracije, ovisno o tome tko se ulogirao u nju: registrirani korisnik (admin, zaposlenik, korisnik) i neregistrirani korisnik.

2.1.1.3. Konfiguracije

• Administrator: vlasnik aplikacije
• Zaposlenik: zaposlenik ljekarne
• Korisnik: registrirani korisnik aplikacije
• Neregistrirani korisnik: korisnik koji nije registriran u aplikaciju.

Referenca: IEEE Software Engineering Standards Committee, „IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications”, 1998.

Petra Banić

2.1.2. Tehnologije i oprema

Tehnologije i oprema koju smo koristili prilikom izrade projekta navedena je u sljedećoj tablici:

Naziv alata	Primjena
Microsoft Visual Studio	Izrada koda
Microsoft Project	Project Management
GitHub	Repozitorij koda
DataGrip	Izrada baze podataka
Microsoft Office	Izrada dokumentacije
Visual Paradigm	Izrada ER modela

Marija Arki

2.1.3. Slučajevi korištenja

Slučajevi korištenja služe opisu funkcionalnosti sustava kroz interakciju korisnika sa sustavom. Dijagrami slučajeva korištenja i njihovi detaljni opisi nalaze se u poglavlju 2.2.2. ove stranice.

2.1.4. Funkcionalni zahtjevi

Funkcionalni zahtjevi opisuju što bi aplikacija trebala raditi. Funkcionalni zahtjevi našeg projekta su izvedeni iz zahtjeva naručitelja:

• Registracija i prijava
• Kreiranje, izdavanje, pregled i storniranje računa
• Izrada loyalty opcija i loyalty kartica
• Unos, ažuriranje i brisanje podataka o: lijekovima, zaposlenicima, dobavljačima, loyalty karticama i loyalty opcijama
• Prodaja aplikacije različitim tvrtkama - kreiranje master administrativnog računa
• Kreiranje apoteke i upravljanje ostalim podacima tvrtke
• Rezervacija lijekova
• Nabava lijekova
• Izvješća o kupcima, lijekovima, prometu i slično
• Obavijest - e-mail podsjetnici klijentima o svim rezervacijama lijekova koji su stigli toga dana
• Analiza - sustav svako jutro automatski šalje mail s popisom lijekova kojih će nestati na zalihama u sljedećih N dana

Detaljnije opise funkcionalnosti možete pronaći u poglavlju 1.3. na stranici Projektna dokumentacija.

Petra Banić

2.1.5. Nefunkcionalni zahtjevi

Nefunkcionalni zahtjevi za razliku od funkcionalnih ne opisuju što će aplikacija raditi, već kakva će biti. To su uglavnom oni zahtjevi koji se tiču same aplikacije, a nemaju veze sa samom svrhom njezine izrade.

• Aplikacija će imati mehanizam za prijavu korisnika u sustav, odnosno mehanizme autentifikacije i autorizacije.
• Aplikacija će podržavati višekorisnički rad.
• Aplikacija bi trebala sadržavati upute za rad za sve konfiguracije.

Marija Arki

2.2. Opis dizajna sustava

2.2.1. Model baze podataka

U nastavku će biti prikazani ER dijagram i UML dijagram koji nam daju detaljan uvid u to kako ćemo implementirati našu aplikaciju.

2.2.1.1. ER dijagram

ER dijagram nam služi kako bi detaljno prikazali kao će izgledati struktura baze podataka koju ćemo koristiti prilikom izrade same aplikacije.

Erik Baukovac

2.2.1.2. UML dijagram

UML dijagram odnosno dijagram klasa prikazuje nam postojanje klasa i njihov međuodnos prilikom logičkog oblikovanja sustava.

Erik Baukovac

2.2.2. Rad s aplikacijom

2.2.2.1. Registracija i prijava

Registracija - korisnik se želi registrirati kako bi se mogao prijaviti i pristupiti aplikaciji.

Sudionik: Neregistrirani korisnik
Preduvjeti: Korisnik ne posjeduje korisnički račun

Glavni scenarij za registraciju:

1. Korisnik otvara formu Registracija
2. Unosi podatke za registraciju
3. Pritišće gumb registracija ili odustani, zavisno od toga što želi učiniti (provesti registraciju ili ne)
4. Ako je korisnik unio točne podatke (provjerava se posjeduje li korisnik račun) u tablicu Korisnik spremaju se uneseni podaci - korisnik je unesen u bazu registriranih korisnika.
5. Ako je registracija bila uspješna, korisniku se prikazuje poruka o uspješnoj registraciji
6. Ako je korisnik unio pogrešne podatke ili posjeduje korisnički račun, odmah mu se prikazuje poruka o pogrešnom unosu i uneseni podaci se nigdje ne spremaju

Prijava - korisnik se želi prijaviti kako bi mogao pristupiti aplikaciji.

Sudionik: Registrirani korisnik (administrator, korisnik, zaposlenik)
Preduvjeti: Korisnik posjeduje korisnički račun

Glavni scenarij za prijavu:

1. Korisnik otvara formu Prijava
2. Unosi podatke za prijavu
3. Pritišće gumb prijava
4. Ako je korisnik unio točne podatke (provjerava se posjeduje li korisnički račun) korisniku je dopušten pristup u aplikaciju te mu se prikazuje poruka o uspješnoj prijavi
5. Ako je korisnik unio pogrešne podatke ili ne posjeduje korisnički račun, odmah mu se prikazuje poruka o pogrešnom unosu

Petra Banić

2.2.2.2. Loyalty opcije i loyalty kartice

Ovo poglavlje opisuje rad aplikacije s loyalty opcijama i karticama kroz dijagrame aktivnosti i dijagrame slučajeva korištenja.

Izrada Loyalty opcije

Ažuriranje i brisanje Loyalty opcije

Izrada Loyalty kartice

Ažuriranje i brisanje Loyalty kartice

Petra Banić

2.2.2.3. Rad s lijekovima

Ovo poglavlje opisuje rad aplikacije s lijekovima kroz dijagrame slijeda i slučajeve korištenja.

Unos novih lijekova

Ažuriranje podataka o lijekovima

Brisanje lijekova

Rezervacija lijekova

Nabava lijekova

Erik Baukovac

2.2.2.4. Rad sa strankama

Ovo poglavlje opisuje rad aplikacije sa strankama kroz dijagrame slijeda i slučajeve korištenja.

Unos novih dobavljača

Ažuriranje podataka o dobavljačima

Brisanje dobavljača

Erik Baukovac

2.2.2.5. Rad sa zaposlenicima

Ovo poglavlje opisuje rad aplikacije sa zaposelnicima kroz dijagrame slijeda i slučajeve korištenja.

Unos novih zaposlenika

Ažuriranje podataka o zaposlenicima

Brisanje zaposlenika

Erik Baukovac

2.2.2.6. Rad administratora

Administrator ima mogućnosti kreiranja apoteke, upravljanja podacima te pristupanja izvješću. Ukoliko odabere kreiranje apoteke, aplikacija će izvršiti provjeravanje postojanja te iste apoteke. Ako apoteka koja se želi kreirati već postoji u bazi, prikazat će se obavijest o tome. Ako apoteka ne postoji, aplikacija ažurira promjenu podataka ukoliko je korisnik pritisnuo tipku spremi. Ukoliko administrator upravlja nekim podacima, bilo da su to podaci zaposlenika, loyalti pogodnostima ili apoteke, tada se promjena ažurira ako je unesene podatke spremio.

Kreiranje apoteke i upravljanje ostalim podacima tvrtke

Marija Arki

2.2.2.7. Rad zaposlenika

Zaposlenik ima mogućnosti izdavanja, storniranja i pregledavanja računa te pristupanja izvješću. Ukoliko izdaje račun, aplikacija će izvršiti kreiranje računa, a podaci će se ažurirati u bazi. Također, podaci u bazi će se ažurirati ukoliko odabere storniranje računa. Ukoliko zaposlenik odabere pregled računa, iz baze podataka aplikacija povuče unesene podatke.

Kreiranje, izdavanje, pregled i storniranje računa

Marija Arki

2.2.2.8. Pristup izvješću

Posljednja akcija koju administrator i zaposlenik mogu poduzeti je pristupanje izvješću. Tada aplikacija generira odabrano izvješće iz baze podataka.

Marija Arki

2.3. Dizajn funkcionalnosti

Dizajn funkcionalnosti je proces koji odgovara na potrebe i želje korisnika aplikacije. Funkcionalni dizajn je proces a u isto vrijeme i rezultat. Kao rezultat, opisuje proizvode koji djeluju u sinergiji kako bi ostvarili dodijeljene zadatke. Kao proces dizajn funkcionalnosti sastoji se od pravila iz kojih proizlaze pozitivni rezultati. Kako bi dizajn što više približili potrebama korisnika, pokušali smo implementirati što jednostavniji dizajn.

Petra Banić

2.3. Upute za podešavanje razvojne i produkcijske okoline

Uloga	Korisničko ime	Lozinka
Administrator	pbanic	P3tra123
Zaposlenik	erikbau	Erik1234
Korisnik	petrabanic	Petra33

Petra Banić