IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business
Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis. Certified Business Analysis
Professional, Certification of Competency in Business Analysis, Endorsed Education Provider, EEP and the EEP logo are trademarks owned by
International Institute of Business Analysis.
Eliminare il gap tra esigenze reali e requisiti espressi grazie alla Business Analysis Federico Maria Capo
IIBA® Italy Chapter
Marzo 2017
2
• Con SCOPE CREEP ci si riferisce, in genere, ad un PROGETTO che vede i suoi OBIETTIVI
ORIGINALI ESPANDERSI SENZA CONTROLLO mentre il progetto è in corso
• Come suggerisce il termine «creep: che avanza lentamente» è un PROCESSO SUBDOLO
che inizia con PICCOLI AGGIUSTAMENTI e finisce con PROGETTI che si ESTENDONO molto
più del tempo previsto o addirittura FALLISCONO ancora prima di completarsi, per l’incremento
di tempi e costi
Cos’è
Quali rischi comporta
Lo Scope Creep (1/2)
• Ha un impatto negativo sulle SCADENZE e sul BUDGET di progetto
• Comporta PERDITE FINANZIARIE nel caso in cui un progetto sia cancellato
• Determina INSODDISFAZIONE degli STAKEHOLDER
• Genera INEFFICIENZE per le continue RILAVORAZIONI
• Crea FRUSTAZIONE nel team di progetto
Più sinteticamente lo SCOPE CREEP
comporta una generale PERDITA del
VALORE della SOLUZIONE
3
A Analisi
Requisitazione
Definizione dello Scope di
Progetto
Elicitation Requirements
Analysis
Business Need
Definition
Lo Scope Creep (2/2)
Le principali CAUSE che portano allo SCOPE CREEP sono:
• ASSENZA di CHIAREZZA nella definizione dell’AMBITO del PROGETTO
• MANCANZA di REQUISITI essenziali (siano essi impliciti o espliciti)
• AGGIUNTA di FUNZIONALITÀ che NON contribuiscono al VALORE apportato dal Progetto
Quando può verificarsi
Perdita di Business Value + -
4
Il 45% circa delle FUNZIONALITA’ di un SOFTWARE, in media, non sono MAI UTILIZZATE
The 45% Disaster
Anche se il progetto è completato, lo
SCOPE CREEP può portare a
RISULTATI DISTANTI da quelli
EFFETTIVAMENTE NECESSARI,
erodendo il VALORE ATTESO dalla
SOLUZIONE
5
Perché la Business Analysis
Fonte: Standish Group (sulla base di 8000 progetti analizzati)
Più del 50% delle CAUSE di
FALLIMENTO dei progetti
ICT può essere ricondotto a
CARENZE di BUSINESS
ANALYSIS
1
2
3
4
5
6
8
7
Requisiti non completi
Stakeholder non coinvolti nell’analisi
Carenza di risorse
Aspettative irrealizzabili
Carenza di Governance
Change requests
Carenza di pianificazione
Non più necessario
13,1%
12,4%
10,6%
9,9%
9,3%
8,7%
8,1%
7,5%
CAUSE DEL FALLIMENTO DEI PROGETTI ICT
La BUSINESS ANALYSIS supporta le organizzazioni nella definizione del prodotto/servizio
atteso e nello sviluppo del "BETTER BUSINESS OUTCOMES", guidandole nel cambiamento
verso la giusta direzione
6
Lo Scope Creep nel BABOK®
Business Analysis Body of Knowledge® (BABOK® Guide) v3
•L’unico standard riconosciuto a livello mondiale per la pratica della BA
•La conoscenza collettiva di tutta la community di BA
•L'insieme di competenze e conoscenze richieste ad un BA professionista
7
Business
Analysis
Il BUSINESS ANALYSIS CORE CONCEPT MODEL™ è il FRAMEWORK CONCETTUALE alla base
della Business Analysis. Esso include tutti gli elementi di base di cui si essa si compone e il significato
stesso della Business Analysis
COSA FA LA BUSINESS ANALYSIS:
ATTRAVERSO UN’APPROFONDITA ANALISI E
COMPRENSIONE DEI BISOGNI, ANALIZZANDO
IL CONTESTO DI RIFERIMENTO E GLI SCENARI
ATTESI, LA BUSINESS ANALYSIS CONSENTE DI
IDENTIFICARE CIÒ DI CUI GLI STAKEHOLDERS
EFFETTIVAMENTE NECESSITANO,
INDIVIDUANDO LA SOLUZIONE CHE ABILITI IL
CAMBIAMENTO, ASSICURANDO IL
RAGGIUNGIMENTO DEL MAGGIOR VALORE
PER L’ORGANIZZAZIONE
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
Il Framework concettuale della BA
8
I Requisiti secondo l’IIBA®
DESIGN
DESIGN DESIGN
ASSESS
OUTCOME
Business
Requirements
Perché lo
vogliamo?
Sono gli OBIETTIVI e gli ESITI che descrivono il
MOTIVO per cui un CAMBIAMENTO è stato
avviato
Le ESIGENZE degli
STAKEHOLDER che
devono essere
soddisfatte al fine di
assicurare il
RISPETTO dei
REQUISITI di
BUSINESS. Sono il
COLLEGAMENTO
tra le ESIGENZE di
business e le
SOLUZIONI che le
soddisfano
Stakeholder
Requirements
Quali bisogni
soddisfa?
Le FUNZIONALITÀ e le QUALITÀ che una
SOLUZIONE deve possedere per soddisfare
le esigenze degli stakeholder
Solution
Requirements
Cosa
vogliamo?
Transition
Requirements
A quali
condizioni?
Le FUNZIONALITÀ
che la soluzione deve
avere e le CONDIZIONI
che deve soddisfare
per facilitare la
TRANSIZIONE verso il
cambiamento, ma che
non saranno più
necessarie quando la
soluzione sarà messa
in campo
Definire e sviluppare la
soluzione a maggior valore
passa per la definizione di
4 TIPOLOGIE DI REQUISITI,
tra loro interconnessi
gerarchicamente
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
9
La Requirements Traceability
The purpose of Trace Requirements is to ensure that REQUIREMENTS and designs at
different levels are ALIGNED TO ONE ANOTHER, and to manage the effects of change to
one level on related requirements. - Business Analysis Body Of Knowledge v3 -
La TRACEABILITY assicura che la SOLUZIONE che
si va ad implementare sia CONFORME AI REQUISITI
DI BUSINESS ed è di supporto nelle attività di scope,
change, risk, time, cost e communication
management.
E’ inoltre funzionale alla rilevazione di buchi funzionali
(requisiti non coperti da soluzioni) o per identificare
quelle funzionalità che non sono supportate da alcun
requisito.
10
Input
Ingredienti
Output
Business Analysis
Aree di Conoscenza
Task
Il BABOK classifica le attività di Business Analysis in 6
AREE di CONOSCENZA (o KNOWLEDGE AREA),
all’interno delle quali sono descritti 30 TASK
Per essere eseguito il TASK necessita di:
• Tutte le INFORMAZIONI NECESSARIE
per AVVIARE un TASK
• Possono essere il RISULTATO di
precedenti ATTIVITÀ di BA oppure
provenire dall’ESTERNO
• NON è NECESSARIO che l’input sia
COMPLETO o nel suo stato finale per
iniziare un task
• ELEMENTI: concetti chiave
per comprendere la natura del
task
• LINEE GUIDA / STRUMENTI:
risorse che possono essere
necessarie per eseguire il task
• TECNICHE: utilizzabili per
eseguire il task
• STAKEHOLDER: lista
generica di possibili attori
coinvolti, a vario titolo, nel task
• Il RISULTATO dell’applicazione del
TASK
• Può essere un DELIVERABLE o
PARTE di un deliverable più ampio
• La sua forma può dipendere da molti
fattori (iniziativa, standard applicabili,
esperienza del BA)
• NON è NECESSARIO che sia
COMPLETO o nel suo stato finale
Le Aree di Conoscenza (KA) della BA
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
11
Lo Spettro del Valore della BA
Le AREE DI CONOSCENZA della BA consentono di AVANZARE lungo lo SPETTRO del VALORE, dal
POTENZIALE all’ATTUALE, AZZERANDO lo SCOPE CREEP
Strategy
Analysis
Requirements Analysis &
Design Definition
Solution
Evaluation
Business Analysis Planning & Monitoring
Need Solution Scope Requirements Design Proof of Concept /
Prototype
Pilot /
Beta
Operating
ACTUAL
VALUE
POTENTIAL
VALUE
Business
Requirements
Solution
Requirements
Transition
Requirements Stakeholder
Requirements
Elicitation and Collaboration
Requirements Life Cycle Management
Core KAs
Support KAs
V
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
12
Le relazioni tra le KA
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
13
Le Aree di Conoscenza «core»
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
Solution
Strategy
Analysis Requirements Analysis & Design Definition
Solution
Evaluation
Task
Obiettivo
Identificare i BISOGNI di
un’ORGANIZZAZIONE di
rilevanza TATTICA e/o
STRATEGICA per
indirizzarli attraverso la
STRATEGIA di
CAMBIAMENTO più adatta
Business
Requirements Solution
Requirements
Transition
Requirements Stakeholder
Requirements
• SPECIFICARE e MODELLARE i requisiti e il design della soluzione
• STRUTTURARE ed ORGANIZZARE i requisiti
• VALIDARE e VERIFICARE le informazioni raccolte
• IDENTIFICARE le possibili SOLUZIONI alternative in risposta ai bisogni
individuati, stimandone il VALORE POTENZIALE
TRASFORMARE i BISOGNI iniziali nella SOLUZIONE a maggior VALORE,
attraverso processi iterativi ed incrementali
• Stabilire gli OBIETTIVI di
BUSINESS
• Definire IMPATTI AS IS
• Identificare la
SOLUZIONE a
MAGGIOR VALORE
• Evidenziare i RISCHI e
possibili EFFETTI
• GAP ANALYSIS e piano
di CAMBIAMENTO per
ciascuna iniziativa
• Definizione delle METRICHE
di misurazione del VALORE
della soluzione
• MISURAZIONE delle
PERFORMANCE
• Rilevazione di LIMITI per il
VALORE ATTESO
• Raccomandazione di
INTERVENTI in ottica di
MIGLIORAMENTO
CONTINUO
Valutare le PERFORMANCE
ed il VALORE PRODOTTO
dalla SOLUZIONE in USO
per segnalare la RIMOZIONE
di BARRIERE e VINCOLI che
ostacolino il raggiungimento
dei LIVELLI ATTESI
14
Le Aree di Conoscenza di supporto
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
Business
Requirements
Solution
Requirements
Transition
Requirements
Stakeholder
Requirements
Solution
Req
uir
emen
ts L
ife
Cyc
le M
anag
emen
t
Obiettivo
Attività
Elic
itat
ion
an
d C
olla
bo
rati
on
Assicurare un
CONTROLLO sui
REQUISITI affinchè siano
sempre ALLINEATI fra di
loro, siano allineati con il
design della soluzione e
siano in essa INCLUSI
• TRACCIARE (traceability) i
requisiti
• Verificare
l’ACCURATEZZA e
l’assenza di INCOERENZE
fra i requisiti e fra i requisiti
ed il design della soluzione
• RI-UTILIZZARE i requisiti
per usi futuri
• PRIORIZZARE i requisiti
• VALUTARE le RICHIESTE
di CAMBIAMENTO, in
ottica di allineamento
tattico-strategico
• FAR APPROVARE i
requisiti
Bu
sin
ess
An
alys
is P
lan
nin
g &
Mo
nit
ori
ng
OTTENERE
INFORMAZIONI e
verificarne l’esatta
COMPRENSIONE,
COMUNICANDO
opportunamente con tutti
gli attori interessati
• PREPARARE le sessioni
di elicitazione
• CONDURRE le sessioni
• CONFERMARE le
evidenze emerse
• COMUNICARE le
evidenze raccolte
• COLLABORARE con gli
ATTORI INTERESSATI
per ottimizzare tutte le
attività descritte ai punti
precedenti
ORGANIZZARE
e COORDINARE tutte
le ATTIVITA’ di BA
condotte dai BUSINESS
ANALYST e
nell’interazione con gli
STAKEHOLDER
• PIANIFICAZIONE di tutte
le ATTIVITÀ di BA, dalla
scelta della metodologia
alle singole ATTIVITA’,
TASK e DELIVERABLE
• ANALISI degli
STAKEHOLDER e
PIANIFICAZIONE del
loro ENGAGEMENT
• PIANIFICAZIONE delle
componenti di BA a
supporto della
GOVERNANCE
• PIANIFICAZIONE delle
modalità di GESTIONE
delle INFORMAZIONI
• Identificazione di AREE
di MIGLIORAMENTO
delle attività di BA
15
Flow Chart /
Activity Diagram
venti oncetti
(Entità) e
Relazioni
Specify,… …and Define Requirements
Architecture …Model,…
Roles / Profiles
Matrix
Entity-
Relationship
Model / Class
Diagram
Events Matrix
Business Rules
Matrix
….
Il Modello «PURCE» per lo sviluppo dei Requisiti Funzionali
U
egole di
Business R
P
C E
P
U
egole di
Business R
oncetti
(Entità) e
Relazioni
C
venti E
Soluzione
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
16
Security
Compatibility
Usability
Relaibility
Maintainability
Performance
Efficiency Portability
I Requisiti non Funzionali per l’IIBA®
Extensibility
Localization
Certification
Compliance
Service Level
Agreement
Scalability
Capacità della soluzione di gestire incrementi
della quantità di lavoro svolto
Capacità della soluzione di essere allineata
al vincoli regolatori/legali di una data
giurisdizione
Capacità della soluzione di estendere le
proprie funzionalità
Capacità della soluzione di essere adattata e
di operare in contesti locali differenti (lingua,
cultura, etc.)
Capacità della soluzione di soddisfare
determinati standard industriali
Capacità della soluzione di
assicurare determinati livelli di
servizio per l’organizzazione
ISO/IEC
25010:2011
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
17
Come esprimere i Requisiti non Funzionali
NFR
Trattando ASPETTI
QUALITATIVI, molto
spesso è più facile
esprimerli in modo
INDEFINITO
NFR troppo STRINGENTI
possono far lievitare
facilmente i COSTI di una
soluzione
Potendo trattare ASPETTI
più TECNICI, possono
essere più DIFFICILI da
ESPRIMERE per un
Business Analyst
E’ necessario
COLLABORARE con gli
ATTORI più TECNICI nella
fase di declinazione dei
NFR
Devono essere espressi in
funzioni delle REALI
NECESSITÀ, mediando con
gli attori interessati il costo /
opportunità
Ma come tutti i requisiti,
devono essere elaborati
con i GIUSTI ATTORI…
Ma come tutti i requisiti,
devono essere
PRIORIZZATI
Ma come tutti i requisiti,
devono essere TESTABILI
Provare ad esprimerli
quantificandoli in base a
possibili MISURE
CORRELATE alla categoria
di NFR espresso
«Il sistema deve
fornire il 90% delle
risposte in 2 secondi»
«Il sistema deve fornire
il 90% delle risposte
entro i 5 secondi»
«Il sistema deve fornire
il 90% delle risposte in
brevissimo tempo»
• Creare una stretta
CORRELAZIONE tra
Requisiti Funzionali e
Requisiti Non Funzionali, in
modo che i secondi siano di
aiuto alla migliore
declinazione dei primi;
• Considerare sempre i NFR
come una CHECKLIST da
affiancare ai Requisiti
Funzionali.
«Il sistema deve rispondere velocemente»
C.O.M.P.Ra.S.Ti
C.L.A.S.S.E. C.
• Compatibility
• Operability
• Maintainability
• Performance effic.
• ReliAbility
• Security
• TransferabIlity
• Compliance
• Localization
• Availability
• Scalability
• Service level agr.
• Extensibility
• Certification
Come ricordarli tutti?
18
I BUSINESS ANALYST gli «ARCIERI» del cambiamento e le FRECCE al nostro arco!
Increase Consistency
Improve Information Access
Automate, where possible
Reduce complexity
Innovate, uncovering new capabilities
Remove Redundancy
Eliminate Waste
Gli attori chiave per il cambiamento
Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration
19
Spazio al Case Study