Requisiti software: Cos’è e a cosa serve l’analisi dei requisiti
Requirements engineering
Il requirements engineering (RE) è il termine che definisce le attività necessarie per documentare, raccogliere e tenere aggiornato l’insieme dei requisiti di un sistema software: i requisiti infatti non vengono buttati via una volta finita la prima fase di progettazione, ma vengono tenuti e aggiornati per esigenze future. Scopo primario del requirements engineering è la produzione e il mantenimento di un requirement document. Il procedimento con cui si genera il requirement document è iterativo: inizia con la requirements elicitation (raccolta dei requisiti), seguita dall’analisi dei requisiti, specifica dei requisiti e validazione dei requisiti, solitamente compiuta da persone esterne con un meccanismo di peer review.
Requirements elicitation
L’elicitation è la fase in cui si “tirano fuori” i requisiti dal cliente e da altri stakeholders. Il primo passo di questa fase è stabilire chi sono gli stakeholders, ovvero tutti quelli che hanno interessi nel sistema che andiamo a sviluppare: una volta fatto, l’analista andrà a intervistarli per determinarne i bisogni. Altri metodi integrativi alle interviste sono l’osservazione diretta sul luogo di lavoro, l’analisi dei prodotti dei competitors e workshop (brainstorming) per cercare di chiarire i requisiti. Spesso questa fase prevede anche l’analisi di leggi e regolamenti dell’ambiente in cui il nostro sistema andrà ad operare, report degli help desk e change requests per prodotti simili.
Analisi dei requisiti
I bisogni degli stakeholders, raccolti nella fase precedente, vengono raffinati e analizzati per capire se sono tutti fattibili e se c’è qualche requisito necessario che non è stato specificato nelle fasi precedenti ( missing requirements). In questa fase si identificano anche i conflitti tra i requisiti, e se ne stabilisce la priorità. Un esempio di requisiti in conflitto, nel caso del progetto di un generico sistema hardware potrebbero essere questi:
- al fine di minimizzare il consumo di energia si deve minimizzare il numero di chip preferendo quelli a basso consumo
- si devono garantire tempi di risposta molto rapidi.
Questi due requisiti saranno quasi sicuramente stati proposti da due stakeholder diversi, ad esempio il primo da un ingegnere che deve implementare il sistema e il secondo da un manager. Il conflitto si risolve mediando tra gli stakeholder al fine di arrivare ad una soluzione che tenti, per quanto possibile, di soddisfarli entrambi. Se non tutti i requisiti sono possibili da soddisfare entra in gioco la priorità dei requisiti, per sapere quali risolvere per primi e quali è possibile tagliare. Se nelle fasi successive adotteremo un metodo di sviluppo incrementale, inoltre, la priorità dei requisiti ci dice in che ordine implementare le funzionalità. Ci sono due strategie per organizzare la priorità dei requisiti: scala numerica e scala MoSCoW La scala MoSCoW suddivide i requisiti in
- MUST: da soddisfare assolutamente
- SHOULD: andrebbero soddisfatti, ma se questo causerebbe altri problemi, o siamo in ritardo con la consegna ecc. possiamo trascurarli
- COULD: da implementare solo se rimangono tempo e risorse dopo aver risolto tutto il resto quindi non sono quasi mai implementati
- WON’T: non sono necessari da implementare in quanto sono requisiti fuori dal contorno.
