Requisiti e modelli: prima di iniziare, capire il contesto

Nell’analisi strutturata il diagramma di contesto è considerato un must, il primo passo dell’analisi, da cui partire per identificare le funzionalità del sistema con le tecniche di scomposizione.

Si disegna il sistema da analizzare come un singolo processo, quindi le entità esterne o attori (clienti, fornitori, altri sistemi) con cui il sistema deve interagire e i flussi di input e output tra questi e il sistema stesso.

Esempio

Figura tratta da en.wikipedia.org

Con l’ascesa della programmazione a oggetti, l’analisi strutturata è stata in gran parte soppiantata dai metodi Object Oriented (In realtà l’analisi strutturata è ancora utilizzata in diverse realtà, ma più per l’analisi dei processi che per l’analisi dei sistemi informatici) . Peccato che con essa è caduto un po’ in disuso anche l’utilizzo di uno strumento utile quale il diagramma di contesto.
In effetti UML non prevede esplicitamente un “context diagram”, anche se è possibile rappresentarlo attraverso i suoi diagrammi (es. Class Diagram, Package Diagram, ecc.).
Spesso nei documenti di analisi è presente un diagramma dei casi d’uso, ma il suo scopo è diverso. il modello dei casi d’uso rappresenta tutte le funzionalità che il sistema offre ai suoi utilizzatori e presuppone quindi l’individuazione delle macro-funzionalità del sistema, almeno ad un livello di sintesi.
Il diagramma di contesto, invece, si focalizza sull’ambiente in cui un sistema si trova ad operare e sulle sue interazioni con il mondo esterno. Serve a definire l’ambito dell’analisi ed è un punto di partenza per la raccolta dei requisiti del sistema.
Certo non è banale determinare il contesto di un nuovo sistema, inizialmente si può sbagliare definendolo troppo grande o troppo limitato, ma è pur sempre un punto di partenza da adattare man mano che l’attività di analisi procede e si chiarisce che cosa è dentro e che cosa è fuori dal campo della nostra indagine.
In caso di rifacimento di un sistema, poi, disegnare il diagramma di contesto (se non è già documentato), riduce il rischio di dimenticare attori o connessioni importanti, quando non opportunamente esplicitati nei requisiti perché considerati assodati (ad es. l’invio a cadenza di flussi di dati istituzionali verso enti o società).
Il diagramma di contesto, rappresentando in forma sintetica la globalità delle interazioni del sistema con l’ambiente esterno, agevola l’analisi di impatto ad alto livello. Se un ente richiede i dati in un nuovo formato, se un sistema della nostra azienda è in corso di rifacimento, possiamo subito verificare se questi eventi hanno qualche impatto sul nostro sistema.
E’ importante sottolineare che un sistema può riferirsi a livelli diversi:

• un sistema informatico
• un processo di business
• una funzione aziendale (es. il sistema organizzativo della funzione Vendite)
• l’intera azienda
• ….

Il diagramma di contesto può quindi rappresentare uno qualsiasi di questi livelli, focalizzandosi non sulla struttura del sistema, ma sull’ambiente in cui esso vive e opera e sulle sue modalità di risposta agli eventi e stimoli provenienti dall’ambiente. In altre parole, il diagramma di contesto definisce i confini di un sistema, gli eventi, i flussi di informazioni (o di materiali) che attraversano questi confini e che provengono o sono destinati al nostro sistema.
Uno dei primi compiti da affrontare per l’analista è la definizione dei confini del campo di analisi, il suo ambito. Sicuramente il diagramma di contesto fa al caso nostro per supportarci in questo arduo compito. Ma da dove partire?
Prima ancora di capire il contesto del prodotto software/servizio (sistema informatico) da realizzare o modificare, è utile comprendere i reali problemi e le esigenze dell’intervento richiesto, partendo da un ambito più ampio: il contesto del “business” in cui la soluzione dovrà calarsi. Si tratta di estendere l’analisi anche alle attività umane che devono essere svolte nel sistema e alle persone coinvolte e non limitarsi ai soli aspetti automatizzati.
Solo in questo modo sarà possibile acquisire una visione e una comprensione sufficienti per individuare i corretti requisiti per la soluzione e realizzare un prodotto/servizio adeguato alle esigenze.
Interessante a questo proposito è l’articolo Work Scope and product Scope: Why Both? di Suzanne Robertson e James Robertson, indiscusse autorità in materia di gestione dei requisiti e di analisi dei sistemi.