Schema del Corso. Requirements Engineering: Natural Language Requirements Elicitation, Specification and Quality Evaluation Part II

Transcript

1 Requirements Engineering: Natural Language Requirements Elicitation, Specification and Quality Evaluation Part II Giuseppe Lami Ph.D. System & Software Evaluation Centre Istituto di Scienza e Tecnologie dell Informazione CNR, Pisa Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA (USA) giuseppe.lami@isti.cnr.it Tel Schema del Corso Software Qualità del Software Processo Software Software Project Management Ingegneria del Software Misurare la Qualità del Software Requisiti Software Requirements Engineering Elicitation dei Requisiti: Tecniche & Tools Specifica dei Requisiti: Tecniche & Tools Qualità dei Requisiti Esperienza con i Requisiti Software Test Finale 1

2 Impatto delle attività di RE Esistono molti studi che testimoniano come la causa dei maggiori problemi in un progetto software è collegabile ai requisiti I difetti software costano all economia USA 59,5 miliardi di $, lo 0,6% del PIL Uno studio dello Standish Group rivela che le principali cause di progetti in difficoltà sono: Carenza di coinvolgimento dell utente (12,8%),, requisiti incompleti (12,3%), requisiti che cambiano (11,8%) Uno studio dell ESI condotto su un campione di 3800 organizzazioni in 17 stati europei mostra come il 50% dei problemi è relativo all area della specifica dei requisiti Un recente studio (2002) su 12 aziende software UK mostra che i soli problemi dovuti ai requisiti rappresentano il 48% del totale Un studio di B. Bohem mostra che, dato 1$ il costo della soluzione di un errore nella fase di definizione dei requisiti, tale costo diventa 200 5$ nella fase di design, 10$ in quella di codifica, $ nel testing $ dopo la delivery 50 0 req. design coding testing after-del. Requirements Engineering (RE) Definizione: processo che include tutte le attività per creare e mantenere un documento di requisiti. Le attività di base del RE sono: Studio di fattibilità del sistema Elicitation e analisi dei requisiti Specifica e documentazione dei requisiti Validazione dei requisiti [Sommerville 2001] Definizione: processo che, a livello di progetto, raccoglie, documenta e gestisce i requisiti per l intera durata del progetto [Aurum, Wohlin 2005] 2

3 Requirements Engineering Principali fasi: Elicitation Studi di fattibilità Specifica modellizzazione Negoziazione Analisi di qualità Analisi dell impatto Prioritizzazione Change management Che cos è un requisito software A feature that the system must have or a constraint it must satisfy to be accepted by the client [Bruegge, Dutoit] 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, A documented representation of a condition or capability as in 1) or2). [IEEE ] 3

4 Classificazioni dei requisiti Funzionali: che cosa il sistema farà Non-funzionali: vincoli sui tipi di soluzioni che verranno sviluppate in conformità ai requisiti funzionali (es. accuratezza, performance, security, modificabilità, ) Goal level: relativi agli obiettivi di business Domain level: relativi all area del problema Product level: relativi al prodotto Design level: che cosa costruire Primari: ottenuti (attraverso l elicitation) dagli stakeholders Derivati: derivati da quelli primari Business vs. tecnici di prodotto vs. di processo: business needs vs. come le persone interagiranno con il sistema Basati sul ruolo: cliente, utente, sistema, security Requirements Engineering Key Points Impatto dei requisiti sul destino di un progetto Attività di base del requirements engineering Requisiti definizione e classificazione 4

5 Elicitation dei Requisiti Definizione: the process of seeking, uncovering, acquiring, and elaborating requirements for computer based systems [Zowghi 2005] Using systematic techniques to proactively identify and document customer and end-user needs [CMMI] Il Processo di Elicitation dei Requisiti Scopo: raccogliere, elaborare e tracciare le esigenze del cliente in evoluzione e i requisiti lungo tutto il ciclo di vita del prodotto e/o servizio in modo da stabilire una baseline di requisiti che serva come base per la definizione dei work product necessari. Risultati attesi: Comprendere il dominio applicativo (i.e. l ambiente dove il sistema opererà) Identificare le fonti (stakeholders, documenti sui sistemi attuali, processi di business, manuali, report, ); Selezionare tecniche, approcci e tool da usare Ottenere i requisiti e le richieste dal cliente e dagli altri stakeholder; Comprendere le aspettative del cliente Trovare un accordo sui requisiti Stabilire una baseline dei requisiti del cliente Gestire i cambiamenti ai requisiti del cliente Definire un meccanismo per le query del cliente WP in input: committment/agreement, change request, customer request, customer requirements WP in output: customer requirements, change control record, analysis report 5

6 Esiste una interpretazione comune? La descrizione del prodotto è corretta? 6

7 Tecniche e tool per l elicitation Interviste Questionari Introspezione Card sorting Brainstorming JAD (Joint Application Development) Requirements workshop Etnografia Prototipazione Approcci Goal-based Scenari/Use Case Viewpoint 7

8 Tecniche e tool per l elicitation (cont.) Interviste: Tecnica tradizionale Molte informazioni in breve tempo Efficacia dipendente dall abilità dell intervistatore Strutturate: Insiemi predeterminati di domande Criticità: quali domande, quando e a chi farle Pros: rigorose e efficaci Contra: limitazione all investigazione di nuove idee Non strutturate: Conversazioni informali dove l intervistatore controlla solo la direzione della discussione Rischio di escludere interi aspetti e di sovrabbondare di dettagli su altri Si adattano bene alla fase esplorativa Tool: Volere: fornisce template per le interviste [Robertson, Robertson (1999) Mastering the requirmeents process, Addison Wesley: UK] Tecniche e tool per l elicitation (cont.) Questionari Domande aperte o chiuse Criticità: glossario condiviso Formulare le domande per evitare il rischio di risposte ridondanti o troppo lunghe Pros: ottenere in breve tempo informazioni da diversi stakeholder Contra: limtazioni sulla profondità delle informazioni raccolte Utili anche come check-list per assicurare di considerare tutti i punti importanti Introspezione All analista viene richiesto di sviluppare i requisiti sulla base do ciò che egli crede gli utenti e gli altri stakeholders vogliono e hanno bisogno Meglio se usata come punto di partenza e insieme ad altre tecniche 8

9 Tecniche e tool per l elicitation (cont.) Card sorting Viene richiesto agli stakeholder di ordinare in gruppi sulla base della propiria comprensione un mazzo di carte sulle quali sono stati riportati i nomi di entità del dominio Si chiede il motivo dell ordinamento fatto Tutte le entità del dominio devo essere incluse nelle carte Necessità di conoscenza del dominio da parte di tutti gli attori coinvolti Tool CRC Brainstorming Meeting dove partecipano rappresentanti di tutti gli stakeholders Discussione informale dove si generano più idee possibile senza focalizzarsi su nessuna di esse e senza scendere nei dettagli Utile per produrre un iniziale misson statement per il progetto e il sistema da realizzare Libero e informale, aiuta a trovare soluzioni nuove e innovative Tecniche e tool per l elicitation (cont.) JAD (Joint Application Development) Meeting fra tutti gli stakeholders ma la discussione verte non solo sui problemi da risolvere ma anche sulle possibili soluzioni a quei problemi Decisioni possono essere prese rapidamente Sessioni strutturate con step, azioni e ruoli definiti Etnografia Studio delle persone nel proprio ambiente naturale. Prevede che l analista partecipi attivamente o passivamente alle normali attività degli utenti su un intervallo temporale ampio per raccogliere informazioni su come essi operano Utili per considerare fattori dipendenti dal contesto come l usabilità e le interazioni fra gli utenti finali Efficace quando il motivo di un nuovo sistema è il risultato di problemi con gli attuali processi e procedure 9

10 Tecniche e tool per l elicitation (cont.) Prototipazione Si forniscono agli stakeholder prototipi del sistema finale per raccogliere informazioni dettagliate e feedback di rilievo. Utile quando si sviluppano interfacce uomomacchina gli stakeholders non hanno familiarità con le soluzioni disponibili Si sviluppano nuovi sistemi per applicazioni del tutto nuove Gli stakoholder sono spinti ad avere un ruolo attivo nello sviluppo dei requisiti Rischio: affezionarsi a un prototipo e non voler andare avanti Approcci goal-based Gli obiettivi di alto livello (high-level goal) che rappresentano gli obiettivi per il sistema sono decomposti (usando le relazioni AND e OR) e elaborati (con domande come e perché ) in sotto-obiettivi che man mano vengono raffinati fino a quando i requisiti sono ottenuti Riesce a rappresentare relazioni dettagliate fra entità del dominio, requisiti e obiettivi del sistema) Rischio: propagazione fino nei requisiti di eventuali errori negli obiettivi di alto livello Tool: F3, KAOS meta- model, framework i* Tecniche e tool per l elicitation (cont.) Scenari / Use Case Molto usati in req. elicitation Sono narrazioni e descrizioni specifiche di processi attuali e futuri che includono azioni e interazioni fra il sistema e l utente Occorre raccogliere tutte lo possibili eccezioni a ciascuno step Tool e tecniche specifiche: CREWS l Ecritoire, The Inquiry Cycle, SBRE, Scenario Plus USE CASE # < the name is the goal as a short active verb phrase> Goal in Context <a longer statement of the goal in context if needed> Scope & Level <what system is being considered black box under design> <one of: Summary, Primary Task, Sub-function> Preconditions <what we expect is already the state of the world> Success End Condition <the state of the world upon successful completion> Failed End Condition <the state of the world if goal abandoned> Primary, Secondary Actors <a role name or description for the primary actor>. <other systems relied upon to accomplish use case> Trigger <the action upon the system that starts the use case> Description Step Action 1 <put here the steps of the scenario from trigger to goal delivery, and any cleanup after> 2 <...> 3 Extensions Step Branching Action 1a <condition causing branching> : <action or name of sub-use case> Sub-Variations Branching Action 1 <list of variations> 10

11 Tecniche e tool per l elicitation (cont.) View point Lo scopo è quello di modellare il dominio da diverse prospettive per sviluppare una descrizione completa consistente del sistema Un sistema può essere descritto in termini della sua operatività, interfacce, implementazione Contra: non permettono di rappresentare facilmente i requisiti non funzionali Troppi viewpoint portano ad una massa di dati non gestibile Tool: VORD (Viewpoint-oriented Requirements Definition) Tecniche vs. attività dell elicitation interviste JAD etnografia prototip. goal-based scenari comprendere il dominio X X X X X X identificare fonti di requisiti X X X X X analizzare gli stakeholder X X X X X X X selezionare tecniche e approcci X X viewpoint eliciting dei requisiti X X X X X X X 11

12 Tecniche complementari e altrenative interviste JAD etnografia prototip. goal-based scenari viewpoint interviste A A A C C C JAD A A C C C C etnografia A A C C A A prototip. A C C C C C goal-based C C C C C C scenari C C A C C A viewpoint C C A C C A Requirements Elicitation Key Points Definizione del processo di Elicitation dei requisiti Tecniche per l elicitation dei requisiti 12

13 Schema del Corso Software Qualità del Software Processo Software Software Project Management Ingegneria del Software Misurare la Qualità del Software Requisiti Software Requirements Engineering Elicitation dei Requisiti: Tecniche & Tools Specifica dei Requisiti: Tecniche & Tools Qualità dei Requisiti in Linguaggio Naturale Esperienza con i Requisiti Software Test Finale Specifica dei Requisiti La prima rappresentazione dei requisiti del cliente è sempre in linguaggio naturale perché per la loro realizzazione devono essere coinvolti diversi stakeholders. Il linguaggio naturale ha il vantaggio di essere comprensibile da tutti ma lo svantaggio di essere intrinsecamente ambiguo. Quando i requisiti necessitano di essere maggiormente dettagliati, possono essere rappresentati in modo più tecnico: Modelli di sistema (UML) Metodi formali Una recente indagine indica che 79% dei documenti di requisiti sono scritti in linguaggio naturale, 16% in linguaggio naturale strutturato e solo i 5% usando linguaggi formalizzati. [Mich 2002] 13

14 La qualità dei requisiti in linguaggio naturale Definiamo un modello di qualità formato dalle caratteristiche di qualità importanti per i requisiti: Correttezza Non ambiguità Completezza Consistenza Importanza Stabilità Verificabilità Modificabilità Tracciabilità Comprensibilità Fattibilità Livello di dettaglio adeguato Caratteristiche di qualità dei requisiti - Definizioni Correttezza: i requisiti che sono implementati devono riflettere il comportamento atteso. Le cose stabilite da un requisito devono essere ritrovate nel sistema finale Non ambiguità: il requisito deve soltanto avere una possibile interpretazione. L ambiguità può dipendere dallo stakeholder Completezza: tutti gli elementi importanti che sono rilevanti per soddisfare l utente devono essere considerati Consistenza: I requisiti devo essere consistenti verso loro stessi e verso i constraint importanti Valutati per importanza: ogni requisito deve essere valutato in termini di importanza, cioè di quanto esso è essenziale per il successo del progetto Stabilità: facilità che un requisito cambi Verificabilità: tutti i requisiti devono essere verificabili, cioè esiste un processo per controllare se il requisito è soddisfatto o no 14

15 Caratteristiche di qualità dei requisiti - Definizioni Modificabilità: tutti i requisiti devono essere modificabili. Fattibilità: tutti i requisiti devono essere implementati con le risorse, la tecnologia e budget. disponibili Giusto livello di dettaglio: l informazione contenuta nel requisito permette di ottenere la giusta comprensione e di iniziare l implementazione La testabilità del software IEEE Standard Glossary La testabilità del software è considerata sia dal punto di vista costruttivo che dei requisiti. (a) the degree to which the system or component facilitates the establishment of a test criteria and the performance of tests to determine whether those criteria have been met. (b) the degree to which a requirement is stated in terms that permit establishment of test design (and subsequently test cases) and execution of tests to determine whether the requirements have been met. 15

16 Requisito testabile Quando un requisito in linguaggio naturale può essere considerato testabile? Eseguire un test significa eseguire una funzione e osservare il verificarsi di un evento. Poiché i requisiti descrivono gli eventi accettabili che un sistema può generare, allora l evento specificato nel requisito deve essere eseguibile e osservabile Definizione di verifiability dello standards IEEE 830 IEEE Recommended Practice for Software Requirements Specifications : there exist some finite cost-effective process [executable] with which a person or machine can check that the software product meets the requirement [observable]. Origini dei problemi di testabilità Cause intra-requisito: dipende da come è scritto il requisito. Per esempio l uso di termini vaghi, imprecisi, frasi troppo complesse e mal strutturate. Cause inter-requisiti: inconsistenze semantiche (contraddizioni) Inconsistenze linguistiche (entità indicate con diverse terminologie, incompletezze, difetti nella struttura del documento dei requisiti requisiti mal posizionati) Cause extra-requisito Non implementabilità tecnica Barriere dovute ai formalismi usati 16

17 Migliorare la testabilità Tecniche Restrittive Tecniche restrittive: si limita il grado di libertà nello scrivere i requisiti per ridurne il grado di ambiguità. Requisiti più precisi ma meno comprensibili Classi di tecniche: Metodi basati su linguaggio naturale semplificato Metodi basati su linguaggio naturale strutturato Approcci basati sugli scenari Metodi basati sul Linguaggio semplificato 1986 Boeing ASD Simplified Technical English Standard di scrittura per documentazione tecnica di manutenzione aerospaziale Vocabolario, grammatica e stile di scrittura Iniziative per la scrittura dei requisiti: Attempt Controlled English (ACE), sottoinsieme dell inglese abbastanzasemplice da evitare ambiguità ma che permette di definre requisiti con lo stesso livello di rigore dei linguaggi di specifica formali Natural Language Processing (NLP) è una tecnica che controlla sui requisiti in linguaggio naturale il rispetto di regole definite come il vocabolario limitato, lo stile di costruzione delle frasi. Ogni frase è valutata con un ambiguity rate Linguaggio strutturato: basato sulla definizione l uso di regole o template per la strutturazione delle descrizioni dei requisiti 17

18 Metodi basati sugli Scenari Uno scenario corrisponde ad una sequenza temporale singola di interazioni fra componenti di un sistema Testing funzionale si può basare sulla riproduzione delle condizioni degli scenari per verificare la conformità del comportamento del sistema Migliorare la testabilità Tecniche Induttive Si parte dall identificazione di problemi diffusi e si definiscono raccomandazioni e linee guida per la stesura dei requisiti Ogni azienda ha le proprie regole per un buono stile di scrittura dei requisiti 18

19 Migliorare la testabilità Tecniche Analitiche Si basano sull analisi dei documenti di requisiti e sulla individuazione dei difetti Basate su tool automatici Tool: QuARS, ARM, LOLITA,TIGER PRO Manuali Formal Inspection Formal Inspection Conosciute dopo un articolo di Fagan (1976) che ha definito e strutturato l attività di revisione di documenti facendola diventare una metodologia Processo di Formal Inspection: Inizio dell ispezione: pianificazione delle risorse e dei tempi Ricerca dei difetti: analisi e report dei difetti trovati Raccolta dei difetti: i difetti vengono discussi e raccolti in una lista definitiva Correzione: viene richiesto agli autori dei documenti di correggere i difetti La fase più critica è la raccolta difetti che è sostenuta da tecniche di Reading 19

20 Reading Techniques L obiettivo è guidare l ispettore nell acquisizione di una comprensione più approfondita del prodotto ispezionato attraverso una serie di passi e procedure Alcune tecniche: Ad hoc: nessun supporto tecnico, solo l esperienza e le conoscenze dell ispettore Basate su check-list: le check-list servono per indicare all ispettore quali argomenti e aspetti specifici andare a considerare quanto legge il documento Basate su scenari: aiutano a concentrarsi su specifici tipi di difetti o proprietà del documento. Valutazione comparativa delle tecniche di miglioramento della testabilità dei requisiti Technique Cause of Poor Testability Intra-req. Inter-req. Extra-req. Analytic Tool based Manual A B C A C B Inductive A B C Simplified NL A C C Restrictive Structured NL B B B Behavioral B A B 20

21 Tecniche linguistiche per l analisi dei requisiti in linguaggio naturale Problemi affrontabili con l uso di tecniche di Natural Language Understanding : Espressiveness: the incorrect understanding of the meaning of the requirements, specifically ambiguities and poor readability. Consistency: the presence of semantic contradictions in the NL requirements documents. Completeness: the lack of necessary information QuARS sentences.txt Syntax Parser Parsed.txt Lexical Analysis Syntactic Analysis Views derivation metrics vague weak optional subjective multiple implicit underspec Logs Indicator-related dictionaries Domain dictionaries Graphics 21

22 Risultati di un rigoroso studio empirico Le performance dell utilizzo di QuARS sono state confrontate con quelle di un revisore esperto Medesimo insieme di documenti analizzati Registrazione dei tempi di review e dei difetti trovati dal tool e dal revisore Risultati: QuaRS ha una numero medio di difetti trovati all ora 32 volte maggiore del revisore Indipendentemente dal tempo QuaRS trova una numero di difetti triplo rispetto al revisore QuARS e il revisore sono complementari: 63% dei difetti trovati dal revisore non sono trovabili da QuARS I falsi positivi possono intaccare i risultati a sfavore di QuARS (se il rapporto fra FP e difetti reali > 6, QuARS è più costoso del revisore) QuARS si dovrebbe usare prima del revisore Requirements Quality Key Points La qualità dei requisiti in linguaggio naturale: definizione delle caratterisitiche Testabilità del software e requisiti testabili Cause di scarsa testabilità dei requisiti Tecniche per il miglioramento della testabilità Un tool per la valutazione della qualità dei requisiti 22