Quando si parla di requirements engineering di fatto ci si concentra sulla comprensione di come una soluzione software si deve comportare per risolvere un certo problema. In questo senso bisogzna prima comprendere quale sia il problema da risolvere e in quale contesto tale problema si verifica, per poter arrivare ad una soluzione corretta ed efficace a problemi “reali”. Bisogna ben comprendere il problema, non si parla quindi della progettazione in se, ma del “cosa” deve fare il software.

• Esempio
• Esempio

Quando si parla di RE è bene distinguere due elementi:

1. esiste sempre un system-as-is, ovvero un sistema preesistente che già risolve il problema (anche se in modo non efficiente o qualitativamente sufficiente). Si ha quindi sempre un sistema da cui partire (esempio banale per il cruise control è dire che in realtà la soluzione al problema già esiste con la guida senza cruise control)
2. esiste sempre un system-to-be, ovvero il sistema che si andrà a realizzare. In altre parole è il sistema quando la macchina/software ci opera sopra.

Studiare il system-as-is è essenziale per poter lavorare al system-to-be.

Definizione: il requirements engineering è formalmente, un insieme di attività:

• per esplorare, valutare, documentare, consolidare, rivisitare e adattare gli obiettivi, le capacità, le qualità, i vincoli e le ipotesi su un system-to-be
• basate sul problema sorto dal system-as-is e sulle nuove opportunità tecnologiche

L’output di queste attività è un documento di specifica dei requisiti con tutto ciò che soddisfa il sistema. Se l’output non è un singolo documento si ha una collezione di singoli requisiti, che nel metodo agile sono storie / cards e in altri metodi un repository centrale con un db condiviso contenente i vari requisiti. In ogni caso si ha un insieme di requisiti su come si deve comportare il sistema che si realizza, descrivendo quanto descritto nei punti precedenti.

In un modello simil-cascata il RE è una delle primissime attività, subito dopo quelle di definizione del sistema e di business plan. Per gli aspetti tecnici è probabilmente la prima attività svolta, occupandosi di ottenere il giusto sistema da sviluppare (per fare la cosa giusta), prima di design, implementazione ed evoluzione software, etc… che si occupano di ottenere il software giusto, sviluppandolo nel modo corretto.

Errare nel RE può portare ad un ottimo software che risolve i problemi sbagliati (o non tutti i problemi che dovrebbe risolvere). Sbagliare i RE è una causa di fallimento del progetto (anche in un contesto non agile).

Lavorare sui RE non è semplice per diversi motivi:

• si deve ragionare su tante versioni del sistema:
  • as-is
  • to-be
  • to-be-next, volendo essere lungimiranti per il comportamento del sistema, sapendo e prevedendo evoluzioni future
• si lavora in ambienti ibridi, tra umano, leggi, device, policy, leggi della fisica, ecc…, quindi in un contesto eterogeneo che va compreso a fondo (ignorare degli aspetti può portare al fallimento)
• si hanno diversi aspetti funzionali, qualitativi e di sviluppo
• si hanno diversi livelli di astrazione, con obiettivi strategici a lungo termine di inserimento sul mercato e dettagli operazionali