Analisi dei requisiti

(1)

Analisi dei requisiti

Analisi dei requisiti

Anno accademico 2020/2021 Ingegneria del Software

Tullio Vardanega, tullio.vardanega@unipd.it

SWE, Corso di Laurea in Informatica, Università di Padova

1/30

(2)

Acquisizione e fornitura

 Il committente studia il problema e definisce le proprie attese sul prodotto

 Le fissa in un capitolato d’appalto che determina i «requisiti utente»

 Chi si candida a fornitore deve capire come corrispondere a quelle attese

 Fissando le implicazione di interesse, di costo e di qualità: studio di fattibilità

 Il progetto nasce quando committente e fornitore trovano un accordo contrattuale al riguardo

 Che fissa gli obiettivi (analisi dei requisiti) e i costi del progetto

 Il contratto finisce con la valutazione del committente sul prodotto

 Collaudo, accettazione

2/30

(3)

Glossario

 “Requisito” secondo il glossario IEEE

1. Capacità/ capability necessaria a un utente per risolvere un problema o raggiungere un obiettivo

 Visione dal lato del bisogno

2. Capacità/ capability che deve essere posseduta (o condizione che deve essere soddisfatta) da un

sistema per adempiere a un obbligo

 Visione dal lato della soluzione

3. Descrizione documentata di una capacità interpretata come in 1 o 2

3/30

(4)

Criticità

 Cause di abbandono (Standish Group 1995)



Requisiti incompleti



Insufficiente coinvolgimento del cliente/utente



Attese irrealistiche



Scarsità di risorse



Volatilità di specifiche e requisiti



Insufficiente competenza del fornitore

4/30

(5)

Studio di fattibilità – 1



Valutare rischi, costi e benefici

 Nell’ottica del cliente e del fornitore

 Competenze richieste/disponibili, prospettive future, competizione

 Studio basato su dati vari e spesso incerti

 Definizione e valutazione di possibili scenari



Decidere se procedere

 Con l’obiettivo di restare entro un costo massimo prefissato



Con le conoscenze immediatamente disponibili

 E con un piano di formazione sostenibile

5/30

(6)

Studio di fattibilità – 2



Fattibilità tecnico-organizzativa



Strumenti e tecnologie per la realizzazione



Soluzioni algoritmiche e architetturali



Piattaforme idonee per l’esecuzione



Rapporto costi/benefici



Confronto tra il mercato attuale e quello futuro



Costo di produzione vs. redditività dell’investimento



Individuazione dei rischi



Complessità e incertezze

6/30

(7)

Studio di fattibilità – 3

 Valutazione delle scadenze temporali



Risorse disponibili vs. risorse necessarie

 Valutazione delle alternative



Scelte architetturali

 Esempi: sistema centralizzato o distribuito; modello client-server; …



Strategie realizzative

 “Make or buy”: riuso o sviluppo ex-novo

7/30

(8)

Sui requisiti e sull’analisi



I requisiti riflettono l’ambiente d’uso, nella sua evoluzione da senza a con il prodotto, non la sua realizzazione

 Capire il «senza» per comprendere il «con», con terminologia coerente con il dominio d’uso



L’analisi riflette la struttura funzionale del prodotto

 Lo scenario «Premere un pulsante scatena un calcolo che legge o scrive dati» va trattato come gerarchia, dall’esterno all’interno, non come flusso

 Il punto di vista dell’analisi è sempre e solo quello del «lato utente»



Questa è la prospettiva dei diagrammi dei casi d’uso

 Relazione tra «attore» e «sistema»: l’attore è chi o cosa possa fare richieste alla parte di prodotto alla quale è esposto (sistema)

8/30

(9)

Attività di analisi



Studio dei bisogni e delle fonti del dominio d’uso



Comprensione del problema dal lato dei bisogni



Approfondimenti tramite scenari d’uso / use case



Raggruppamento degli scenari per affinità



Per individuare possibili parti del sistema



Classificazione e tracciamento dei requisiti



In dialogo con il committente (e gli altri stakeholder )

9/30

(10)

Studio del dominio



Domande base

 A quali bisogni risponde il prodotto atteso

 Quali problematiche d’uso esso comporta



Acquisizione delle conoscenze

 Documentazione e soluzioni preesistenti

 Interviste agli utenti



Consolidamento del glossario

 Raccoglie e definisce i termini chiave del dominio

 Per interazione ordinata con il committente

 Consolidato nel corso del progetto

10/30

(11)

Tecniche – 1



Dominio d’uso come fonte di requisiti impliciti



Comportamenti dell’utente e dell’ambiente d’uso



Interazione con il cliente / committente



Interviste



Generazione, analisi e discussione di scenari



Discussioni creative e collaborative (aka brainstorming )



Prototipazione



Interna (solo per il fornitore)



Esterna (per discussione con il cliente)

11/30

Esito documentato in verbalicon

valore contrattuale

(12)

Qualità dell’analisi – 1

 La specifica dei requisiti deve essere



Priva di ambiguità (UNAMBIGOUS)



Corretta (CORRECT)



Completa (COMPLETE)



Verificabile (VERIFIABLE)



Consistente (CONSISTENT)



Modificabile (MODIFIABLE)



Tracciabile (TRACEABLE)



Ordinata per rilevanza (RANKED)

12/30

IEEE 830-1998

Recommended Practice for

SW Requirements Specifications

(13)

Qualità dell’analisi – 2

13/30

(14)

Tecniche – 2

 Per avere quelle qualità conviene che i requisiti siano «a grana fine»



I requisiti utente spesso sono «a grana grossa»



Lo studio del problema li affina, suddividendoli, e ne aggiunge, ampliando la ricerca

 È utile «sapere dove cercare»



La classificazione dei requisiti aiuta a farlo



Rispondendo alla domanda: che tipo di requisiti applicano al prodotto?

14/30

(15)

Classificazione dei requisiti – 1

Extra-functional requirement

M. Glinz,

On Non-Functional Requirements.

15^thIEEE International Conference on Requirements Engineering.

October 2007, 21-26

15/30

(16)

Classificazione dei requisiti – 2

16/30

Requisiti di vincolo

(17)

Classificazione dei requisiti – 3

 I requisiti hanno diversa rilevanza e utilità, che va negoziata e concordata con il committente



Obbligatori

 Irrinunciabili per qualcuno degli stakeholder



Desiderabili

 Non strettamente necessari ma a valore aggiunto riconoscibile



Opzionali

 Relativamente utili oppure contrattabili più avanti nel progetto

 Non devono essere tra loro contraddittori

17/30

(18)

Punto di arrivo

 Culmine del progetto è il collaudo (validazione) del prodotto

 In esso il fornitore dimostra che tutti i requisiti siano soddisfatti

 La validazione concerne i requisiti di lato committente, ma i requisiti dello sviluppo sono molti di più

 Il prodotto è efficace se soddisfa pienamente tutti i requisiti

 Il fornitore assicura che i requisiti non esposti al collaudo siano anch’essi validati

 Usando un processo di verifica incrementale, che non ne dimentica alcuno (tracciamento)

 L’analisi deve facilitare la verifica dei requisiti

 Chi fissa un requisito deve immaginare come verificarne il soddisfacimento

 Facendo attenzione al costo e complessità di verifica

18/30

(19)

Glossario



Verifica

 Accertare che l’esecuzione di attività non introduca errori

 Did I build the system right?

 Attenzione rivolta al way of working

 Rispetto delle regole, convenzioni e procedure vigenti nell’attuazione dei processi



Validazione

 Accertare che il prodotto corrisponda alle attese

 Did I build the right system?

 Attenzione rivolta al prodotto finale



Piano di qualifica

 Dire come svolgeremo le attività di V&V nel progetto

 Metodi, tecniche, procedure, strumenti e tempi

19/30

V & V = Qualifica

(20)

Tracciamento dei requisiti

20/30

Requisito Progettazione

Codice Validazione

Verifica

soddisfa

realizza

conferma accerta

assicura abilita

(21)

Esempio di tracciamento

21/30

Necessità: tutti i requisiti in AR soddisfano un particolare bisogno Sufficienza: tutti i bisogni rilevati nelle fonti sono requisiti in AR

• ……

Capitolato d’appalto Dominio

Bisogni impliciti (derivati)

Fonti

• ……

Documento AR Capitolato d’appalto

Dominio

Bisogni impliciti (derivati)

Fonti

Bisogni espliciti

(22)

Confine tra analisi e design – 1

22/30

Soluzione del problema

Analisi

Design

Enunciazione del problema

Requisiti del problema

Massimo approfondimento del problema

Sintesi della soluzione scelta

(23)

Confine tra analisi e design – 2

Partition requirements

Identify sub-systems

Assign requirements to sub-systems

Specify sub-system functionality

Define sub-system interfaces

Analisi Progettazione

23/30

(24)

Processi di supporto all’analisi



Documentazione



Per raccogliere i risultati dello studio di fattibilità



Per specificare i requisiti



Verifica



Gestione e manutenzione dei prodotti

 Tracciamento dei requisiti

 Essenziale per il controllo sistematico di conformità

 Gestione di versione e configurazione

 I prodotti dell’analisi non sono monoliti e possono subire variazioni

 Gestione dei cambiamenti

 Cambiare i requisiti ha implicazioni delicate e va fatto con metodo e procdure

24/30

(25)

Documentazione dell’analisi – 1

 La documentazione in linguaggio naturale genera rischi di ambiguità interpretativa



Servono norme redazionali per evitare espressioni ambigue



Glossario per garantire terminologia consistente

 L’uso di metodi (semi-)formali aiuta a ridurre gli errori di interpretazione



Diagrammi e formule (UML) invece di testo e disegni in stile libero

25/30

(26)

Documentazione dell’analisi – 2

26/30

ISO/IEC/IEEE 29148:2018

System and software engineering – Life cycle processes –

Requirements engineering Example outline of

Software Requirements Specification

(27)

Documentazione dell’analisi – 3



Ricercare chiarezza espressiva

 L’uso del linguaggio naturale rende difficile coniugare chiarezza con facilità di lettura



Ricercare chiarezza strutturale

 Separazione tra requisiti funzionali e non-funzionali

 Classificazione precisa, uniforme e accurata



Ricercare atomicità e aggregazione

 Requisiti elementari

 Correlazioni chiare ed esplicite

27/30

(28)

Verifica dell’analisi



Eseguita su un documento organizzato

 Non ripete il lavoro di analisi, ma si accerta che esso sia stato svolto in modo conforme alle attese



Tramite walkthrough

 Lettura a largo spettro



Oppure ispezione

 Lettura mirata e strutturata



Accertando necessità e sufficienza dei requisiti specificati

 Esaminando la matrice delle dipendenze (documentazione di tracciamento)

28/30

(29)

Stati di progresso per SEMAT – 1

 Conceived



Il committente è identificato e gli stakeholder vedono sufficienti opportunità per il progetto

 Bounded



I bisogni macro sono chiari, i meccanismi di gestione dei requisiti (configurazione e

cambiamento) sono fissati

 Coherent



I requisiti sono classificati e quelli essenziali (obbligatori) sono chiari e ben definiti

29/30

(30)

Stati di progresso per SEMAT – 2

 Acceptable



I requisiti fissati definiscono un sistema soddisfacente per gli stakeholder

 Addressed



Il prodotto soddisfa i principali requisiti al punto da poter meritare rilascio e uso

 Fulfilled

