Analisi dei Requisiti
L'analisi dei requisiti da noi svolta e riportata all'interno di questa documentazione è frutto di una costante evoluzione e presa di coscienza del problema in esame durante tutte le fasi di progettazione e sviluppo.
Requisiti Funzionali
Per svolgere tale analisi abbiamo dapprima analizzato il testo del progetto, cercando di far emergere dei pilastri qui di seguito elencati, che nella fase di Progettazione troveranno poi concretizzazione negli elementi costituenti il diagramma di dominio.
Ricette
- Si può creare nuova Ricetta in qualsiasi momento.
- Le Ricette devono essere consultabili e fruibili in qualsiasi momento.
- Una Ricetta è l'elemento fondamentale di BrewDay, identificabile attraverso una serie di proprietà fondamentali e composta da una lista di ingredienti.
- È sempre possibile creare una Ricetta, anche se gli ingredienti necessari non sono attualmente disponibili in magazzino.
- Una Ricetta può essere mandata in produzioni.
- Non è mai possibile cancellare una Ricetta a cui sono associate delle produzioni.
- Non è possibile modificare l’elenco ingredienti di una Ricetta a cui sono associate delle produzioni (terminate o meno), perché altrimenti il birraio perderebbe traccia dello “storico” di quanto è stato prodotto.
Versioni Ricette
- Una ricetta può avere più Versioni. Questo è utile perché se si modifica una certa ricetta, è importante che le produzioni già effettuate di tale ricetta non perdano traccia degli ingredienti originali che erano stati utilizzati per farle.
- Il concetto di Versione è in tutto e per tutto simile a quello di v ma strettamente collegata alla propria ricetta padre.
- Ogni Versione è identificata oltre che dal proprio nome, anche da quello della propria ricetta padre, ossia quella da cui è stata creata.
Ingredienti
- Per Ingrediente si intende un elemento che può comporre una ricetta, suddivisi nel nostro caso in Malti, Luppoli, Lieviti e Additivi.
- Gli Ingredienti sono associati ad una disponibilità, legata al concetto di "possesso" nel magazzino e alla data di scadenza dell'Ingrediente posseduto.
- Un Ingrediente non disponibile in magazzino non può essere utilizzato per una produzione.
- La disponibilità degli Ingredienti dev'essere costantemente monitorata. Verrà scalata la quantità in proprio possesso a ogni lancio di produzione e giornalmente bisognerà controllare gli Ingredienti in scadenza per notificare l'utente della necessità di comprarne di nuovi.
Strumentazione
- Per Strumento si intende l’elemento fisico che il birraio deve utilizzare per poter effettuare una produzione e quindi iniziare la preparazione e fermentazione di una ricetta. Sono soggetti ad una capienza massima e sono di tre tipi: bollitori, fermentatori e tubi.
- Gli Strumenti sono ad una disponibilità, legata al concetto di "possesso" nel magazzino e all'attuale condizione di "occupato", nel caso in cui essi siano attualmente utilizzati per una produzione in corso.
- Uno Strumento è impiegato in una sola produzione alla volta (non è condivisibile).
- Uno Strumento non può essere utilizzato per una produzione per cui si tenta di produrre una quantità di birra superiore alla capienza effettiva per cui è predisposto lo Strumento.
Produzioni
- Il concetto di Produzione indica che una determinata ricetta è al momento in fase di preparazione e fermentazione.
- In realtà ogni Produzione non è associata direttamente con una ricetta, bensì con una delle sue versioni. Una Produzione può essere lanciata dal birraio in qualsiasi momento, a patto che si abbiano gli ingredienti necessari a produrre tale ricetta (versione) e la strumentazione necessaria a farlo.
- Non v'è limite al numero di Produzioni attive contemporaneamente, purché queste rispettino ingredienti e strumentazione a disposizione.
- Al lancio di una Produzione: gli ingredienti necessari vengono immediatamente scalati da quelli presenti in magazzino; la strumentazione usata viene associata a tale Produzione affinché siano riconducibili allo stato Occupato.
- Per ogni Produzione è prevista una data di fine, stimata automaticamente dal sistema sulla base della durata di fermentazione indicata nella ricetta (versione), ma modificabile dal Birrario.
- É possibile produrre una qualsiasi ricetta, senza alcun vincolo sugli Ingredienti di cui essa è composta (potenzialmente può essere vuota). Questa scelta è stata fatta per consentire a BrewDay di non gestire solamente produzioni con metodologie All Grain ed E+G, ma anche Kit.
- Una Produzione andrà sempre e comunque "fermata" manualmente da parte del birraio, che potrà decidere di interromperla in qualsiasi momento.
- A Produzione avviata, gli ingredienti della ricetta (versione) associata non potranno più essere modificati. Sarà possibile creare una versione della Ricetta, clonandola e rendendola quindi modificabile dall’utente.
- Una Produzione in corso può essere consultata e vi si possono appuntare delle osservazioni/note.
What Should I Brew Today?
É la funzionalità più complessa di BrewDay, che abbiamo deciso di lasciare per ultima. Quando il Birraio lo richiede, il sistema deve automaticamente proporre all'utente la Ricetta da produrre nel giorno odierno, sulla base degli Ingredienti presenti in magazzino e degli Strumenti a propria disposizione. Lo scopo è quello di limitare gli sprechi di Ingredienti (basandosi sulla scadenza), massimizzando la quantità di Birra da produrre.
Sarà l'ultima funzionalità che implementeremo, a causa della complessità del suo algoritmo.
Requisiti Non Funzionali
Dall'analisi del progetto non sono emerse particolari disposizioni relative ai requisiti non funzionali che il software avrebbe dovuto soddisfare. Pertanto ci siamo permessi di rifarci semplicemente a requisiti standard di progettazione e sviluppo software:
- Il software deve essere pronto per il 4 Febbraio
- Tutti i membri del team devono avere piena comprensione di (quasi) ogni singola parte del progetto a livello implementativo
- L'interfaccia utente deve essere assolutamente user-friendly
- L'interfaccia utente deve essere adattabile per schermi di diverse dimensioni
- L'applicazione deve rispondere alle richieste in tempi accettabili
- L'applicazione deve gestire correttamente gli errori senza andare in crash e presentare chiaramente all'utente il motivo per cui si è verificato un errore
- L'applicazione deve poter essere scalata in dimensioni e funzionalità
- L'applicazione deve essere facilmente mantenibile
- Il codice sorgente deve essere di facile lettura
- Il codice sorgente non deve presentare troppe duplicazioni
- Il codice sorgente dovrebbe poter essere riutilizzabile
- Il codice sorgente non deve presentare bug o troppi code smell