Corso di Ingegneria del Software. Ingegneria dei Requisiti

Transcript

1 Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca

2 Ingegneria dei requisiti Sommario 1. Ingegneria dei requisiti 2. Concetto e definizione di requisito Il processo di ingegneria dei requisiti 5. L elicitazione dei requisiti 6. Bibliografia

3 Ingegneria dei requisiti Ingegneria dei requisiti Sommario 1. Ingegneria dei requisiti 2. Concetto e definizione di requisito Il processo di ingegneria dei requisiti 5. L elicitazione dei requisiti 6. Bibliografia

4 Ingegneria dei requisiti L ingegneria dei requisiti The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. F.P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1995, pag. 200

5 Ingegneria dei requisiti L ingegneria dei requisiti L ingegneria dei requisiti ha come obiettivo la costruzione di un ponte tra le esigenze dell utente e la progettazione e codifica effettuate dagli sviluppatori.

6 Ingegneria dei requisiti L ingegneria dei requisiti L ingegneria dei requisiti è l insieme di attività che in un progetto di sviluppo di software l analista esegue per individuare e comprendere cosa un software deve fare, da un lato, per assecondare le esigenze di un cliente ( requisiti utente ) dall altro lato, per fornire indicazioni puntuali per gli sviluppatori (in particolare quali servizi fornisce all utente ( requisiti del software ).

9 Ingegneria dei requisiti Strumenti di supporto alla ingegneria dei requisiti Figura:

10 Concetto e definizione di requisito Ingegneria dei requisiti Sommario 1. Ingegneria dei requisiti 2. Concetto e definizione di requisito Il processo di ingegneria dei requisiti 5. L elicitazione dei requisiti 6. Bibliografia

11 Concetto e definizione di requisito Concetto di requisito Requisiti utente (user requirements) descrizione (in linguaggio naturale e/o diagrammi), dei servizi che il sistema deve fornire e dei vincoli operativi (scritti per (e con) il cliente). Requisiti di sistema (system requirements) specificati mediante la stesura di un documento strutturato che descrive in modo dettagliato i servizi che il sistema software deve fornire il documento risultante costituisce un contratto tra cliente e fornitore

12 Concetto e definizione di requisito Concetto di requisito Esempio Requisito utente Il sistema software deve fornire un mezzo per rappresentare e visualizzare file esterni generati da altri tool Requisito di sistema 1.1 L utente deve avere la possibilità di definire il tipo dei file esterni 1.2 Ad ogni tipo di file esterno deve essere associato il tool che lo ha generato 1.3 Ogni tipo di file esterno deve essere rappresentato mediante una specifica icona sullo schermo 1.4 L utente deve avere la possibilità di definire l icona che rappresenta il tipo di file esterno 1.5 Quando l utente seleziona un icona che rappresenta un file esterno, deve poter essere eseguito il tool in grado di visualizzare il file

13 Concetto e definizione di requisito Definizione di requisito Requirement - IEEE Std (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).

14 Sommario 1. Ingegneria dei requisiti 2. Concetto e definizione di requisito Il processo di ingegneria dei requisiti 5. L elicitazione dei requisiti 6. Bibliografia

15 Funzionali Esprimono le funzioni (i servizi percepibili dall utente) che il software deve svolgere (e.g. l utente deve poter effettuare una certa ricerca in un database e stampare un report). Come il sistema software reagisce a specifici tipi di input e di come si comporta in situazioni particolari. Non funzionali Sono caratteristiche che il software deve possedere (vincoli sui servizi o funzioni offerti dal sistema) caratteristiche prestazionali - il tempo di stampa del report deve essere 10 sec caratteristiche di sicurezza - ogni utente non deve poter modificare dati di altri utenti caratteristiche di affidabilità - l intervallo tra 2 errori consecutivi deve essere 1 ora Relativi ai dati

18 Esempi di requisiti funzionali Il sistema software deve fornire un appropriato visualizzatore per i documenti memorizzati L utente deve essere in grado di effettuare ricerche sia sull intero insieme di basi di dati che su un loro sottoinsieme Ad ogni nuovo ordine deve essere associato un identificatore unico (Order ID)

19 Esempi di requisiti non funzionali Requisiti non funzionali descrivono le proprietà del sistema software in relazione a determinati servizi o funzioni e possono anche essere relativi al processo caratteristiche di efficienza, affidabilità, safety, ecc. caratteristiche del processo di sviluppo (standard di processo, uso di ambienti CASE, linguaggi di programmazione, metodi di sviluppo, ecc.) caratteristiche esterne (interoperabilità con sistemi di altre organizzazioni, vincoli legislativi, ecc.) Il tempo di risposta del sistema all inserimento della password utente deve essere inferiore a 10 sec I documenti di progetto (deliverable) devono essere conformi allo standard XYZ-ABC Il sistema software non deve rilasciare ai suoi operatori nessuna informazione personale relativa ai clienti, tranne nominativo e identificatore

20 Requisiti non funzionali Classificazione dei requisiti

21 Requisiti non funzionali Requisiti di qualità Specificano come il prodotto software deve comportarsi durante l uso (prestazioni, affidabilità, sicurezza, usabilità ecc) Requisiti di processo Specificano scelte di tipo organizzativo e metodologico,(metodi di produzione, modello di sviluppo da adottare, notazioni di progettazione (es. UML). Requisiti tecnologici Specificano scelte di tipo strumentale (tools di sviluppo, linguaggi di programmazione, RDBMS, ambiente tecnologico, OS). Requisiti di dominio Sono i vincoli imposti al software dal contesto o da fattori esterni (es. la configurazione hardware e software di base già posseduta dal cliente, gli standard grafici per le interfacce che usano gli utenti (il layout, i colori), i regolamenti o le prassi da rispettare, altri standard di lavoro in uso presso il cliente, ecc Requisiti inversi Esprimono le cose che il software non deve fare o consentire di fare (sicurezza)

22 Requisiti non funzionali Classificazione dei requisiti non funzionali Figura: c G. Kotonya and I. Sommerville 1998

23 Non funzionale Although the term non-functional requirement has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. (M. Glinz, On Non-Functional Requirements. RE 2007, pag. 21) However, there is no consensus, and it is in fact not clear, what a nonfunctional requirement really is. M. Glinz, Rethinking the Notion of Non-Functional Requirements. 3WCSQ 2005, Munich, Germany, Vol. II, pag. 55. Funzionale o non funzionale? Non esiste una chiara distinzione tra i due tipi di requisito. Un requisito può essere funzionale oppure no a seconda: livello di dettaglio da includere nel documento di specifica dei requisiti dal grado di fiducia che esiste tra il cliente e lo sviluppatore

24 Problemi con i requisiti Esempio Requisito: Il sistema assicura che i dati siano protetti da accessi non autorizzati Specificato in questo modo il requisito è non funzionale dato che non specificala funzionalità del sistena che deve essere fornita. Requisito: Il sistema include una procedura di autenticazione nella quale gli utenti si identificano usando una login e una password. Solo gli utenti autorizzati in questo modo possono accedere ai dati de sistema Espresso in questo modo il requisito sembra funzionale, dato che specifica la user login che è una funzione utente che deve far parte del sistema.

25 Problemi con i requisiti Esempio Requisito: Il sistema assicura che i dati siano protetti da accessi non autorizzati Specificato in questo modo il requisito è non funzionale dato che non specificala funzionalità del sistena che deve essere fornita. Requisito: Il sistema include una procedura di autenticazione nella quale gli utenti si identificano usando una login e una password. Solo gli utenti autorizzati in questo modo possono accedere ai dati de sistema Espresso in questo modo il requisito sembra funzionale, dato che specifica la user login che è una funzione utente che deve far parte del sistema.

26 Problemi con i requisiti Ambiguità Esempio 1: Il sistema software deve fornire un appropriato visualizzatore per i documenti memorizzati Significato di appropriato visualizzatore Interpretazione utente: visualizzatore specifico per ogni tipo di documento Interpretazione sviluppatore: generico visualizzatore di testo che mostri il contenuto del documento Incompletezza: i requisiti non includono la descrizione di tutte le caratteristiche richieste Inconsistenza: conflitti o contraddizioni nella descrizione delle caratteristiche del sistema Esempio Req 1: ogni form di input non deve contenere più di 5 campi editabili dall utente Req 2: nella form di input relativa all inserimento dei dati anagrafici l utente deve introdurre i seguenti dati: nome, cognome, anno di nascita, luogo di nascita, indirizzo, telefono, fax,

27 Requisiti relativi ai dati I requisiti riguardano di solito anche i dati che il sistema software dovrà elaborare. La descrizione dei dati deve identificare, tra l altro: i dati elaborati dal software, le relazioni tra i dati, i loro attributi e la loro associazione con le funzionalità i volumi di dati trattati i dati da caricare al primo avvio del software presso il cliente i livelli di sicurezza da assicurare ai dati gli eventuali collegamenti con basi dati esterne il glossario / dizionario dati eventuali vincoli sui formati dei dati

28 Il processo di ingegneria dei requisiti Ingegneria dei requisiti Sommario 1. Ingegneria dei requisiti 2. Concetto e definizione di requisito Il processo di ingegneria dei requisiti 5. L elicitazione dei requisiti 6. Bibliografia

29 Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti Obiettivo del processo Descrivere, in modo preciso e senza ambiguità, le esigenze del cliente (requisiti utente) cosa il software può fare per soddisfare queste esigenze (requisiti del software) dati i vincoli del progetto (budget, risorse, tempi, tecnologia, ecc.

30 Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti Attori Clienti (forniscono le esigenze, negoziano priorità e soluzioni, validano la specifica); Analisti (raccolgono, analizzano, specificano e gestiscono i requisiti).

31 Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti Attività del processo di ingegneria dei requisiti Elicitation and capturing of requirements vengono raccolti presso il cliente i requisiti (le sue esigenze). Requirement analysis i requisiti raccolti vengono analizzati per capirne la fattibilità e negoziarne le priorità. Requirement specification vengono specificati in un documento quali requisiti verranno soddisfatti dal software Requirement validation il documento di specifica dei requisiti viene validato dal cliente. Requirement management i requisiti possono evolvere durante lo sviluppo: queste modifiche vanno gestite.

32 Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti Output del processo Il documento di specifica dei requisiti, che fornisce ai progettisti tecnici e ai programmatori le indicazioni su quali funzioni deve fornire il software che devono realizzare e su ulteriori vincoli da rispettare nello sviluppo. Tecniche utilizzate per la raccolta e analisi dei requisiti Interviste Use Case Storyboards Modelli di analisi utilizzati Casi d uso Activity Diagrams Diagrammi degli Stati Data Flow Diagrams (DFD).

33 Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti Altre attività Dependencies between requirements Impact analysis of requirements Negotiation of requirements Quality assurance of requirements

34 Il processo di ingegneria dei requisiti Attività propedeutiche Studio di Fattibilità Precede le attività di ingegneria dei requisiti Analizza la fattibilità del progetto di sviluppo software, dal punto di vista tecnico, manageriale ed economico, al fine di decidere se avviare o no i lavori. Gara d appalto Allo studio può seguire una gara per appaltare il lavoro a un fornitore, che può essere individuato anche a seguito di una trattativa privata (procedura negoziata). In tal caso, una prima versione dei requisiti utente e quelli del software (eventualmente derivanti dallo Studio di fattibilità) sono inseriti nel Capitolato Tecnico, che dà al fornitore gli elementi base per poter effettuare l offerta tecnica ed economica al cliente.