analisi-disegno.com

Homepage  | Blog | Per essere avvisati in caso di nuovi documenti | In English

I requisiti si scoprono progressivamente

Esprimere requisiti per evolvere e migliorare di un sistema esistente è relativamente semplice. Ma per qualcosa di nuovo, è molto più complesso.

"Spesso, il modo migliore per scoprire requisiti che nessuno ancora conosce è rilasciare il prodotto in modo incrementale. Ogni volta che i clienti ricevono un rilascio tirano fuori decine di altre funzioni che vorrebbero avere. È un dato di fatto che il numero di nuovi requisiti pensati dai clienti è proporzionale al numero di requisiti già soddisfatti. [...]

La maggior parte dei manuali sull’ingegneria del software raccomanda di non iniziare la progettazione fino a quando tutti i requisiti non sono concordati. È un consiglio sbagliato, perché comunque non arriverete mai a conoscere tutti i requisiti, e iniziare presto la progettazione vi servirà probabilmente a scoprire nuovi requisiti.” (Alan Davis: Just Enough Requirements Management )

“I cambiamenti in corso d’opera per sistemi medio-grandi avverranno sempre. Non è possibile congelare i requisiti per nessuna applicazione reale. Quindi le aziende migliori sono in grado di gestire i cambiamenti e sono pronte a farlo, facendo in modo che i cambiamenti non impediscano l’evoluzione del sistema. Una qualche forma di sviluppo iterativo è una necessità logica.” (Capers Jones, Social and Technical Reasons for Software Project Failures, CrossTalk, June 2006)

Conseguenze:

1. Lo sviluppo iterativo (in cui il lavoro sui requisiti non è limitato ad un'unica fase progettuale) è più efficace dello sviluppo a cascata.

2. Per scoprire i requisiti il dialogo con il committente, i futuri utenti e gli altri stakeholder va basato il più possibile sull'analisi di concreti scenari operativi e sulla verifica di prototipi, non su ragionamenti astratti. Le astrazioni sono un terreno su cui analisti e sviluppatori software si muovono agevolmente, ma non accade altrettanto per tutti coloro che devono esprimere i requisiti.

Funziona meglio, in tutti i casi in cui sia praticabile, la strategia di costruire il sistema per incrementi successivi, e sottoporre i risultati concreti agli stakeholder per ottenere riscontri ed ulteriori indicazioni per l'evoluzione del sistema.

Pagina generale sui requisiti

analisi-disegno.com, servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.