Tehnička dokumentacija - ErikBaukovac/PI-Apoteka GitHub Wiki
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:
- Korisnik otvara formu Registracija
- Unosi podatke za registraciju
- Pritišće gumb registracija ili odustani, zavisno od toga što želi učiniti (provesti registraciju ili ne)
- 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.
- Ako je registracija bila uspješna, korisniku se prikazuje poruka o uspješnoj registraciji
- 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:
- Korisnik otvara formu Prijava
- Unosi podatke za prijavu
- Pritišće gumb prijava
- 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
- 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ć