Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
PubblicatoAbelie Viviani Modificato 10 anni fa
1
Analisi dei Requisiti (Requirements Engineering) Seminario RE Università degli Studi di Padova, 12 Gennaio 2004
2
Sommario Università degli Studi di Padova, 12 Gennaio 2004 Cosè il Requirements Engineering Contesto di riferimento Definizione di requisito Le attività di analisi dei requisiti
3
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements… No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later. F.Brooks, 1987 Cosè il Requirements Engineering Università degli Studi di Padova, 12 Gennaio 2004
4
Cosè il Requirements Engineering Università degli Studi di Padova, 12 Gennaio 2004 Il costo di una generica modifica è più che proporzionale rispetto allo stato di avanzamento del progetto Costo della modifica Requir. Prog. Realizzaz. Test Esercizio
5
Cosè il Requirements Engineering Università degli Studi di Padova, 12 Gennaio 2004 Alcune cause di insuccesso dei progetti di S.I.: Carenze nel processo gestionale dei requisiti Carenze nel processo gestionale dei requisiti Carente processo di comunicazione allinterno del team di progetto (Cliente, Fornitore) Carente coinvolgimento delle risorse del Committente (utenti operativi e manager) Carente gestione delle risorse umane Carente controllo del budget di progetto
6
Cosè il Requirements Engineering Università degli Studi di Padova, 12 Gennaio 2004 Mancato soddisfacimento dei requisiti Mancato soddisfacimento dei requisiti Mancato raggiungimento degli obiettivi di performance del Committente Scarso utilizzo del sistema realizzato Risorse spese sul progetto (tempo,costi,…) che non trovano riscontro nella qualità del risultato Alcune cause dinsoddisfazione sul risultato dei progetti di S.I.:
7
Cosè il Requirements Engineering Università degli Studi di Padova, 12 Gennaio 2004 E il processo in cui ciò che deve essere fatto viene individuato, modellizzato e comunicato E una disciplina per sviluppare specifiche complete, consistenti ed esenti da ambiguità, che servono come riferimento per laccordo, tra le parti coinvolte, su quanto il sistema deve fare Le specifiche vertono su funzioni, interfacce, prestazioni, vincoli, regole di gestione dei processi, ruoli nella gestione dei processi
8
Cosè il Requirements Engineering Università degli Studi di Padova, 12 Gennaio 2004 Perché è importante il Requirements Engineering: Aiuta nella tempestiva individuazione degli errori Spinge il Committente ad identificare, articolare e rivedere i requisiti Supporta laccordo tra il progettista ed i futuri utenti Serve come riferimento base per le verifiche e validazioni della rispondenza della progettazione e dei risultati finali (test) Incrementa la comprensione allinterno del team che progetta il nuovo sistema
9
Contesto di riferimento Università degli Studi di Padova, 12 Gennaio 2004 Ambiente Operativo Necessità Specifica requisiti Progettazione Concettuale Requirements Engineering Sviluppo e Test Specifica Tecnica Feedback Analisi sistema Disegno del SIstema Progettazione Tecnica Feedback progettazione Feedback Sviluppo/test Esercizio Prodotto Feedback esercizio
10
Definizione di Requisito Università degli Studi di Padova, 12 Gennaio 2004 Cosè un requisito: Una condizione o prestazione necessaria ad un utente per risolvere un problema o raggiungere un obiettivo Una condizione o capacità di fare che deve essere conseguita o posseduta da un sistema o da un suo componente per adempiere ad un contratto, uno standard, una specifica o altro documento formalmente imposto
11
Definizione di Requisito Università degli Studi di Padova, 12 Gennaio 2004 Tipologie di requisito: Vincoli Obiettivi, regole generali o limitazioni Assunzioni, influenze esterne Funzionali Cosa il sistema deve fare e quali dati deve trattare (funzionalità del prodotto, azioni che deve svolgere,…) Esigenze dellutenza (funzionalità automatiche,…) Non Funzionali Requisiti di performance (tempi di risposta, durata max delle elaborazioni,…) Requisiti organizzativi/operativi (ambiente operativo, condizioni operative dellutenza,…) Requisiti di sicurezza (protezione da accessi non autorizzati,…)
12
Le attività di Analisi dei Requisiti Università degli Studi di Padova, 12 Gennaio 2004 Individuazione dei requisiti Identificare il dominio del processo in esame Individuare gli attori principali Rilevare le necessità ed i vincoli Rilevare i sistemi che supportano il processo --- > Fornisce lelenco dei requisiti del sistema
13
Le attività di Analisi dei Requisiti Università degli Studi di Padova, 12 Gennaio 2004 Carenze nellindividuazione dei requisiti Influenzano tutte le fasi successive, fino al collaudo Producono, in momenti successivi, modifiche ai requisiti che hanno impatto crescente sul progetto in funzione del ritardo con cui si individuano
14
Le attività di Analisi dei Requisiti Università degli Studi di Padova, 12 Gennaio 2004 Indipendentemente dalla tipologia, i requisiti individuati possono essere: Esplicitiespressi sotto forma di documentazione o richieste formulate e documentate Implicitiinsiti nelle pratiche di business Esternirequisiti di legge Inespressiconseguenti ad altri fattori quali la connessione del sistema con altri, lintegrazione fra componenti
15
Le attività di Analisi dei Requisiti Università degli Studi di Padova, 12 Gennaio 2004 Specificazione I requisiti devono essere strutturati e descritti compiutamente Deve essere data particolare importanza alla corretta documentazione per la successiva fase di progettazione Non è sufficiente avere una buona conoscenza del dominio, occorre avere anche buone competenze tecniche --- > Fornisce una descrizione dettagliata dei servizi che saranno resi dal sistema
16
Le attività di Analisi dei Requisiti Università degli Studi di Padova, 12 Gennaio 2004 Attributi di una buona Specifica dei Requisiti: Non ambigua Completa, consistente, concisa, organizzata Comprensibile Verificabile Modificabile Tracciabile Testabile
17
Le attività di Analisi dei Requisiti Università degli Studi di Padova, 12 Gennaio 2004 Esempio Definizione requisito 1.Il software deve permettere di accedere archivi esterni creati da altri strumenti Specifica requisito 1.1 Deve essere fornito allutente un mezzo per identificare il tipo di file esterni a cui accedere 1.2Ogni file esterno può avere associato un tool da utilizzare nel caso specifico 1.3Ogni file esterno deve essere rappresentato in visualizzazione per mezzo di unicona 1.4Quando lutente seleziona unicona che presenta un file esterno, leffetto della selezione deve essere quello di applicare il tool associato al file esterno rappresentato dallicona medesima
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.