Ingegneria dei Requisiti - e dei Sistemi - Giuseppe Berio DI-Unito 2007

Ingegnerie dei Requisiti - e dei Sistemi -: Punti chiave Determinazione e specifica dei requisiti del software (senza distinguere lo studio di fattibilità, senza distinguere le due attività che possono essere svolte al contempo) Uso di notazioni (o linguaggi) nella Ingegneria dei Requisiti – e dei Sistemi - Formalizzazione della relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

Sintesi Due casi di determinazione dei requisiti ove si è visto che l’attività di determinazione dei requisiti (o comunicazione) e quella di specifica (o modellazione analitica) sono state svolte a partire da una richiesta del committente (dal nulla – greenfield engineering - con richiesta più o meno innovativa) Si è evidenziato che: La richiesta del committente, in generale, non indica direttamente i requisiti del software ma tali requisiti devono essere esplicitamente determinati; infatti, la richiesta del committente, in generale, riguarda un sistema in cui il software da sviluppare è solo una parte (il sistema è perciò costituito sia dal software da sviluppare che dall’ambiente circostante a tale software e che con questo interagisce), indica, in particolare, cosa tale sistema dovrebbe permettere, anche dicendo poco o nulla su come tale sistema dovrà essere realizzato La tracciabilità di un requisito è, di conseguenza, un elemento fondamentale poiché giustifica un requisito in termini della richiesta del committente

Sintesi Non si è distinto tra le due attività: Le diverse notazioni – semiformali – (cioè DFD, DFD esteso, UML) usate sono servite per svolgere analisi per verificare se ciò che è stato fatto è corretto, è completo o per ragionare su alternative possibili (determinazione dei requisiti), quindi permettere eventuale negoziazione anche in termini di tempi e costi E fatto osservare che i requisiti del software da sviluppare devono essere esplicitamente accettati o convalidati dal committente; il ruolo dell’ingegnere del software è solo quello di aiutare il committente nel definire e nel convalidare i requisiti del software (determinazione dei requisiti) Ma si è anche detto che ciò che è rappresentato con una o più notazioni è efficacemente usabile per progettare il software (specifica dei requisiti) Nell’uso delle notazioni si è evidenziato come l’ingegneria del software è sistematica cioè tenta di applicare regole definite per costruire diverse rappresentazioni (dei requisiti) con la medesima o diverse notazioni

Ammettiamo che un sensore non funziona; cosa accade? Se un sensore non funziona, il sistema dovrebbe fermare l’ascensore in funzione ai piani precedenti o successivi L’ascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dell’ascensore Comprensione Modellazione Movimento Sensori Ev_ascensorepiano(x) Movimento Analisi Convalida Negoziazione Verifica Ammettiamo che un sensore non funziona; cosa accade?

Notazioni usate per la modellazione Matrici DFD Casi d’Uso (UML) Statechart (UML) DFD estesi Diagramma delle classi (UML) Diagramma di sequenza (UML)

Generalizzazione

Determinazione dei Requisiti: una definizione Obiettivo: arrivare ad una collezione, sufficientemente dettagliata, completa e condivisa (cioè priva di conflitti) tra tutti i partecipanti (stakeholder) dei requisiti che il prodotto software dovrà possedere, una volta prodotto La determinazione dei requisiti inizia da una richiesta del committente che, in generale, evidentemente, non indica necessariamente i requisiti del software da sviluppare; in particolare, spesso non indica una chiara distinzione tra ciò che è software da sviluppare e ciò che è l’ambiente circostante al software; i requisiti si devono perciò dedurre, estrarre, identificare, elaborare, negoziare, convalidare e forse anche analizzare La collezione raccoglie e, talvolta, permette di visualizzare, in varie forme, i requisiti di cui è composta, e i legami tra tali requisiti (inclusa la tracciabilità) Spesso tale collezione coincide con un documento dei requisiti

Specifica dei requisiti: una definizione Obiettivo: produrre una “specifica dei requisiti” cioè una precisa descrizione (modello) informale, semiformale ovvero formale, di tutti requisiti determinati, che permette di passare sistematicamente alla progettazione del software Qualunque sia il modo di operare, dovrebbe essere chiaro il legame tra i requisiti determinati e il modello qui costruito (tracciabilità) La specifica può essere più o meno formale ma dovrebbe essere sempre sufficientemente precisa, completa e corretta; come vedremo, la scelta per una specifica formale è essenzialmente legata alla necessità di provare una relazione fondamentale, tra i requisiti del software, il comportamento dell’ambiente circostante il software e, ciò che è richiesto dal committente

I prodotti principali delle due attività e le loro relazioni Il documento dei requisiti (una o più notazioni) che raccoglie la collezione organizzata dei requisiti determinati Il modello dei requisiti o modello analitico (una più notazioni) che rappresenta in modo opportuno la collezione dei requisiti determinati Il modello dei requisiti può far riferimento a modelli già presenti nel documento dei requisiti I due elaborati devono essere consistenti cioè non devono essere mutuamente contradditori

Dettaglio delle attività di determinazione e specifica dei requisiti può riusare o riferirsi Comprensione Requisiti (Collezione + Documento dei Requisiti) Modello Linguaggio Comune Modellazione Modellazione Analisi devono essere non contradditori (verifica) Convalida Negoziazione Verifica Modello Linguaggio Comune Modello dei Requisiti (Modello Analitico o Specifica dei Requisiti) Prototipo (*) (*) dipende dal processo

Notazioni alternative per la specifica dei requisiti e la determinazione dei requisiti Formale Semi-Formale Informale Una loro combinazione

Esempio Fermare Spegnere i pulsanti (una passo del caso d’uso) Descritto come Spegnere i pulsanti (una passo del caso d’uso) Descritto come Descritto come Partire (una caratteristica del sistema) traced to (from)

I problemi del linguaggio comune per esprimere i requisiti • Rumore – le affermazioni non indicano informazioni utili • Silente – qualcosa di non coperto dalle affermazioni • Sovra-specificato – si indica nelle affermazioni troppo sul come realizzare • Contraddizione – parti delle affermazioni che si contraddicono. • Ambiguità – esistono varie interpretazioni di un’affermazione, non necessariamte contradditorie • Forward reference – riferimenti a termini o altri elementi non ancora definiti nelle affermazioni • Non validabile – non si è certi che è possibile convalidare ciò che è affermato • Frammentati – gli elementi chiave contenuti nelle affermazioni sono dispersi in un documento • Requisiti oca – affermazioni formalmente corrispondenti a standard • Terminologia inconsistente – Invenzioni e modifiche della terminologia usata nelle affermazioni • Rimandare il problema ad altri – Obbligo per chi deve usare le affermazioni di decifrare il loro significato • Formulazione per il lettore ostile

Esempio di misure di qualità dei requisiti scritti in linguaggio comune Directives ÿindicated by tables, figures etc ÿthese strengthen the quality of the document Size ÿin terms of lines of text, indicators and subjects ÿroughly, the number of subjects for all the imperatives Text structure ÿmeasures the number of statement identifiers Specification depth ÿmeasures how deep are the subsections of the a requirement document ÿgives an indication of a requirement document structure. Readability statistics ÿe.g average number of syllables per word, number of words per sentence Imperatives ÿidentified by words such as “shall”, “must”, “is required”, etc. ÿImperatives measure how explicit a requirement document is. Continuances follow an imperative and introduce requirements ÿindicated by “below:”, “as follows:” etc. ÿmeasure the structure of an a requirement document. Option ÿindicated by words such as “can”, “may”, “optionally” etc. ÿmeasure how much latitude does a requirement document leave Weak phrases ÿcause uncertainty ÿe.g. “adequate”, “as applicable” etc.

Cos’è un requisito del software Un requisito del software è un’affermazione sul software che riguarda proprietà, comportamenti, vincoli (di varia natura) del software Tali affermazioni possono riguardare come si deve comportare (requisiti funzionali), ed altre affermazioni sul software ovvero del prodotto software (requisiti non funzionali) Ma per essere requisiti, tali affermazioni dovrebbero possedere almeno alcune caratteristiche!

Caratteristiche di un requisito (qualunque sia la notazione) Grado di priorità Grado di stabilità Grado di rischio Condiviso Non ambiguo Completo Non in conflitto Tracciabile Verificabile Manutenibile Traceability (IEEE) : the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another Traceability (ISO 8402) : is the ability to trace the history, application or location of an entity by means of recorded identifications

Esistono affermazioni “perfette” per i requisiti? ambiguo ridondante inconsistente incomprensibile incompleto espandere sintetizzare ridurre spiegare formalizzare risolvere formalizzare

Importanza della Tracciabilità Verification and Validation  assessing adequacy of test suite  assessing conformance to requirements  assessing completeness, consistency, impact analysis  assessing over- and under-design  investigating high level behaviour impact on detailed specifications  detecting requirements conflicts  checking consistency of decision making across the lifecycle Maintenance  Assessing change requests  Tracing design rationale Document access  ability to find information quickly in large documents Process visibility  ability to see how the software was developed  provides an audit trail Management  change management  risk management  control of the development process

I requisiti hanno sempre un doppio ruolo requisito Progettisti, Sviluppatori, Committente Committente Affermazione sufficientemente precisa (cioè non ambigua), (direttamente) usabile da progettisti e sviluppatori e, talvolta, anche al committente Affermazione sufficientemente precisa, anche sufficientemente comprensibile al committente, giustificata in termini della sua richiesta non contradditori (verifica)

Esempio I: il doppio ruolo dei requisiti Cosa è più comprensibile per il Committente? Un utente deve poter inserire la sua partenza e la sua destinazione, le ore ed i giorni di partenza e di arrivo E’ possibile effettuare una ricerca sui possibili treni esistenti secondo i seguenti criteri….. Cosa è necessario per rispondere adeguatamente alla richiesta del Committente? Il requisito espresso in linguaggio comune pur astrattamente ambiguo potrebbe essere accettabile se il committente e l’ingegnere dei requisiti sono d’accordo che questo rappresenta tutte le possibili situazioni ovvero una qualunque situazione Ricercare utente Dest+Arr | Dest+Arr+Hp|Ha | … Treni Cosa è necessario affinché sia possibile progettare il software? If Dest and Arr are available then Seleziona Treni tali che… Rif. Esempio Treno

Esempio II: il doppio ruolo dei requisiti Se un sensore non funziona, il sistema dovrebbe fermare l’ascensore in funzione ai piani precedenti o successivi L’ascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dell’ascensore If Ev_ascensorepiano(x) and Direction=Down and ProssimaRichiesta(y) and x<y then Rallentare Motore; … Fermare& Partire Sensori Ev_ascensorepiano(x) If Ev_ascensorepiano(x) and ProssimaRichiesta(y) and x=y then Rallentare Motore; … Rif. Esempio Ascensore

Il documento dei requisiti In generale il documento dei requisiti raccoglie in modo organizzato i requisiti determinati, descritti in una o più notazioni, ed anche informazioni ulteriori sulla richiesta del committente e su come la determinazione ha avuto luogo La forma di tale documento è generalmente standardizzata nella forma e nei contenuti dalla meteodologia adottata (anche perché spesso costituisce una base contrattutale) Tale standardizzazione può essere relativa alla metodologia specifica ovvero coincidere con uno standard di riferimento come ad esempio IEEE-830-1993

Il documento dei requisiti Il documento dei requisiti contiene generalmente diagrammi e, collegate, affermazioni in linguaggio comune

La forma del modello analitico In generale una metodologia propone una forma del modello analitico che s’ispira all’uso di una o più notazioni, legate da regole più o meno precise Le metodologie si differenziano spesso in base alla tipologia delle notazioni usate (non alla notazione poiché si è detto che esistono notazioni diverse per DFD, DFD estesi, mentre per UML la notazione è adattabile ovvero si possono usare diverse notazioni per esprimere classi, scambio di messaggi etc.)

(Analisi Strutturata)

Modello Object-Oriented di Analisi (Esempio) Casi d’Uso Diagrammi di Sequenza Classi (attributi ed operazioni) Statecharts

Quali requisiti vengono specificati I requisiti sono di varia natura; i requisiti che vengono specificati sono: I requisiti funzionali Parte dei requisiti non funzionali, se necessario I requisiti funzionali indicano tipicamente le funzionalità, i comportamenti, le proprietà ovvero le informazioni desiderati I requisiti non funzionali indicano talvolta delle proprietà desiderate che devono essere soddisfatte dal prodotto software; l’interesse per i requisiti non funzionali deve essere considerato nella specifica dei requisiti funzionali (ad esempio, nel caso ascensore, se il tempo di trattamento per richieste prioritarie deve essere inferiore a 0,01ms può obbligare a requisiti funzionali diversi)

Una tassonomia dei requisiti non funzionali

Uso delle notazioni nella Ingegneria dei Requisiti

Metodi-Pratiche Metodi/Pratiche che aiutano a trasformare una descrizione testuale anche imprecisa in un diagramma (per estrarre, dedurre, etc. i requisiti) Metodi/Pratiche che aiutano a trasformare una notazione in un’altra (ed associati, Metodi/Pratiche che aiutano a verificare la eventuale “equivalenza”): Per passaggio, Per incremento. Metodi/Pratiche di analisi che aiutano a valutare la completezza e la correttezza di ciò che è stato rappresentato tramite un diagramma (per estrarre, dedurre, etc. i requisiti) Metodi/Pratiche per provare formalmente la relazione fondamentale (verificare)

Riepilogo: Notazioni Usate Linguaggio (notazione) Uso Diagramma dei casi d’uso Scenari DFD Funzioni DFD di contesto Funzione DFD ed ER Funzioni e Dati DFD Estesi (con Statechart) Comportamento Statechart Diagramma delle classi Oggetti concettuali Diagramma di sequenza Interazioni degli oggetti (concettuali)

Sistematizzazione dei passaggi usati negli esempi (Metodi-Pratiche) Che abbiamo usato: DFD --- DFD Un caso d’uso (passo) --- una funzione (Treno) Un caso d’uso --- uno stato (Ascensore) Un caso d’uso --- una transizione di stato (Ascensore) Una condizione --- un evento (Ascensore) Statechart --- DFD estesi (Ascensore) Statechart --- casi d’uso (Ascensore) Un passaggio è tipicamente caratterizzato dal fatto che la rappresentazione da cui si parte è SOSTITUITA dalla nuova rappresentazione

Modello Object-Oriented di Analisi (Esempio) Casi d’Uso Diagrammi di Sequenza Classi (attributi ed operazioni) Statecharts

Cosa è stato fatto nell’esempio dell’ascensore Fermare Partire Leggendo i passi nomeclasse Sensore Cabina Pulsante Tipo Stato Stato Tempo di reazione attributi Tempo di reazione Direzione Data controllo Data controllo Piano numero classe: una tipologia di oggetti, con propri attributi ed operazioni Sensore Piano Richiesta Porta

Cosa è stato fatto nell’esempio dell’ascensore Leggendo i passi Partire Leggendo l’operazione Pulsante Stato Tempo di reazione Direzione Data controllo illuminare( ) spegnere() operazioni

Cosa è stato fatto nell’esempio dell’ascensore Cosa è necessario per eseguire l’operazione “dimmi quali sono i pulsanti da illuminare” cardinalità Sensore Cabina Pulsante Tipo Stato Stato 1 1 Tempo di reazione Tempo di reazione Direzione Data controllo 0..1 Data controllo associazione illuminare( ) spegnere() attributi 1 Piano 1 numero classe: una tipologia di oggetti, con propri attributi ed operazioni 1 Sensore Piano 0..1 1 0..1 1..* Richiesta Porta

Sistematizzazione dei passaggi nel caso del modello di analisi object-oriented (Metodi-Pratiche) Che abbiamo usato: Casi d’uso (passo) --- classi, attributi Casi d’uso --- sequenza Sequenza --- classi e operazioni Precondizioni --- messaggi (operazioni) Che si possono usare: Sequenza --- Statechart Statechart --- classi, Statechart

Sistematizzazione degli incrementi modello di analisi object-oriented (ordinati) (Metodi-Pratiche) Che abbiamo usato: Operazioni --- associazioni, attributi Che si possono usare: Classe --- Statechart Classe --- Classe Classe --- associazioni Classe --- attributi Un incremento è tipicamente caratterizzato dal fatto che la rappresentazione da cui si parte è COMPLETATA dalla nuova rappresentazione

Diagramma delle Classi Sistematizzazione degli incrementi modello di analisi object-oriented (ordinati) (Metodi-Pratiche) Diagramma delle Classi Diagramma Casi d’Uso Diagrammi Sequenza incrementare

Relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

Sistema(i), requisiti del software: una visione d’insieme Rif. Esempio Treno Diminuire le code Con quale sistema? Cercare, Prenotare, Pagare etc. Con quale software? Ricerca Prenotazione Requisiti del sistema ove sistema = software + ambiente del software Requisiti del software

Sistema e Requisiti del Software: relazione fondamentale AND Ipotesi sull’ambiente circostante il Software) SODDISFA Requisiti del Sistema dove: Sistema=Software+Ambiente circostante al software Provare formalmente? (= Verificare)

Treno (Requisiti del Software: Casi d’uso AND Ipotesi sull’ambiente circostante il Software: almeno il 5% dei clienti possiede una carta di credito AND …) SODDISFA Requisiti del Sistema: le code devono diminuire del 10% rispetto alla situazione attuale)

Treno (Requisiti del Software: Casi d’uso AND Ipotesi sull’ambiente circostante il Software: almeno il 5% dei clienti possiede una carta di credito AND almeno il 30% dei clienti abituali userà il software AND …) SODDISFA Requisiti del Sistema: le code devono diminuire del 10% rispetto alla situazione attuale)

Ascensore (Requisiti del Software: casi d’uso + statechart + DFD esteso (formalizzabile) AND Ipotesi sull’ambiente circostante il Software: statechart dei vari dispositivi o software circostanti al software da sviluppare) (formalizzabile) SODDISFA Requisiti del Sistema: in condizioni normali di operatività, se un utente preme il pulsante, l’ascensore arriva mediamente in 1’ (proprietà formalmente esprimibile)

Organizzazione della Ingegneria del Sistema e dei Requisiti Richiesta del committente Desiderata del sistema Estrarre Requisiti del sistema Soddisfare Estrarre, dedurre, etc. Ipotesi ambiente del software Requisiti del software Ingegneria di sistema Ingegneria dei requisiti

Ascensore: un caso d’Ingegneria di Prodotto L’ingegneria di prodotto (una tipologia di ingegneria dei sistemi) si pone come finalità la costruzione di un prodotto nel perseguimento di determinati obiettivi Il punto chiave è la definizione e la valutazione delle alternative per sviluppare il prodotto Ad esempio, nel caso dell’ascensore è importante dare una risposta ai seguenti quesiti: quanti sensori è necessario avere, quale manutenzione dei componenti dovrebbe essere messa in opera, quante cabine devono essere disponibili etc.

Ingegneria di Processo Pressman propone come esempio di sistema industriale un sistema d’instradamento di scatole su nastro trasportatore Come decidere su qual è il software da sviluppare? Diagramma attività (UML)

Capitoli del Pressman per Ingegneria dei Requisiti – e dei Sistemi - 5, 6, 7, 8 (alcuni paragrafi verranno trattati in dettaglio più avanti parlando di test) Tranne 5.3, 5.4.2, 5.5, 5.6