Ingegneria del Software -analisi dei requisiti

Requirements Analy-

sis Document

Progetto SmartWheel

Gestione Fabbrica Biciclette

NOTA: questo documento è stato trovato in rete ed è gra-

tuitamente distribuito, a scopo didattico, dal sito

www.quellidiinformatica.org , Community studenti di In-

gegneria 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

Progetto SmartWheel Requirements Analysis Document

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 produ- di un dato modello.

zione Insieme di ordini tutti per uno stesso modello. E’ caratteriz-

Lotto di produ- zato da un numero identificativo, un numero totale di pezzi

zione (ricavato dalla somma dei pezzi dei singoli ordini) e dalle da-

te di consegna dei singoli ordini. Può essere: omogeneo, a-

nomalo, in produzione o ultimato.

Lotto di produzione con un numero totale di pezzi compreso

Lotto omogeneo tra 50 e 150 e date di consegna degli ordini che non differi-

scano per più di 15 giorni.

Lotto il cui numero totale di pezzi non è compreso tra 50 e

Lotto anomalo 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 attualmente in lavorazione presso uno stabilimento. Un

Lotto in produ- lotto in produzione non può più essere cancellato.

zione Lotto la cui lavorazione è stata completata e che è pronto a

Lotto ultimato essere consegnato

Richiesta da parte di un cliente all’ufficio clienti per un certo

Ordine numero di biciclette, di un certo modello e per una certa data.

Un ordine può essere: proposto, rifiutato, in produzione,

ed evaso.

Ordine che è stato ricevuto dall’ufficio clienti ma non ancora

Ordine proposto sottoposto al reparto produzione; a seconda dell’esito può

diventare ordine in produzione oppure ordine rifiutato.

Ordine che non è stato approvato dal reparto produzione.

Ordine rifiutato Ordine che appartiene ad un lotto che è stato inviato allo sta-

Ordine in produ- bilimento di produzione. Un ordine in produzione non può

zione più essere cancellato. Una volta completata la produzione i

pezzi vengono inviati al cliente e l’ordine diventa evaso.

Ordine facente parte di un lotto ultimato.

Ordine evaso RAD pag. 3

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

Progetto SmartWheel Requirements Analysis Document

Ordine di una data quantità di una singola parte verso un da-

Ordine verso for- to fornitore; comprende nome del fornitore, nome e quantità

nitore della parte e data di consegna.

Materia prima o componente necessaria per la fabbricazione

Parte di un pezzo.

Bicicletta del modello A o B completa di tutte le sue parti.

Pezzo Ogni pezzo viene univocamente identificato dalla sua tar-

ghetta.

Etichetta adesiva da applicare su ogni pezzo che lo identifica

Targhetta univocamente e che contiene: codice identificativo dello sta-

bilimento, numero di telaio e dati relativi.

2 Sistema attuale

Si suppone che non ci sia nessun sistema informatico preesistente e che tutte le attività di archivia-

zione 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 qua-

li 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 ma-

niera 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 preceden-

za.

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 bi-

cicletta.

• 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

Progetto SmartWheel Requirements Analysis Document

3.2.1 Inserimento, modifica e cancellazione ordini clienti.

Il sistema deve permettere all’addetto all’ufficio clienti di inserire nuovi ordini, controllarne lo sta-

to, modificare o cancellare l’ordine e segnalare al cliente se un ordine è stato evaso o se è stato rifiu-

tato. Pertanto la cancellazione e la modifica di un ordine saranno possibili solo se l’ordine non è sta-

to 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 o-

gnuno 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 aggiun-

gere 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, ov-

vero 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 pro-

duzione 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à automa-

ticamente in un lotto solo gli ordini in scadenza o quelli la cui immissione è banale, permet-

tendo sempre la modifica all’utente.

Si noti che in questa fase non è necessario memorizzare permanentemente i lotti: essi saranno me-

morizzati 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 stabili-

mento. RAD pag. 5

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

Progetto SmartWheel Requirements Analysis Document

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 di-

stinta 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 pros-

simo lotto in produzione in poi.

Se invece la distinta si riferisce a dei lotti non ancora in produzione il responsabile potrà modificar-

la, 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 con-

segna 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, vie-

ne 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 ver-

nice 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 memorizza-

re: 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 informa-

zioni 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 descrit-

te 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 prodotto 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 svilup-

patori. RAD pag. 6

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

Progetto SmartWheel Requirements Analysis Document

• System Design Document (SDD) che illustra l’architettura ad alto livello del sistema. E’ ri-

volto agli sviluppatori.

• Object Design Document (ODD) che illustra il funzionamento di ogni oggetto. E’ rivolto a-

gli 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 accet-

tabili? Ad esempio nella schedula-

3.3.5 Gestione degli errori e condizioni estreme zione dei lotti?

Il sistema deve potere fronteggiare una perdita di connessione assicurando la coerenza e la persi-

stenza 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 inter-

rotto.

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