Ingegneria del Software -analisi dei requisiti

Requirements analysis document

Progetto SmartWheel

Gestione fabbrica biciclette

NOTA: questo documento è stato trovato in rete ed è gratuitamente distribuito, a scopo didattico, dal sito www.quellidiinformatica.org, Community studenti di Ingegneria Informatica di Napoli.

Progetto SmartWheel Requirements Analysis Document

Sommario

1 Obiettivo generale.............................................................................................................................3

1.1 Definizioni e acronimi..............................................................................................................3

2 Sistema attuale ..................................................................................................................................4

3 Sistema proposto ...............................................................................................................................4

3.1 Vista d’insieme .........................................................................................................................4

3.2 Requisiti funzionali ..................................................................................................................4

3.2.1 Inserimento, modifica e cancellazione ordini clienti. ....................................................5

3.2.2 Composizione e smistamento lotti di produzione. .........................................................5

3.2.3 Scheduling dei lotti di produzione. .................................................................................5

3.2.4 Inserimento, modifica e cancellazione della distinta di produzione. ............................6

3.2.5 Creazione della lista delle parti necessarie per il magazzino. .......................................6

3.2.6 Inventario dei pezzi e creazione delle targhette. ............................................................6

3.3 Requisiti non funzionali ...........................................................................................................6

3.3.1 Interfaccia utente e fattore umano...................................................................................6

3.3.2 Documentazione...............................................................................................................6

3.3.3 Considerazioni sull’hardware..........................................................................................7

3.3.4 Considerazioni sulle prestazioni......................................................................................7

3.3.5 Gestione degli errori e condizioni estreme .....................................................................7

3.3.6 Sicurezza ...........................................................................................................................7

3.4 Pseudo – requisiti......................................................................................................................7

3.5 Modelli del sistema...................................................................................................................7

3.5.1 Scenari...............................................................................................................................7

3.5.2 Modello dei casi d’uso ...................................................................................................12

3.5.3 Modello degli oggetti .....................................................................................................29

3.5.4 Modelli dinamici ............................................................................................................39

3.5.5 Mock-up interfaccia utente ............................................................................................52

RAD pag. 2

http://www.quellidiinformatica.org – Documento trovato in rete

1 Obiettivo generale

L’obiettivo generale del progetto SmartWheel è la creazione di un sistema informatico che snellisca la normale attività produttiva di una fabbrica di biciclette.

1.1 Definizioni e acronimi

Acronimi: Data Base Management System

DBMS Graphical User Interface

GUI Object Design Document

ODD Requirements Analysis Document

RAD System Design Document

SDD Software Project Management Plan

SPMP Unified Modeling Language

UML

Definizioni: Elenco delle parti necessarie per la fabbricazione di un pezzo

Distinta di produzione di un dato modello.

Insieme di ordini tutti per uno stesso modello. E’ caratterizzato da un numero identificativo, un numero totale di pezzi (ricavato dalla somma dei pezzi dei singoli ordini) e dalle date di consegna dei singoli ordini. Può essere: omogeneo, anomalo, in produzione o ultimato.

Lotto di produzione con un numero totale di pezzi compreso tra 50 e 150 e date di consegna degli ordini che non differiscano per più di 15 giorni.

Lotto omogeneo

Lotto il cui numero totale di pezzi non è compreso tra 50 e 150 oppure le cui data di consegna differiscono di più di 15 giorni. L’approvazione per un lotto anomalo può essere data solo dal responsabile di produzione.

Lotto anomalo

Lotto attualmente in lavorazione presso uno stabilimento. Un lotto in produzione non può più essere cancellato.

Lotto in produzione

Lotto la cui lavorazione è stata completata e che è pronto a essere consegnato.

Lotto ultimato

Richiesta da parte di un cliente all’ufficio clienti per un certo numero di biciclette, di un certo modello e per una certa data. Un ordine può essere: proposto, rifiutato, in produzione, ed evaso.

Ordine

Ordine che è stato ricevuto dall’ufficio clienti ma non ancora sottoposto al reparto produzione; a seconda dell’esito può diventare ordine in produzione oppure ordine rifiutato.

Ordine proposto

Ordine che non è stato approvato dal reparto produzione.

Ordine rifiutato

Ordine che appartiene ad un lotto che è stato inviato allo stabilimento di produzione. Un ordine in produzione non può più essere cancellato. Una volta completata la produzione i pezzi vengono inviati al cliente e l’ordine diventa evaso.

Ordine in produzione

Ordine facente parte di un lotto ultimato.

Ordine evaso

Ordine di una data quantità di una singola parte verso un dato fornitore; comprende nome del fornitore, nome e quantità della parte e data di consegna.

Ordine verso fornitore

Materia prima o componente necessaria per la fabbricazione di un pezzo.

Parte

Bicicletta del modello A o B completa di tutte le sue parti. Ogni pezzo viene univocamente identificato dalla sua targhetta.

Pezzo

Etichetta adesiva da applicare su ogni pezzo che lo identifica univocamente e che contiene: codice identificativo dello stabilimento, numero di telaio e dati relativi.

Targhetta

RAD pag. 3

http://www.quellidiinformatica.org – Documento trovato in rete

2 Sistema attuale

Si suppone che non ci sia nessun sistema informatico preesistente e che tutte le attività di archiviazione vengano svolte su supporto cartaceo, che le comunicazioni tra amministrazione e produzione si svolgano via telefono o fax e che le targhette vengano compilate a mano dall’operaio addetto.

3 Sistema proposto

3.1 Vista d’insieme

L’azienda in cui SmartWheel verrà utilizzato è divisa in due settori: amministrazione e produzione; a sua volta il settore produzione è diviso in due stabilimenti separati (Nord e Sud), ciascuno dei quali si occupa di un diverso modello di bicicletta.

Il sistema deve fornire ad ogni operatore una vista d’insieme sulle operazioni a lui possibili in maniera da agevolare le sue decisioni. Il sistema è anche stato pensato per migliorare lo scambio delle informazioni tra i reparti e per fornire un servizio di archiviazione per le attività svolte in precedenza.

3.2 Requisiti funzionali

Il sistema prevede tre postazioni per il settore amministrativo e tre per ogni stabilimento del settore produzione.

I servizi che il sistema offre al settore amministrazione sono:

• Inserimento, modifica e cancellazione degli ordini dei clienti.
• Composizione e smistamento lotti di produzione, con poteri decisionali diversi per l’addetto alla produzione e il responsabile di produzione.

Invece i servizi offerti alla sezione produzione, per ognuno dei due stabilimenti, sono:

• Scheduling dei lotti di produzione.
• Inserimento, modifica e cancellazione della distinta di produzione per un dato modello di bicicletta.
• Creazione della lista delle parti necessarie per integrare le scorte di magazzino.
• Inventario dei pezzi prodotti.
• Creazione delle targhette identificative per ogni pezzo.

Analizziamo ora in dettaglio i singoli servizi.

RAD pag. 4

http://www.quellidiinformatica.org – Documento trovato in rete

3.2.1 Inserimento, modifica e cancellazione ordini clienti

Il sistema deve permettere all’addetto all’ufficio clienti di inserire nuovi ordini, controllarne lo stato, modificare o cancellare l’ordine e segnalare al cliente se un ordine è stato evaso o se è stato rifiutato. Pertanto la cancellazione e la modifica di un ordine saranno possibili solo se l’ordine non è stato inserito in un lotto andato in produzione. Inoltre si suppone che non siano necessarie ulteriori conferme da parte del cliente, il quale riceverà comunicazioni solo in caso di ordine rifiutato o di ordine evaso correttamente.

Si noti che un ordine si riferisce ad un solo modello di bicicletta; se un cliente dovesse richiedere pezzi di entrambi i modelli, il sistema provvederà a spezzare tale ordine nei due ordini (uno per ognuno dei due modelli di bicicletta) che lo compongono in maniera assolutamente trasparente per l’addetto all’ufficio clienti.

Tale scelta consente una gestione degli ordini più facile e soprattutto permette facilmente di aggiungere ulteriori modelli.

3.2.2 Composizione e smistamento lotti di produzione

Il sistema deve prevedere due figure professionali diverse con poteri decisionali diversi:

• L’addetto alla produzione, il quale si occupa della gestione ordinaria della produzione, ovvero può inviare allo stabilimento di pertinenza solo lotti omogenei;
• Il responsabile di produzione si occupa dei casi straordinari: ha gli stessi poteri dell’addetto alla produzione e in più può rifiutare un ordine e assemblare e inviare alla produzione lotti anomali.

Dalle richieste del cliente si evince che:

• Ognuno dei due stabilimenti si occupa di uno e un solo modello di bicicletta, pertanto una volta scelto il modello da produrre l’assegnazione ad uno stabilimento è immediata e non ambigua;
• Inoltre il sistema deve inserire automaticamente in un lotto gli ordini con data di scadenza prossima (entro le due settimane). Funzione svolta dalla composizione automatica dei lotti;
• Non è richiesto nessun metodo di scheduling automatico evoluto: il sistema inserirà automaticamente in un lotto solo gli ordini in scadenza o quelli la cui immissione è banale, permettendo sempre la modifica all’utente.

Si noti che in questa fase non è necessario memorizzare permanentemente i lotti: essi saranno memorizzati solo quando saranno stati approvati da chi di dovere e inviati agli stabilimenti produttivi.

3.2.3 Scheduling dei lotti di produzione

Non è previsto nessuno scheduling automatico dei lotti di produzione; il sistema deve permettere al responsabile di stabilimento di avere una vista di insieme chiara dei lotti in produzione e di quelli da produrre, e di potere organizzare la produzione giornaliera di settimana in settimana accordo con la politica di produzione dell’azienda.

Si ricorda che la capacità di produzione di ogni stabilimento varia da cinquanta pezzi al giorno, in regime di lavorazione ordinaria, fino a un massimo di cento pezzi al giorno, in regime straordinario; si ricorda inoltre che una volta deciso lo scheduling viene avviata la produzione, pertanto la coda di produzione non può più essere modificata.

Si assume che la decisione di lavorare in straordinario o meno sia presa dal responsabile di stabilimento.

RAD pag. 5

http://www.quellidiinformatica.org – Documento trovato in rete

3.2.4 Inserimento, modifica e cancellazione della distinta di produzione

Queste operazioni sono a cura del responsabile di magazzino; si noti che non è possibile modificare la distinta per un lotto già andato in produzione, altrimenti non sarebbe più possibile risalire alla distinta per un pezzo già prodotto. Nel caso in cui si modifichi la distinta per un lotto già andato in produzione, le modifiche apportate saranno memorizzate in una nuova distinta e applicate dal prossimo lotto in produzione in poi.

Se invece la distinta si riferisce a dei lotti non ancora in produzione il responsabile potrà modificarla, cancellarla o crearne una nuova a proprio piacimento.

Si noti che deve essere sempre presente almeno una distinta per ogni modello in produzione.

3.2.5 Creazione della lista delle parti necessarie per il magazzino

Si suppone, come specificato dal cliente, che il magazzino abbia capacità infinita. Il sistema deve ricavare in base ai lotti prodotti negli ultimi 15 giorni la lista delle parti da ordinare e presentarla al responsabile di magazzino; questi dovrà inserire manualmente il nome del fornitore e la data di consegna per ogni ordine di parti. Si noti che la separazione delle parti tra componenti pronte e materie prime non è rilevante per il calcolo del materiale consumato; tuttavia, per comodità dell’utente, viene indicato se la parte è un componente o una materia prima.

Si è scelto di indicare la quantità come numero non intero in maniera da prevedere eventuali parti che vengano consumate in quantità non intera per ogni pezzo (es.: “è necessaria mezza latta di vernice verde per produrre un pezzo del modello A”).

Il sistema fornirà la quantità esatta consumata per la produzione, sarà compito del responsabile di magazzino arrotondarla in eccesso o in difetto secondo le sue esigenze.

Si noti che il caso d’uso in cui si verificano problemi in fase di stampa non è stato trattato perché banale; il sistema permetterà di ripetere l’operazione di stampa fino a quando questa non vada a buon fine.

3.2.6 Inventario dei pezzi e creazione delle targhette

Il sistema deve mantenere un inventario dei pezzi prodotti. Per ogni pezzo è necessario memorizzare: numero di telaio, data di produzione, numero di lotto di produzione e identificativo cliente, in maniera tale da identificare univocamente il pezzo e chi l’ha ordinato. Basandosi su queste informazioni il sistema deve generare una targhetta da applicare sul pezzo.

Per i casi in cui la stampa delle targhette non vada a buon fine si applicano le considerazioni descritte alla fine del paragrafo precedente.

3.3 Requisiti non funzionali

3.3.1 Interfaccia utente e fattore umano

Si nota che il sistema si presenta a due fasce di utenti diverse: infatti, se è ragionevole supporre che gli impiegati dell’amministrazione, il responsabile di stabilimento e quello di magazzino abbiano dimestichezza con l’informatica, non si potrà dire altrettanto dell’operaio alla produzione, pertanto l’interfaccia utente per la postazione di quest’ultimo dovrà essere il più semplice possibile.

3.3.2 Documentazione

Per illustrare lo sviluppo del progetto al cliente e ai futuri sviluppatori saranno prodotti i seguenti documenti:

• Software Project Management Plan (SPMP) che illustra la pianificazione del progetto. Documento rivolto a clienti e responsabile del progetto.
• Requirements Analysis Document (RAD) il presente documento. Rivolto a clienti e sviluppatori.

RAD pag. 6

http://www.quellidiinformatica.org – Documento trovato in rete

• System Design Document (SDD) che illustra l’architettura ad alto livello del sistema. E’ rivolto agli sviluppatori.
• Object Design Document (ODD) che illustra il funzionamento di ogni oggetto. E’ rivolto agli sviluppatori.

3.3.3 Considerazioni sull’hardware

Per soddisfare le funzionalità richieste, si ritiene necessario utilizzare un sistema di memorizzazione dei dati. Inoltre, per facilitare le comunicazioni tra i vari reparti della ditta, si ritiene necessario Commento [I1]: l’utilizzo di un mezzo di comunicazione permanente e affidabile tra le varie postazioni. La trattazione è un po’ troppo qualitativa.

3.3.4 Considerazioni sulle prestazioni

Non vi sono particolari considerazioni sulle prestazioni, se non quella di non risultare un intralcio Commento [I2]: (piuttosto che una agevolazione) alla produttività dell’azienda. Quali sono i tempi di risposta del sistema accettabili? Ad esempio nella schedulazione dei lotti?

3.3.5 Gestione degli errori e condizioni estreme

Il sistema deve potere fronteggiare una perdita di connessione assicurando la coerenza e la persistenza dei dati immagazzinati e segnalare all’utente il fatto. In caso di guasto hardware il sistema deve permettere di riprendere il lavoro, dopo la riparazione del guasto, dal punto in cui si era interrotto.

3.3.6 Sicurezza

Dato che ogni figura professionale coinvolta ha privilegi diversi si dovrà prevedere un meccanismo per l’autenticazione dell’utente. Dato che i reparti dell’azienda sono distribuiti sul territorio si deve anche provvedere ad una comunicazione sicura tra i diversi reparti.

3.4 Pseudo – requisiti

Non sono presenti pseudo – requisiti particolari sull’implementazione del sistema.

3.5 Modelli del sistema

3.5.1 Scenari

3.5.1.1 Inserimento ordine Inserimento_Ordine_Bikes_R_Us

Nome dello scenario Tulip: Add