36
4. Requisiti del Software Cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 4. Requisiti del Software 1 / 35

Cosa? Andrea Polinipolini/downloads/SE0809/IdS_04.pdf · Requisiti del Software 12 / 35. Categorizzazione dei Requisiti Requisiti non funzionali classificazione Si riferiscono a

  • Upload
    others

  • View
    17

  • Download
    2

Embed Size (px)

Citation preview

4. Requisiti del SoftwareCosa?

Andrea Polini

Ingegneria del SoftwareCorso di Laurea in Informatica

(Ingegneria del Software) 4. Requisiti del Software 1 / 35

Sommario

1 Generalità

2 Categorizzazione dei Requisiti

3 Documenti dei Requisiti

4 Esercizi

(Ingegneria del Software) 4. Requisiti del Software 2 / 35

Generalità

Sommario

1 Generalità

2 Categorizzazione dei Requisiti

3 Documenti dei Requisiti

4 Esercizi

(Ingegneria del Software) 4. Requisiti del Software 3 / 35

Generalità

Ingegneria dei Requisiti

Disciplina che si occupa di definire cosa un sistema debba fare, le sueproprietà essenziali ed i vincoli a cui deve rispondere. Scoprire,analizzare, documentare e verificare i requisiti sono attività delladisciplina della ingegneria dei requisiti

Studio di fattibilitàElicitazione ed analisi dei requisiti

Scoperta dei requisitiClassificazione ed organizzazione dei requisitiPrioritizzazione dei requisiti e negoziazioneDocumentazione dei Requisiti

ValidazioneGestione

Presenta forte interazione e comunicazione con il cliente. Dunque nonsoltanto un attività dagli aspetti tecnici ma forti implicazioni umane

(Ingegneria del Software) 4. Requisiti del Software 4 / 35

Generalità

Rilevanza dei Requisiti

La fase di gestione dei requisiti è probabilmente la più criticaProblemi inseriti in questa fase dello sviluppo sono i più costosi darimuovere.Studi rivelano che circa il 37% dei problemi, nello sviluppo disistemi software “challenging”, sono relativi alla fase dei requisiti

(Ingegneria del Software) 4. Requisiti del Software 5 / 35

Generalità

Requisiti

Caratteristiche e categorizzazione dei requisitiDocumenti dei requisitiProcessi e strumenti di elicitazione dei requisitiModelli di sistema

(Ingegneria del Software) 4. Requisiti del Software 6 / 35

Categorizzazione dei Requisiti

Sommario

1 Generalità

2 Categorizzazione dei Requisiti

3 Documenti dei Requisiti

4 Esercizi

(Ingegneria del Software) 4. Requisiti del Software 7 / 35

Categorizzazione dei Requisiti

Come specificare i requisiti

Differenti techniche possibiliInformali: usano tipicamente linguaggi naturaliSemi formali: usano notazioni grafiche per cui la semantica non èsempre precisamente definitaFormali: attraverso modelli matematici

Esempio: sistema di controllo apertura sbarra passaggio a livello

(Ingegneria del Software) 4. Requisiti del Software 8 / 35

Categorizzazione dei Requisiti

Requisiti utente vs. sistema

Requisiti utenteLinguaggio naturale (eventualmente più diagrammi)

Requisiti di sistemaPrecisa definizione di cosa sarà necessario implementare.Dettaglio su aspetti funzionali e vincoli operazionali

In generale definiti e destinati ad utenti differenti:

Requisiti utente - manager del cliente, utenti finali del sistema,ingegneri del cliente, architetti del sistema.

Requisiti di sistema - utenti finali del sistema, ingegneri del cliente,architetti del sistema, sviluppatori

(Ingegneria del Software) 4. Requisiti del Software 9 / 35

Categorizzazione dei Requisiti

Esempio: il sistema di gestione della biblioteca

Definizione di requisito utente:Il sistema deve tener traccia di tutti i dati richiesti dalla normativasul copyright

Requisiti di SistemaA seguito di una richiesta devono essere forniti all’utente i dettaglidell’account e della richiestaogni richiesta deve essere memorizzata nel sistema per almeno 5annitutti i dati devono poter essere indicizzati sulla chiave utente,materiale oggetto della richiesta, personale che ha gestito larichiestaLog di tutte le richiesta fatteSul materiale per cui sono previsti diritti di prestito devono essereprodotti resoconti mensili da inviare alle agenzie registrate.

(Ingegneria del Software) 4. Requisiti del Software 10 / 35

Categorizzazione dei Requisiti

Requisiti funzionali, non-funzionali

Requisiti funzionali:cosa deve fare il sistema. Come deve reagire agli stimoli esterni.Anche cosa il sistema non deve fare.

Requisiti non-funzionali:proprietà del sistema che devono essere soddisfatte.

Requisiti di dominio:Categoria trasversale - riguarda quei requisiti che derivanodirettamente dallo specifico dominio applicativo

Attenzione distinzione non sempre netta!!

(Ingegneria del Software) 4. Requisiti del Software 11 / 35

Categorizzazione dei Requisiti

Requisiti funzionali

Vengono descritte le funzionalità in dettaglio - input, output, eccezioni

Possono contenere differenti livelli di astrazione. E.g. il sistema digestione della biblioteca:

L’utente deve essere capace di cercare in tutti i cataloghi oselezionare un sottoinsieme di essiil sistema deve fornire all’utente appropriati visulizzatori al fine dipermettere la lettura all’interno del sistemaad ogni ordine deve essere allocato uno specifico ID

Attenzione a requisiti specificati in maniera imprecisa (requisitiambigui)

Completezza e consistenza dei requisiti

(Ingegneria del Software) 4. Requisiti del Software 12 / 35

Categorizzazione dei Requisiti

Requisiti non funzionaliclassificazione

Si riferiscono a proprietà del sistema (vedi 2a lezione)

Sono per certi versi critici tanto quanto i requisiti funzionali

Classificati in:Requisiti di ProdottoRequisti organizzativiRequisiti esterni

(Ingegneria del Software) 4. Requisiti del Software 13 / 35

Categorizzazione dei Requisiti

Requisiti non-funzionaliesempi

Product:L’intefaccia utente deve essere implementata come HTMLstandard 4.0 No frames o Java applet

Organizzativiil sistema di documentazione del processo di sviluppo deveessere conforme a quello definito in XYZStand-2007

Esternoil sistema non deve rendere publici dati personali

(Ingegneria del Software) 4. Requisiti del Software 14 / 35

Categorizzazione dei Requisiti

Requisiti non-funzionali

(Ingegneria del Software) 4. Requisiti del Software 15 / 35

Categorizzazione dei Requisiti

Requisiti non-funzionaliproblemi

Difficili da verificare!!

In generale i requisiti devono poter essere facilmente edeconomicamente verificati

Esempio: interfaccia utente e uso da parte di personale esperto

Spesso non è comunque facile definire metriche per la proprietà nonfunzionale

(Ingegneria del Software) 4. Requisiti del Software 16 / 35

Categorizzazione dei Requisiti

Requisiti non funzionaliesempi di metriche

Speed Tempo per transazione, tempi di rispostadimensioni K bytes, Numero di chip nella RAMFacilità d’uso Tempi di training, numero di frame di aiutoAffidabilità MTBF, probabilità di indisponibilità ...Robustezza Tempo di riavvio,

percentuale di eventi che causano erroriPortabilità Percentuale degli statement dipendenti dalla

piattaforma, numero di sistemi target.

(Ingegneria del Software) 4. Requisiti del Software 17 / 35

Categorizzazione dei Requisiti

Requisiti di dominio

Requisiti che sono del tutto ovvi a persone che lavorano nel dominio(vedi esistenza di leggi giuridiche, regola matematica, legge fisica,etc.)

Sono spesso difficili da capire per chi non ha conoscenze nel dominio

Altrettanto spesso sono considerati ovvi dal cliente e non vengono“manifestati”

(Ingegneria del Software) 4. Requisiti del Software 18 / 35

Categorizzazione dei Requisiti

Requisiti utente

Specificano il comportamento del sistema in modo comprensibile alcliente. Si occupano del comportamento osservabile del sistema perl’utente e non dovrebbero contenere specifiche di design.

Tipici problemi:

Mancanza di chiarezza - verbosità vs. precisioneLe diverse tipologie di requisiti sono mischiati tra loroMolti requisiti vengono specificati come un singolo requisito

(Ingegneria del Software) 4. Requisiti del Software 19 / 35

Categorizzazione dei Requisiti

Requisiti utenteesempio

Griglia di supporto: nell’assistere l’utente nel posizionamento delleentità in un diagramma, l’utente può attivare una griglia, che forniscasia i centimetri che i pollici, attraverso un’opzione nel pannello dicontrollo. Inizialmente la griglia è disattivata. La griglia può essereattivatà/deattivatà in qualsiasi momento. Un opzione griglia verràfornita nella vista adatta-a-dimensioni ma il numero di linee mostratesarà ridotto per evitare di riempire diagrammi più piccoli con linee digriglia.

Problemi?

(Ingegneria del Software) 4. Requisiti del Software 20 / 35

Categorizzazione dei Requisiti

Requisiti utenteesempio

Molti differenti tipi di requisiti sono mischiati nella prima frase:funzionali: la griglianon funzionali: centimetri / pollicinon funzionale: dove il meccanismo si trova

Nota: Troppi dettagli tecnici limitano il raggio di azione deglisviluppatori che invece potrebbero fornire soluzioni innovative.

(Ingegneria del Software) 4. Requisiti del Software 21 / 35

Categorizzazione dei Requisiti

Requisiti utenteesempio

L’editor deve fornire una funzionalità griglia dove una matrice di lineeorizontali e verticali vengano visualizzate come background della vistanella finestra dell’editor. La griglia dovrebbe essere passiva el’allineamento alla griglia deve essere fatto su iniziativa dell’utente.

Motivazione: una griglia aiuta l’utente nella creazione di un diagrammapiù pulito con entità ben spaziate. Una griglia attiva può essere utilema può creare effetti indesiderati come posizionamenti imprecisi.L’utente è la persona più appropriata a decidere il posizionamento

Sorgente: Micky Mouse

(Ingegneria del Software) 4. Requisiti del Software 22 / 35

Categorizzazione dei Requisiti

Requisiti utenteesercizio

Il sistema di gestione della biblioteca intende fornire un supporto allagestione dei “conti” che in particolare riporti tutti i pagamenti fatti dagliutenti del sistema. I gestori del sistema devono poter configurare ilsistema in modo da poter accordare sconti ad utenti regolari.

Problemi?

(Ingegneria del Software) 4. Requisiti del Software 23 / 35

Categorizzazione dei Requisiti

Requisiti utentereccomandazioni

Definite un formato standard per la definizione dei requisitiUtilizzate linguaggio consistentemente - attenzione alle parole“deve”, “dovrebbe”Utilizzate meccanismi di evidenziazione del testoNon usare, per quanto possibile, gergo tecnico del dominioinformatico.

(Ingegneria del Software) 4. Requisiti del Software 24 / 35

Categorizzazione dei Requisiti

Requisiti di sistema

Aggiungono dettagli per capire come i requisiti utente possono essereeffettivamente raggiunti dal sistema. Anche questi si dovrebberolimitare al comportamento osservabile e non contenere scelte didesign. Ma . . .

Potreste aver bisogno di definire un’architettura iniziale per strutturare irequisiti.In molti casi il sistema interagirà con sistemi pre-esistenti che dunquein un certo qual modo forzano scelte progettualiavete bisogno di certificare il sistema ad esempio rispetto a norme disafety

(Ingegneria del Software) 4. Requisiti del Software 25 / 35

Categorizzazione dei Requisiti

Requisiti di sistema

Aggiungono dettagli per capire come i requisiti utente possono essereeffettivamente raggiunti dal sistema. Anche questi si dovrebberolimitare al comportamento osservabile e non contenere scelte didesign. Ma . . .

Potreste aver bisogno di definire un’architettura iniziale per strutturare irequisiti.In molti casi il sistema interagirà con sistemi pre-esistenti che dunquein un certo qual modo forzano scelte progettualiavete bisogno di certificare il sistema ad esempio rispetto a norme disafety

(Ingegneria del Software) 4. Requisiti del Software 25 / 35

Categorizzazione dei Requisiti

Requisiti di sistema

Problemi nell’uso di linguaggio naturale:si basa sulla comune comprensione dei concetti nel sistematroppo flessibiledifficile modularizzare requisiti scritti con linguaggio naturale

Uso di notazioni semi-formali o formaliLinguaggio Naturale StrutturatoLinguaggi di Descrizione ProgettualeNotazioni graficheSpecifiche Matematiche

(Ingegneria del Software) 4. Requisiti del Software 26 / 35

Categorizzazione dei Requisiti

Formato definizione requisiti

Possibili informazioni da riportare in un formato strutturato per laspecifica di requisiti:

[ID]Nome: [Nome Mnemonico]The [System] Must/Should/Could/Want [function]Description: . . .Source: . . .

Criteri MoSCoW

(Ingegneria del Software) 4. Requisiti del Software 27 / 35

Categorizzazione dei Requisiti

Specifica dei punti di interazione

Praticamente tutti i sistemi software si trovano ad interagire con altrisistemi software. Le interfacce di interazione devono essere definiteformalmente:

Application Programming Interface (API)Strutture datiRappresentazione dei dati

(Ingegneria del Software) 4. Requisiti del Software 28 / 35

Documenti dei Requisiti

Sommario

1 Generalità

2 Categorizzazione dei Requisiti

3 Documenti dei Requisiti

4 Esercizi

(Ingegneria del Software) 4. Requisiti del Software 29 / 35

Documenti dei Requisiti

documento dei requisiti software

Il documento dei requisiti software è ciò che deve essere implementatodagli sviluppatori. Contiene generalmente sia requisiti utente che disistema.

Differenti utenti . . . differenti “requisiti”

Formato dipendente anche da processo adottato!

Esistono standard per la specifica dei requisiti di sistema.

(Ingegneria del Software) 4. Requisiti del Software 30 / 35

Documenti dei Requisiti

IEEE/ANSI 830-1998

Suggerisce la seguente struttura:Introduction

1 Scopo del documento dei requisiti2 Scopo del prodotto3 Definizione, acronimi ed abbreviazioni4 Riferimenti5 Overview dell’intero documento

Descrizione generale1 Prospettive sul prodotto2 Funzioni del prodotto3 Caratteristiche degli utenti4 vincoli generali5 Assunzioni e dipendenze

Requisiti specificiAppendiciIndici

(Ingegneria del Software) 4. Requisiti del Software 31 / 35

Documenti dei Requisiti

Contenuto generale

1 Prefazione2 Introduzione3 Glossary4 Definizione dei requisiti utente5 Architettura del sistema6 Definizione dei requisiti di sistema7 Modelli del sistema8 Evoluzione del sistema9 Appendici

10 Indici

(Ingegneria del Software) 4. Requisiti del Software 32 / 35

Documenti dei Requisiti

Possibili alternative

Il caso della programmazione estrema (eXstreme Programming - XP)

(Ingegneria del Software) 4. Requisiti del Software 33 / 35

Esercizi

Sommario

1 Generalità

2 Categorizzazione dei Requisiti

3 Documenti dei Requisiti

4 Esercizi

(Ingegneria del Software) 4. Requisiti del Software 34 / 35

Esercizi

Guida Turistica

Si vuole realizzare un sistema di supporto al turista in visita ad unacerta zona. Il sistema prevedere la dotazione del turista in visita di unpalmare da ritirarsi presso appositi uffici dell’APT. Il sistema dovrebbefungere da tutor personale e permettere al fruitore di ricevereinformazioni sui monumenti artistici e culturali da poter visitare nellesue immediate vicinanze. Il sistema deve poter anche permettere diaccedere alla lista dei ristoranti vicini. È auspicabile che la definizionedella lista delle attrattive sia anche fatta in base a criteri inseritidall’utente. Il sistema potrebbe fungere anche da sistema dipagamento dei servizi ottenuti presso gli esercizi convenzionati. Inquesto modo non sarebbe nesessario al turista fornire più volte la cartadi credito e portare con se contanti. Il palmare in dotazione andrebbead identificare il turista quando in visita e in un certo modo sarebbepreposto a rendere la visita il più possibile semplice e piacevole.

(Ingegneria del Software) 4. Requisiti del Software 35 / 35