Requirements Engineering

(1)

Requirements Engineering:

Natural Language Requirements Elicitation, Specification and Quality Evaluation

Part II

Giuseppe LamiPh.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. 0503153493

RE: NL Requirements Elicitation, Specification & QA Giuseppe Lami, ISTI-CNR

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

(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

5$ nella fase di design,

10$ in quella di codifica,

20$ nel testing

200$ dopo la delivery

0 50 100 150 200

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]

(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 featurethat the system musthave or a constraint it mustsatisfy to be accepted by the client” [Bruegge, Dutoit]

“1) a condition or capabilityneeded by a userto 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 otherformally imposed documents,

A documentedrepresentation of a condition or capability as in 1) or2).” [IEEE610.12-1990]

(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

(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

(6)

Esiste una interpretazione comune?

La descrizione del prodotto è corretta?

(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

(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

(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

(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 uomo- macchina

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>

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>.

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> :

Sub-Variations Branching Action 1 <list of variations>

(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 viewpoint

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

eliciting dei requisiti X X X X X X X

(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

(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]

(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

(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 610.12 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”.

(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 eseguibilee 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

(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

(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

(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

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

(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

B A

B Behavioral

B B

B Structured NL

C C

A Simplified NL

Restrictive

C B

Inductive A

B A

Manual B

C C

A Tool based

Analytic

Extra-req.

Inter-req.

Intra-req.

Cause of Poor Testability Technique

(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

Indicator-related dictionaries Syntax Parser

Parsed.txt

sentences.txt

Lexical Analysis

Syntactic Analysis

multiple implicit underspec subjective optional vague weak

metrics

Logs

Views derivation

0 1 2 3 4 5 6 7 8

1 2 3 4 5 6

Graphics Domain

dictionaries Indicator-related

dictionaries Syntax Parser

Parsed.txt

sentences.txt

Lexical Analysis

Syntactic Analysis

multiple implicit underspec subjective optional vague weak

metrics

Logs

Views derivation

0 1 2 3 4 5 6 7 8

1 2 3 4 5 6

Graphics Domain

dictionaries

(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