Un recente Technical Report del Software Engineering Institute tratta il tema della frequente mancanza delle informazioni necessarie per definire le architetture software.

“C’è un disallineamento profondo e sostanziale tra le informazioni contenute nelle specifiche dei requisiti e quelle di cui gli architetti hanno bisogno. Il disallineamento si evidenzia in due aspetti:

1. La maggioranza dei contenuti di una specifica dei requisiti non determina né contribuisce a definire l’architettura. Le architetture sono soprattutto determinate dai requisiti non funzionali; eppure la parte più consistente delle normali specifiche dei requisiti si focalizza sulle funzionalità del sistema, che hanno un impatto limitato sulla scelta delle architetture. Peggio ancora, molte specifiche specificano poco e male i requisiti non funzionali; molte li ignorano completamente.

2. Parecchie informazioni che sarebbero utili ad un architetto software non si trovano neppure nelle migliori specifiche dei requisiti. Sono informazioni che derivano dagli obiettivi di business dell’organizzazione in cui origina l’esigenza di sviluppo, come ad esempio impiegare le risorse in modo produttivo, ammortizzare gli investimenti fatti in strumenti e tecnologie, rispettare le indicazioni provenienti dalla gestione delle risorse umane, migliorare il posizionamento di mercato dell’organizzazione rispetto alla concorrenza, ed altri aspetti analoghi.”

L’individuazione degli obiettivi di business da cui partire deve avvenire con il coinvolgimento degli stakeholder, attraverso interviste o workshop. Il report propone un modo innovativo di definire gli obiettivi di business, basato sull’analisi di alcuni elementi di base:

• il soggetto che ha interesse al raggiungimento dell’obiettivo (es. uno sponsor)
• l’oggetto toccato dall’obiettivo (es. il cliente di cui si desidera migliorare la soddisfazione)
• il contesto in cui l’obiettivo va interpretato (es. di mercato, o tecnologico, o sociale)
• le unità di misura utili per valutare se l’obiettivo è stato raggiunto
• il grado di volatilità dell’obiettivo
• il valore dell’obiettivo

Il passo successivo consiste nella derivazione dagli obiettivi di business dei requisiti non funzionali (o “requisiti sugli attributi di qualità”, come vengono chiamati nel report), partendo dal presupposto che ogni requisito non funzionale deve trovare la propria ragion d’essere in un obiettivo significativo a livello di business.

Ciò consente, tra l’altro, di analizzare in modo critico eventuali vincoli e requisiti non funzionali precedentemente espressi, per verificarne il fondamento in termini di obiettivi di alto livello.

Il report, “Relating Business Goals to Architecturally Significant Requirements for Software Systems”, a cura di Paul Clements e Len Bass, è scaricabile dal sito del SEI.