GlossarioStandard Dei Termini Utilizzati Nella Ingegneria v1 3

Glossario Standard dei Termini utilizzati nellIngegneria
dei Requisiti
REQB
Certified Professional for Requirements Engineering
Version 1.3
2014
Associazione ITA-STQB
Sede Legale e Amministrativa: 25125 Brescia Via Brozzoni 9
C.F. 03265510176 P.I 03121180982
e-mail info@ita-stqb-org
REQB Certified Professional for
Requirements Engineering
Glossario
DATI IDENTIFICATIVI
CODICE DOCUMENTO DATA DI EMISSIONE STATO

ITASTQB-GLOSS-V1.3 31/12/2014 REDATTA APPROVATA
REDATTORI DATA
M. DI CARLO 15/04/2012
C. SOBRERO 20/11/2014
APPROVATORI DATA
GUALTIERO BAZZANA 31/12/2014
SALVATORE REALE
MARCO SOGLIANI
Versione 2013 Pagina 2 di 42 01 Gennaio 2013

REQB Certified Professional for Requirements Engineering
Pagina 2 di
42
Glossario
STORIA DELLE MODIFICHE
CHI DATA VERSIONE CONTENUTO

Massimo 1.0 Prima versione
15/04/2013
Di Carlo
Cristina 1.3 Allineamento al Sillabo v2.1 2014
20/11/2014
Sobrero (2014)
Autore della traduzione italiana: Massimo Di Carlo (v. 1.0) e Cristina Sobrero (v. 1.3)
Revisori: Fabio Milanese e Cristina Sobrero
Nota di Copyright
Questo documento pu essere copiato nella sua interezza, o possono esserne estratte delle parti, solo
previa autorizzazione di ITA-STQB e se la fonte viene citata.
Versione 2014 Pagina 3 di 42 31 Dicembre 2014

Glossario
INDICE DEI CONTENUTI

1. Note alla traduzione italiana ...............................................................................................................5
2. Obiettivo ...............................................................................................................................................6
3. ambito ...................................................................................................................................................6
4. Organizzazione .....................................................................................................................................6
5. Definizioni.............................................................................................................................................8
A ................................................................................................................................................................8
B ...............................................................................................................................................................11
C ...............................................................................................................................................................12
D ..............................................................................................................................................................15
E ...............................................................................................................................................................16
F ...............................................................................................................................................................17
G ..............................................................................................................................................................18
H ..............................................................................................................................................................19
I ................................................................................................................................................................20
L ...............................................................................................................................................................21
M ..............................................................................................................................................................22
N ..............................................................................................................................................................25
O ..............................................................................................................................................................26
P ...............................................................................................................................................................27
Q ..............................................................................................................................................................29
R ...............................................................................................................................................................30
S ...............................................................................................................................................................32
T ...............................................................................................................................................................35
U ..............................................................................................................................................................36
V ..............................................................................................................................................................37
X ..............................................................................................................................................................39
W..............................................................................................................................................................40
6. Annesso A (Informativo) ...................................................................................................................41
7. Annesso B (Metodo di commento al presente Glossario) ...............................................................42

Glossario
1. NOTE ALLA TRADUZIONE ITALIANA

Alcuni termini del Glossario Originale in lingua inglese nella Versione 1.3 (2014), non sono stati
tradotti direttamente per vari motivi (generalmente per sinonimia eccessiva con termini molto pi usati
nella letteratura tecnica).
In ogni caso:
1. La presente traduzione del Glossario in lingua italiana completamente autocontenuta, per cui
nel presente documento non esiste nessun riferimento a termini che non siano compresi nella
traduzione medesima.
2. La corrispondenza dei termini tra la versione 1.3 del Glossario in lingua inglese e la presente
corrispondente traduzione in lingua italiana, descritta in un ulteriore documento chiamato:
DOCUMENTO DI TRACCIABILIT dei termini tra GLOSSARIO REQB in LINGUA
ORIGINALE e GLOSSARIO REQB tradotto in LINGUA ITALIANA
che inteso a supporto e completamento del presente documento.
Questo a garanzia del fatto che tutti e soli i termini del Glossario in lingua inglese in Ver. 1.3
siano stati valutati per leventuale traduzione, e che a partire dai documenti prodotti ci sia la
completa possibilit di effettuare una congruente preparazione dei sillabi, dei corsi in lingua
italiana e della traduzione delle domande per gli esami.

Glossario
2. OBIETTIVO
Lo scopo di questo documento di fornire un glossario standardizzato che possa essere usato da
professionisti IT che si occupano di Ingegneria dei Requisiti, per assicurare una comune comprensione
dei termini e delle attivit di base.
3. AMBITO
Questo documento presenta concetti, termini e definizioni, creati per aiutare la comunicazione
nell'ambito dellIngegneria dei Requisiti, di Analisi del Business e di Sistema, in generale
dellIngegneria del Software e delle discipline correlate.
4. ORGANIZZAZIONE
Il glossario stato organizzato in una singola sezione di definizioni ordinate alfabeticamente.
Alcuni termini sono stati preferiti ad altri sinonimi, nel qual caso viene data la definizione del termine
preferenziale, mentre i sinonimi rimandano a quello.
Sono inoltre usati i riferimenti incrociati Vedere anche, che permettono di navigare rapidamente
al termine corretto. I riferimenti incrociati Vedere anche sono costruiti per relazioni come da termine
generico a termine specifico, e per significati sovrapposti tra i due termini.
4. Riferimenti normativi
Al tempo della pubblicazione del glossario inglese, erano valide le edizioni indicate. Tutti gli
standard sono soggetti a revisione e le parti che stipulano accordi basati su questo standard sono
invitati a verificare la possibilit di applicare la versione pi recente delle norme di seguito indicate. I
membri della IEC e ISO mantengono i registri delle norme internazionali vigenti
IEEE Standard 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology

IEEE Standard 829-1998 IEEE Standard for Software Test Documentation
IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications
IEEE Standard 1012-2004: IEEE Standard for Software Verification and Validation
IEEE Standard 1059-1993: IEEE guide for software verification and validation plans

Glossario
IEEE Standard 1220-1998: IEEE Standard for Application and Management of Systems
Engineering Process
IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications
IEEE Standard 1362-1998 IEEE Guide for Information Technology-System Definition Concept
of Operations (ConOps) Document
ISO 9000:2005. Quality Management Systems Fundamentals and Vocabulary.
ISO/IEC 12207:1995. Information Technology Software Lifecycle Processes.
ISO/IEC 14598-1:1999. Information Technology Software Product Evaluation - Part 1: General

Overview.
ISO 15504-9: 1998. Information Technology Software Process Assessment (SPICE Software
Process Improvement and Capability Determination) Part 9: Vocabulary
ISO 31000: Risk Management - Principles and Guidelines on Implementation
IEC 31010: Risk Management - Risk Assessment Techniques
ISO/IEC 73: Risk Management Vocabulary
ISTQB Glossary of testing terms ver. 2.1
5. Marchi registrati
In questo documento vengono usati i seguenti marchi registrati:
BABOK is a registered trademark of IIBA
CMM e CMMI sono marchi registrati di Carnegie Mellon University
BPMN un marchio registrato di Business Process Management Initiative (BPMI), attualmente

fusa con Object Management Group
RUP un marchio registrato di Rational Software Corporation
TMMI un marchio registrato di TMMi Foundation
UML un marchio registrato di Object Management Group
SysML un marchio registrato di Object Management Group

Glossario
5. DEFINIZIONI
A
Accordo sui Requisiti: vedere Approvazione dei requisiti
Accuratezza: La capacit del prodotto di fornire il risultato o effetto richiesto, con il necessario
grado di precisione. [in accordo con ISO/IEC 25000, prima ISO9126]. Vedere anche Requisito
Funzionale
Activity Diagram: In UML un tipo di Behavior Diagram, che rappresenta i flussi delle attivit e
azioni, supportata da istruzioni relative alla scelta, all'iterazione e alla concorrenza. Per i dettagli
fare riferimento alle specifiche UML [OMG].
Adattabilit: La capacit del prodotto di essere adattato per ambienti differenti senza lutilizzo di
altre azioni o limpiego di altre risorse, rispetto a quelle gi fornite per questo scopo dal prodotto
considerato [in accordo con ISO/IEC 25000, prima ISO9126].Vedere anche Portabilit e
Requisito Non Funzionale
Affermazione della Vision: Breve testo che specifica informazioni sul prodotto desiderato (perch,
che cosa o chi) dal punto di vista del business [in accordo con BABOK]
Affidabilit: La capacit del prodotto di eseguire le funzionalit richieste, sotto prefissate
condizioni, per uno specifico periodo di tempo o per uno specificato numero di operazioni. [in
accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche Requisito Non Funzionale
Ambito: Il grado di influenza di qualcosa. Il termine ambito pu essere applicato a qualsiasi cosa,
come una Specifica, un sistema o un progetto definito [TGilb].
Ambito della Soluzione: Tutte le capacit, funzioni e qualit che devono essere rilasciate da una
soluzione per poter soddisfare le richieste o gli obiettivi di business richiesti. Vedere anche
Ambito
Analisi degli Use Case Point (UCP): Metodo che si prefigge di misurare la dimensione della
funzionalit di un sistema informatico. La misurazione richiede unanalisi di altri elementi quali
il numero e la complessit degli use case (casi duso) e degli attori nella soluzione pianificata.
Questa misura pu essere usata come base per la stima delle risorse necessarie e per il controllo
del progetto. Vedere anche Use Case Point
Analisi dei Function Point (FPA): Metodo che si prefigge di misurare la dimensione della
funzionalit di un sistema informatico, calcolando il numero dei cosiddetti Function Point della
soluzione pianificata.. La misurazione indipendente dalla tecnologia. Questa misura pu essere
usata come base per la misurazione della produttivit, la stima delle risorse necessarie e per il
controllo del progetto. Vedere anche Function Point
Analisi dei Requisiti: Un insieme di compiti, attivit e strumenti per determinare se i requisiti
identificati (elicitati) siano non chiari, incompleti, ambigui o contraddittori e quindi
documentare i requisiti nella forma di un modello coerente.
Analisi del Rischio (valutazione): Il processo di valutazione dei rischi identificati per stimare il
loro impatto e la loro possibilit di verificarsi (intesa come probabilit).

Glossario
Analisi del Sistema (SA): un insieme di attivit, metodi, tecniche, strumenti focalizzati a
trasformare i requisiti di business in requisiti di sistema. Descrive un sistema e le sue limitazioni
nellambiente, fornendo una comprensione consolidata dell'ambiente e dei requisiti di sistema.
Analisi del Business (BA): LAnalisi del Business una disciplina che fornisce un insieme di
attivit, strumenti e metodi che permettono di definire le richieste, i problemi e gli obiettivi di
business, e consentono di determinare le soluzioni appropriate che soddisfano queste necessit e
risolvono i problemi di business identificati. Vedere anche Analisi del sistema.
Analista di Business: Una persona responsabile di determinare le richieste, le aspettative e gli
obiettivi di business degli stakeholder, in modo da determinare le soluzioni ai problemi di
business [in accordo con BABOK]. Vedere anche Analista di Sistema.
Analista di Sistema: Una persona con un approccio tecnico, che ricerca un dato problema di
business, pianifica le soluzioni software fornendo raccomandazioni sulla scelta del software e dei
sistemi, coordina lo sviluppo per soddisfare i requisiti di business o altri requisiti. Il compito
dellAnalista di sistema quello di sviluppare i requisiti di business in requisiti di sistema
(espressi come Specifiche Tecniche).
Analisi e Progettazione Object Oriented (OOAD): Un approccio dellIngegneria del Software
che modella un sistema come un insieme di oggetti che interagiscono tra loro. Ogni oggetto
rappresenta elemento del sistema da modellare ed caratterizzato dalla sua classe, dallo stato
(elementi di dati) e dal suo comportamento. OOAD comprende lAnalisi Object Oriented (OOA)
e la Progettazione Object Oriented (OOD). OOA applica tecniche di modellazione ad oggetti per
analizzare i requisiti funzionali di un sistema. OOD elabora i modelli di analisi per produrre
specifiche di implementazione.
Analizzabilit: La capacit del prodotto di limitare impegno richiesto per diagnosticare carenze o
cause di malfunzionamenti, o per identificare parti da modificare...Vedere Manutenibilit e
Apprendibilit: La capacit del prodotto di consentire allutente di imparare il suo utilizzo [in
accordo con ISO/IEC 25000, prima ISO 9126]. Vedere anche Usabilit.
Apprendimento: Tecnica utilizzata per lIdentificazione dei Requisiti. Un processo di conoscenza
eseguito direttamente dal cliente sulle attivit che svolge nel suo lavoro. Il cliente insegna
allIngegnere dei Requisiti come un insegnante ad un allievo
Approccio Agile: un insieme di metodologie di sviluppo software basate sullapproccio
incrementale iterativo, in cui i requisiti e le soluzioni evolvono attraverso la collaborazione di
piccoli gruppi auto-organizzati e rappresentativi del progetto.
Approccio Incrementale: Un modello del ciclo di vita tradizionale dove un progetto viene
suddiviso in una sequenza di incrementi. Linsieme dei requisiti richiesti in un progetto viene
suddivisa in sottoinsiemi di requisiti, che vengono implementati attraverso tali incrementi. I
requisiti vengono prioritizzati ed implementati secondo tale ordine di priorit nel relativo passo
incrementale. In alcune (ma non in tutte) le versioni di questo modello del ciclo di vita, ogni
sotto progetto segue un mini modello a V con le proprie fasi di progettazione, codifica e test.
Approccio Iterativo: Un modello del ciclo di vita tradizionale dove un progetto viene suddiviso in
un numero generalmente elevato di iterazioni. Uniterazione un ciclo di sviluppo completo che

Glossario
termina con un rilascio (interno od esterno) di un prodotto eseguibile, un sottoinsieme del

prodotto finale, che si accresce ad ogni iterazione fino a diventare il prodotto finale.
Approccio Lineare: Vedere Approccio Sequenziale
Approccio Sequenziale: Un modello del ciclo di vita tradizionale dove ogni fase pu iniziare solo
al termine della fase precedente. Dal punto di vista dellIngegneria dei Requisiti, che si basa
sullassunzione che tutti i requisiti possono essere raccolti, definiti e analizzati nella fase iniziale
del ciclo di vita, e non saranno successivamente soggetti a modifiche.
Approccio Tradizionale: Modello del ciclo di vista del software che non segue lApproccio Agile:
modelli sequenziali o lineari, modelli iterativi e modelli incrementali (spesso questi ultimi due
modelli vengono combinati insieme). Vedere Approccio Sequenziale, Approccio Incrementale,
Approccio Iterativo
Appropriatezza: La capacit del prodotto di fornire un insieme appropriato di funzioni per gli
specificati compiti e obiettivi dellutente. [in accordo con ISO/IEC 25000, prima ISO 9126]
Vedere anche Requisito Funzionale
Approvazione dei Requisiti: Processo formale di accordo tra gli stakeholder principali relativo alla
accuratezza e completezza del contenuto e dellambito dei requisiti
Artefatto: Uno dei risultati prodotti durante lo sviluppo del software. Alcuni prodotti (per es.: use
case, class diagram e altri modelli UML, documenti dei requisiti e di progetto) aiutano a
descrivere una funzione, larchitettura e la progettazione del software. Altri prodotti riguardano il
processo stesso di sviluppo come piani di progetto, casi di business e la valutazione del rischio.
Attore: Un tipo di ruolo svolto da unentit che interagisce con il soggetto (per es. scambiando
segnali e dati), ma che esterna al soggetto [OMG].
Attrattivit: La capacit del prodotto di essere attraente, piacevole per lutente. [in accordo con
ISO / IEC 25000, prima ISO9126] Vedere anche Usabilit.
Attributo: Una caratteristica di un oggetto. [IEEE 610]
Attributo di Qualit: Una caratteristica che riguarda la qualit di un elemento. [IEEE 610]
Attributo di un Requisito: Informazioni descrittive di un requisito che arricchiscono la sua

definizione, come la release e la versione [Wiegers]
Audit: Una valutazione indipendente di prodotti software o di processi per stabilire laderenza a
standard, linee guida, specifiche e/o procedure basate su criteri oggettivi, che includono
documenti che specificano [IEEE 1028]:
la forma o il contenuto dei prodotti che devono essere realizzati,
il processo attraverso il quale i prodotti devono essere realizzati,
le modalit con cui laderenza agli standard o alle linee guida deve essere misurata.
Auto-registrazione: In questa tecnica di Identificazione dei Requisiti, lo stakeholder (per esempio,
un utente finale) documenta in modo autonomo le attivit che ha eseguito per poter completare
uno specifico compito, riportando eventuali desiderata e richieste.

Glossario
B
BA: Business Analysis. Vedere Analisi del Business, Analista di Business.
Baseline: Una specifica del prodotto software che stata formalmente verificata o concordata, su
cui si baser un successivo sviluppo e che pu essere modificata solamente attraverso un
processo di controllo formale delle modifiche (Change Management). [IEEE 610]
Behavior Diagram: Diagramma Comportamentale. In UML un tipo di diagramma che rappresenta
le caratteristiche comportamentali di un sistema o di un processo di business. Sono compresi gli
Activity Diagram, gli State Machine Diagram, gli Use Case Diagram e i quattro Interaction
Diagram (Communication Diagram, Interaction Overview Diagram, Sequence Diagram e
Timing Diagram). Vedere anche Interaction Diagram. Per i dettagli fare riferimento alle
specifiche UML [OMG].
Beneficio: Valore fornito agli stakeholder [TGilb]
BPMN: Vedere Business Process Modeling Notation
Braistorming: Tecnica per lidentificazione dei requisiti, comunemente utilizzata per identificare
requisiti e raccogliere molte idee da differenti stakeholder in breve tempo ed in modo
economico.
Business Process Modeling Notation (BPMN): Una notazione grafica che descrive le fasi di un
processo di business. La notazione BPMN raffigura il flusso end to end di un processo di
business. La notazione stato specificamente progettata per coordinare la sequenza di processi e
messaggi che si scambiano i differenti processi in un insieme di attivit [BPMN.ORG].

Glossario
C
Capability Maturity Model (CMM): E un modello a cinque livelli che descrive gli elementi
chiave di un processo software efficace. Il Capability Maturity Model copre le migliori pratiche
per la pianificazione, per lingegnerizzazione e per la gestione dello sviluppo del software e della
sua manutenzione. [CMM] Vedere anche Capability Maturity Model Integration (CMMi).
Capability Maturity Model Integration (CMMi): E un modello che descrive gli elementi chiave
di un efficace processo di sviluppo del prodotto e della sua manutenzione. Il Capability Maturity
Model Integration copre le migliori pratiche per la pianificazione, per lingegnerizzazione e per
la gestione dello sviluppo del prodotto e della sua manutenzione. Il CMMi il successore del
CMM. [CMMi] Vedere anche Capability Maturity Model (CMM).
Caratteristica: Un attributo di uno specifico componente o sistema, o derivante dalla
documentazione dei requisiti. (per esempio affidabilit, usabilit o vincoli di progettazione)
[IEEE 1008]
Caratteristica di Qualit: Vedere Attributo di qualit.
Caratteristica di Qualit del Software: Vedere Attributo di qualit
Caso duso: Vedere Use Case
CCB: Change Control Board
Change Control Board (CCB): Un gruppo di persone responsabile di valutare, di approvare o
meno le modifiche (Change Request) apportate ad elementi della configurazione, e di garantire
limplementazione delle modifiche approvate. [IEEE 610]
Change Management: (1) Un approccio strutturato per gestire il passaggio di stato di oggetti,
individui, gruppi ed organizzazioni (da uno stato attuale ad un desiderato stato futuro). (2) Una
modalit controllata per rendere effettiva una modifica, o una proposta di modifica, ad un
prodotto o servizio.
Change Request: Un documento ufficiale con cui viene chiesto di aggiungere o modificare
caratteristiche, requisiti o funzioni.
Ciclo di Vita del Prodotto: Il periodo di tempo che inizia quando un prodotto software viene
concepito (Concezione del progetto), e termina quando il software non pi disponibile per
l'utilizzo (Fine dellutilizzo). Il ciclo di vita del software generalmente include una fase di
concezione (identificazione della Vision di progetto), una fase di identificazione, analisi e
specifica dei requisiti, una fase di progettazione, una fase di implementazione, una fase di test,
una fase di installazione e di rilascio, una fase di operativit e con possibile manutenzione e, a
volte, una fase di ritiro. Da notare che queste fasi possono sovrapporsi oppure essere eseguite
iterativamente.
Class Diagram: In UML un tipo di Structure Diagram statico che rappresenta la struttura di un
sistema mostrando le classi del sistema, i loro attributi, le operazioni (o metodi) e le relazioni tra
le classi. Per i dettagli fare riferimento alle specifiche UML [OMG].

Glossario
Classe: Una classe rappresenta un insieme di oggetti che condividono le stesse caratteristiche,
vincoli e semantiche. La classe definita in termini di attributi e operazioni.
Cliente: Il Cliente una persona, gruppo o organizzazione che richiede una soluzione che soddisfi
le proprie richieste e aspettative di business. Compratore o utente, attuale o potenziale, di
prodotti o di servizi di un fornitore.
CMMi: Capability Maturity Model Integration
Coesistenza: La capacit di coesistere con altri software nel medesimo ambiente, condividendo
risorse..Vedere anche Portabilit e Requisito Non Funzionale
Communication Diagram: In UML un Behavior Diagram che mostra le istanze delle classi, le
relazioni e il flusso di messaggi tra le istanze. E un tipo di Interaction Diagram. Per idettagli fare
riferimento alle specifiche UML [OMG]. Vedere anche Behavior Diagram e Interaction
Diagram
Complessit: Il grado di difficolt con cui possibile comprendere, manutenere e verificare la
progettazione e/o la struttura interna di un componente o sistema.
Completezza di un Requisito: Il livello in cui il requisito contiene tutte le informazioni necessarie
per la sua comprensione ed implementazione.
Component Diagram: In UML uno Structure Diagram che rappresenta i componenti di
un'applicazione, un sistema o unazienda. Per i dettagli fare riferimento alle specifiche UML
[OMG].
Componente: Il minimo elemento software che, per esempio, pu essere testato singolarmente.
Composite Structure Diagram: In UML uno Structure Diagram che rappresenta la struttura
interna di un classificatore (ad esempio una classe, componente o use case), includendo i punti di
interazione del classificatore con altre parti del sistema. Per i dettagli fare riferimento alle
specifiche UML [OMG].
Comprensibilit: La capacit del prodotto di permettere allutente di capire se il prodotto
adeguato e come possa essere usato per particolari attivit e condizioni di utilizzo. [in accordo
con ISO/IEC 25000, prima ISO 9216] Vedere anche Usabilit.
Configuration Management: Il processo che ha lobiettivo di stabilire e mantenere lintegrit dei
prodotti (componenti, dati e documentazione) e degli artefatti software, durante il ciclo di vita
del prodotto e del progetto. Applica tecniche e strumenti per registrare e controllare le modifiche
a componenti, dati e documentazione, per memorizzare e preparare report sullo stato
dellimplementazione delle modifiche, e per verificarne la conformit con i requisiti specificati
[IEEE 610]
Confine del Sistema: Vedere Margine del sistema.
Conformit: La capacit del prodotto di aderire a standard, regolamentazioni e, norme legali. [in
accordo con ISO/IEC 25000, prima ISO9126]. Vedere anche Requisito Funzionale e Requisito
Non Funzionale
Consistenza: Il grado di uniformit, standardizzazione e coerenza tra documenti o parti di un
componente o di un sistema. [IEEE 610]

Glossario
Context Diagram: Un diagramma che rappresenta gli attori esterni ad un sistema che potrebbe
interagire con tale sistema.
Contratto: E un accordo formale tra il Fornitore ed il Cliente, che specifica e descrive le richieste
del Cliente
Controllo del Rischio: Il processo attraverso il quale vengono prese le decisioni e vengono
realizzate le misure protettive per la riduzione dei rischi a determinati livelli o per il
mantenimento dei rischi entro livelli specificati.
Controllo di Qualit (QC): Parte della Gestione della Qualit focalizzata a soddisfare i requisiti di
qualit [ISO 9000]
Copertura: Il grado, espresso come percentuale, con il quale uno specifico elemento di copertura
stato verificato da un insieme di test.
Criterio di Accettazione: Il criterio di uscita che un componente o sistema deve soddisfare per
poter essere accettato da un utente, un cliente o unaltra entit autorizzata. [IEEE 610]
Criterio di Qualit: Definisce dei criteri affinch un requisito oppure una Specifica dei Requisiti
sia di buona qualit. Ogni requisito deve essere corretto, fattibile, necessario, prioritizzato, non
ambiguo, verificabile, singolare. Ogni Specifica dei Requisiti deve essere completa, consistente,
modificabile, tracciabile.
Criticit dei Requisiti: La valutazione del rischio di un requisito, attraverso la stima del danno
causato dalla sua mancata realizzazione.

Glossario
D
Defect Management: Il processo di riconoscimento, analisi, correzione ed eliminazione dei difetti.
Comprende anche la memorizzazione dei difetti, classificandoli e identificandone limpatto.
[IEEE 1044]
Deployment Diagram: In UML uno Structure Diagram che rappresenta l'architettura dei sistemi in
fase operativa (in esecuzione). Per i dettagli fare riferimento alle specifiche UML [OMG]
Diagramma Comportamentale: Vedere Behavior Diagram
Diagramma Strutturale: Vedere Structure Diagram
Difetto: Una falla in un componente o sistema che pu causare un esito negativo (failure)
nellesecuzione delle sue funzionalit rispetto al risultato e comportamento atteso, come ad
esempio unistruzione o una definizione dei dati scorretta. Un difetto, se riscontrato durante
lesecuzione, pu causare un failure del componente o sistema. [in accordo con ISTQB]
Dipendenza: Una specifica relazione di un insieme di componenti, requisiti o altri artefatti che
risultano dipendenti ad un altro insieme rispettivamente di componenti, requisiti o altri artefatti.
[TGilb]
Disponibilit: Identifica il grado col quale un sistema od un suo componente operativo ed
accessibile quando ne viene richiesto lutilizzo. Viene spesso espressa come valore
percentuale.[IEEE 610]
Dominio di Business: (1) Linsieme delle classi che rappresentano gli oggetti nel modello di
business che deve essere implementato. (2) In generale unarea di business che argomento
principale della soluzione pianificata o impattata da questa.

Glossario
E
Efficienza: La capacit del prodotto di fornire appropriate prestazioni, relativamente alla quantit di
risorse utilizzate sotto specifiche condizioni. [in accordo con ISO/IEC 25000, prima ISO 9126]
Vedere anche Requisito Non Funzionale
Elemento di Configurazione: Un artefatto, un documento o prodotto (hardware e/o software)
utilizzabile da un utente finale e che viene gestito come una singola entit nel processo di
Configuration Management [IEEE 610].
Elicitazione: L'attivit di ottenere informazioni da altre persone. Nel contesto dellIngegneria dei
Requisiti, lElicitazione il processo di raccolta dei requisiti dagli stakeholder. Vedere
Identificazione dei Requisiti
Elicitazione dei Requisiti: Vedere Elicitazione, Identificazione dei Requisiti.
Entit: (1) Un elemento o insieme di elementi che ha una esistenza distinta e separata, anche se non
deve essere una esistenza materiale. (2) Un'astrazione dalla complessit di un certo dominio.
Entity Relationship Diagram (ERD): Diagramma Entit-Relazioni. vedere Modello Entit-
Relazioni.
ERD: Entity-Relationship Diagram (Diagramma Entit-Relazioni).
ERM: Entity-Relationship Model (Modello Entit-Relazioni).
Errore: Unazione umana che produce un risultato non corretto (difetto). [IEEE 610]
Esigenza di Business: Esigenza manifestata ( in modo esplicito od implicito) dal cliente, che pu
tramutarsi in Richiesta (quando considerata prioritaria) formalizzata poi in Requisito (quando
considerata economicamente e tecnicamente realizzabile).
Esito Negativo: Deviazione (discrepanza) del componente o sistema dal risultato. Dal
comportamento atteso o dal servizio che dovrebbe fornire. [Fenton]
Esperti del Dominio: Uno stakeholder che possiede specifiche esperienze, conoscenze e abilit su
uno specifico aspetto del dominio del problema.
Evidenza di Esito Negativo (Failure mode): La manifestazione fisica o funzionale di un esito
negativo (failure). Per esempio, un sistema che evidenzi un esito negativo pu essere
caratterizzato da operazioni lente, da output non corretti o da interruzioni nellesecuzione. [IEEE
610]
Extreme Programming (XP): Metodologia dellIngegneria del Software utilizzata all'interno di
sviluppo software Agile. Le caratteristiche principali sono: Pair Programming, Collective
Ownership, Refactoring, Coding Standards, Refactoring, Vedere anche Sviluppo Software Agile.

Glossario
F
Failure: vedere Esito negativo
Failure Mode and Effect Analysis (FMEA): Un approccio sistematico allidentificazione del
rischio e allanalisi per individuare i possibili esiti negativi e cercare di prevenire il loro
manifestarsi. . [IEEE 610]
Fase dei Requisiti: Il periodo di tempo nel ciclo di vita del software durante il quale i requisiti di
un prodotto software sono definiti e documentati. [IEEE 610]
FMEA: Vedere Failure Mode and Effect Analysis
Fornitore: Una persona, un gruppo o organizzazione che fornisce, basandosi sulle richieste del
Cliente, la relativa soluzione.
FPA: Function Point Analysis. Vedere Analisi dei Function Point
Function Point: Unit di misura utilizzata per esprimere la quantit di funzionalit di business
fornite da un sistema informativo. Vedere anche Function Point Analysis
Funzionalit: La capacit del prodotto di fornire funzioni che soddisfino le richieste ed esigenze
stabilite (esplicite ed implicite) quando il software viene utilizzato sotto specifiche condizioni.
[in accordo con ISO/IEC 25000, prima ISO 9126]. Vedere anche Requisito Funzionale
Funzione: Una descrizione di cosa fa un sistema od un suo componente. Una funzione ha un
corrispondente scopo implicito ed una parte fondamentale della descrizione del sistema. Una
funzione spesso pu essere scomposta in un insieme gerarchico di sotto-funzioni. [TGilb]

Glossario
G
Garanzia della Qualit: E un insieme di attivit del processo di Gestione della Qualit, che
comprende tutte le attivit sistematiche e pianificate in un sistema di qualit, che stato
dimostrato essere necessarie per fornire la giusta confidenza affinch un elemento soddisfi i
requisiti di qualit. [ISO 9000]
Gestione dei Difetti: Vedere Defect Management
Gestione dei Requisiti: Processo di gestione di tutti i requisiti che sono stati ricevuti o definiti dal
gruppo di progetto (che includono requisiti funzionali e requisiti non funzionali), oppure sono
stati richiesti dallorganizzazione sul progetto [in accordo con CMMI].
Gestione del Rischio: Processo di applicazione di procedure e pratiche in modo sistematico per le
attivit di identificazione, analisi, prioritizzazione e controllo del rischio.
Gestione della Qualit: Processo definito da un insieme di attivit necessarie a gestire e controllare
unorganizzazione dal punto di vista della qualit. La gestione ed il controllo della qualit
generalmente includono la definizione di procedure e obiettivi di qualit, la pianificazione della
qualit, il controllo di qualit, la Garanzia di Qualit e il miglioramento della qualit. [ISO 9000]
Grado di Obbligatoriet: Il grado di impegno (commitment) nel soddisfare un requisito.
Guasto: Vedere Difetto.
GUI: Graphical User Interface. Un tipo di User Interface (Interfaccia Utente) che permette agli
utenti di interagire con dispositivi elettronici attraverso icone grafiche ed indicatori visuali.

Glossario

Glossario
I
Identificazione dei Requisiti: Il processo di raccolta dei requisiti dagli stakeholder.
Identificazione del Rischio: Il processo di identificazione dei rischi usando tecniche quali il
brainstorming, le checklist e lo storico degli esiti negativi (failure).
Impatto: Misura, stimata o effettiva degli effetti/conseguenze di unidea di progettazione di un
requisito in determinate condizioni.
Ingegnere dei Requisiti: Ruolo interno allIngegneria dei Requisiti. Pu essere un Responsabile
(Manager) dei Requisiti oppure uno Sviluppatore dei Requisiti. Vedere anche Responsabile dei
Requisiti e Sviluppatore dei Requisiti
Ingegneria dei Requisiti: Disciplina parte dellIngegneria del Software che si occupa di definire e
gestire i requisiti di sistemi software e hardware.
Installabilit: La capacit del prodotto di essere installato in un specifico ambiente. [in accordo con
ISO/IEC 25000, prima ISO 9126]. Vedere anche Portabilit.
Integrazione: Il processo di combinazione di componenti o sistemi in aggregati pi grandi
Interaction Diagram: In UML un sottoinsieme di Behavior Diagram che evidenziano le
interazioni fra gli oggetti: Communication Diagram, Interaction Overview Diagram, Sequence
Diagram e Timing Diagram. Per i dettagli fare riferimento alle specifiche UML. [OMG]. Vedere
anche Behavior Diagram, Communication Diagram, Interaction Overview Diagram, Sequence
Diagram e Timing Diagram .
Interaction Overview Diagram: In UML, una variante di un Activity Diagram che d una visione
di insieme del flusso di controllo all'interno di un sistema o di un processo di business. E un tipo
di Interaction Diagram. Per i dettagli fare riferimento alle specifiche UML. [OMG] Vedere anche
Behavior Diagram e Interaction Diagram
Interoperabilit: La capacit del prodotto di interagire con uno o pi componenti o sistemi
specificati. [In accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche Requisito
Funzionale.
Intervista: Una tecnica di Identificazione dei Requisiti basata su conversazioni in cui
l'intervistatore fa delle domande allintervistato per ottenere informazioni su uno specifico
argomento.
Ispezione: Un tipo di peer review che si basa su un verifica di documenti od oggetti per rilevare
difetti, come ad esempio violazioni di standard di programmazione e non conformit di
documentazione di pi alto livello. la tecnica di review pi formale e si basa quindi su una
procedura documentata. [In accordo con IEEE 610, IEEE 1028] Vedere anche Peer review.

Glossario
L
Linguaggio di Modellazione: Qualsiasi linguaggio artificiale che pu essere utilizzato per
descrivere informazioni, conoscenze o sistemi attraverso una struttura definita da un insieme
coerente di regole.
Livello di Formalizzazione: La documentazione di prodotto, che include le Specifiche dei
Requisiti e della Soluzione, pu essere creata utilizzando tre differenti livelli di formalizzazione:
Non formale, Semi formale e Formale
Livello di Maturit: Il grado di miglioramento dei processi misurato su un insieme predefinito di
aree di processo, per le quali vengono raggiunti tutti i rispettivi obiettivi. [in accordo con CMMi]
Livello di Rischio: Limportanza di un rischio definita dalla sua probabilit di accadimento e dal
suo impatto. Un livello di rischio pu essere espresso sia qualitativamente (ad esempio alto,
medio, basso) sia quantitativamente.

Glossario
M
Macchina a Stati Finiti: Vedere State Machine Diagram
Manifesto Agile: Una dichiarazione sui valori che sono alla base dello sviluppo del software
secondo lapproccio Agile. I valori sono:
Gli individui e le loro interazioni, pi che i processi e gli strumenti
Il software funzionante, pi che una documentazione omnicomprensiva
La collaborazione con il cliente, pi che la negoziazione dei contratti
Il rispondere ai cambiamenti, pi che il seguire un piano
Vedere anche Approccio Agile.
Manutenibilit: La capacit di un prodotto di essere modificato per correggere difetti, per
soddisfare nuovi requisiti, o per essere adattato a cambiamenti nellambiente operativo. [in
accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche Requisito Non Funzionale
Manutenzione: Modifiche ad un prodotto dopo il suo rilascio per correggere difetti, per migliorare
le prestazioni od altre funzionalit, o per adattare il prodotto ad un ambiente modificato. [in
accordo con IEEE 1219]
Mappa Concettuale: Un diagramma utilizzato per rappresentare parole, idee, attivit o altri
elementi connessi e disposti intorno ad una parola chiave o idea centrale. Le mappe concettuali
sono utilizzate per identificare, visualizzare, strutturare e classificare le idee e come supporto
per lanalisi, lorganizzazione, e la risoluzione di problemi, per prendere decisioni e per scrivere
la documentazione.
Margine del Sistema: Il confine tra un sistema e il suo contesto.
Matrice di Tracciabilit dei Requisiti (RTM): Un documento, di solito sotto forma di una tabella,
che correla due documenti di riferimento, che richiedono una relazione molti a molti per
determinare la completezza della relazione.
Maturit: (1) La capacit di unorganizzazione relativa allefficacia e allefficienza dei suoi
processi e delle sue procedure operative. Vedere anche Capability Maturity Model. (2) La
capacit del prodotto software di evitare esiti negativi causati da difetti presenti nel software.
[ISO 9126] Vedere anche Affidabilit e Requisito Non Funzionale.
Metodo Delphi: Una tecnica utilizzata per la stima dei costi e delle risorse di un progetto, basata su
una comunicazione strutturata utilizzata per condurre previsioni attraverso interazioni di gruppi
di esperti [Linstone75].
Metrica: Definisce una scala di misurazione ed il relativo metodo usato per la misurazione. [ISO
14598]
Miglioramento di Processo: Un insieme programmato di attivit volte a migliorare le prestazioni e
la maturit dei processi dellorganizzazione [CMMi]

Glossario
Milestone: Un momento temporale definito nella pianificazione di un progetto, in corrispondenza

del quale dovrebbero essere effettuati specifici rilasci (anche intermedi) e/o ottenuti specifici
risultati.
Misura: Il numero o la categoria assegnata ad un attributo di unentit, che si ottiene attraverso una
misurazione. [ISO 14598]
Misurazione: Il processo di assegnazione di una misura per quantificare un attributo di unentit.
[ISO 14598] Vedere anche Misura
Mitigazione del Rischio: Vedere Controllo del rischio.
Modello: Un sistema di assunzioni, concetti e le relative relazioni, che consentono di descrivere
(modellare) in modo approssimativo un aspetto specifico della realt.
Modello a V: Un modello per descrivere le fasi del ciclo di sviluppo del software
dallidentificazione dei requisiti alla manutenzione. Il modello a V illustra come le attivit di test
possono essere integrate nella corrispondente attivit di sviluppo.
Modello Concettuale: Un modello che rappresenta i concetti (entit) e le relative relazioni tra di
essi. Scopo del modello concettuale di chiarire ed esprimere il significato di termini e concetti
utilizzati dagli esperti del dominio, per indirizzare il problema di business e stabilire le relazioni
corrette tra concetti differenti. Viene anche chiamato Modello del dominio.
Modello dei Requisiti: Un modello che descrive larea del problema ed generalmente progettato
nelle fasi iniziali del progetto. Questo modello viene utilizzato principalmente per lAnalisi dei
Requisiti e la stima dei costi e dei tempi, e fornisce una base per il Modello della soluzione.
Modello del Ciclo di Vita: La suddivisione della vita di un prodotto o di un progetto in fasi.
[CMMI]
Modello del Dominio: Vedere Modello Concettuale
Modello della Soluzione: Un modello che descrive larea della soluzione da differenti punti di
vista del sistema e determina lidea dellimplementazione dei Requisiti Funzionali e Non
Funzionali. Il modello della soluzione di business fornisce una base per la progettazione della
soluzione.
Modello di Maturit: Una raccolta strutturata di elementi che descrivono alcuni aspetti della
maturit di unorganizzazione, e supportano nella definizione e nella comprensione dei processi
di unorganizzazione. Un modello di maturit fornisce spesso un linguaggio comune, una visione
condivisa ed un modello per prioritizzare le azioni di miglioramento.
Modello di Processo: (1) Uno schema dove i processi della stessa natura sono classificati
allinterno di un modello complessivo, ad esempio un modello di miglioramento dello sviluppo.
(2) Una descrizione dei processi di sviluppo indipendentemente dal metodo del processo.
Modello Entit-Relazioni: Attraverso luso di Entity Relationship Diagram (ERD), modella i
blocchi costruttivi di entit, relazioni tra entit, attributi di relazioni ed entit. una
rappresentazione dei dati astratta e concettuale.

Glossario
Modello Kano: Un modello di soddisfazione del cliente che divide gli attributi di prodotto in tre
categorie: attributi fondamentali o di soglia (threshold), attributi prestazionali (performance),
attributi di soddisfazione (excitement).
Moderatore: Il principale responsabile di unispezione o di altri processi di revisione (review).
Modificabilit: La capacit del prodotto di consentire che specifiche modifiche software possano
essere implementate. [in accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche
manutenibilit.
Modulo: Vedere Componente.
MoSCoW: Una tecnica che permette di definire il grado di obbligatoriet di un requisiti e di
prioritizzare i requisiti di un progetto, assegnando uno dei seguenti termini in modo appropriato:
deve avere (Must have), dovrebbe avere (Should have), potrebbe avere (Could have) e vorrebbe
avere in futuro (Will not have this time but will have in future).

Glossario

Glossario
O
Obiettivo: Uno stato o risultato desiderato di unattivit. Gli obiettivi dovrebbero essere misurabili
e definiti in termini di tempo in modo che ne possa essere verificato lavanzamento.
Object Diagram: In UML uno Structure Diagram che rappresenta gli oggetti e le loro relazioni in
un certo istante, tipicamente un caso speciale del Class Diagram o del Communication Diagram.
Per i dettagli fare riferimento alle specifiche UML. [OMG]
Oggetto: NellAnalisi e Progettazione Object Oriented (OOAD) un oggetto rappresenta unistanza
di una classe. Vedere anche Classe, Analisi e Progettazione Object-Oriented.
OOA: Vedere Analisi e Progettazione Object-Oriented.
OOAD: Vedere Analisi e Progettazione Object-Oriented.
OOD: Vedere Analisi e Progettazione Object-Oriented.
Operabilit: La capacit del prodotto di consentire agli utenti di operare su di esso e di
controllarlo. [in accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche Usabilit.

Glossario
P
Package Diagram: In UML uno Structure Diagram che mostra come gli elementi del modello
sono organizzati in package e le relative dipendenze tra di essi. Per i dettagli fare riferimento alle
specifiche UML. [OMG]
Pair Programming: Un approccio allo sviluppo del software in cui due programmatori
programmano le linee di codice (codifica e/o test) lavorando sullo stesso computer. Questo
implicitamente significa avere una attivit continuativa e immediata di code review.
Peer Review: Una revisione (review) di un prodotto software svolta dai colleghi dellautore, con lo
scopo di identificare difetti e/o miglioramenti. Esempi di peer review sono lispezione, la review
tecnica ed il walkthrough.
Planning Game/Planning Poker: Una tecnica utilizzata per la stima dei costi e delle risorse,
utilizzata nellApproccio Agile.
Portabilit: La capacit del prodotto di essere trasferito da un ambiente hardware o software ad un
altro ambiente. [in accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche Requisito Non
Funzionale
Prestazione: Il grado con il quale un sistema o un componente realizza le funzionalit per cui
stato progettato, con prefissati vincoli relativi al tempo di elaborazione ed al tasso di throughput.
[In accordo con IEEE 610] Vedere anche Efficienza.
Priorit: E una valutazione dellimportanza/urgenza di un requisito
Prioritizzazione: (Assegnazione della priorit) Un processo per la definizione dellimportanza di
implementazione di un requisito.
Problema: E la descrizione di cosa il cliente desidera fare per trovare una soluzione alle sue
mancanze, richieste o necessit. Il problema descrive o aiuta a descrivere le richieste di un
cliente.
Problema di Business: E la descrizione di cosa il cliente desidera fare per realizzare i suoi
processi di business. Il problema descrive o aiuta a descrivere le richieste di business di un
cliente.
Processo: Un insieme di attivit correlate tra loro, che trasformano input in output. [ISO 12207]
Processo di Business: Un insieme di attivit progettate per produrre un output specifico per un
particolare cliente o mercato.
Processo Software: Insieme di ruoli, documenti e attivit necessari alla creazione di un sistema
software.
Prodotto: Una composizione di software, hardware e altri output del processo di produzione.
Product Backlog: NellApproccio Agile, un insieme di user story, requisiti o funzioni che sono
stati identificati come candidati per una potenziale implementazione, prioritizzati e valutati per la
stima [BABOK]

Glossario
Progetto: Un insieme di attivit che vengono intraprese per raggiungere un obiettivo che soddisfi
specifici requisiti, includi vincoli temporali, di costo e di risorse. Tali attivit sono coordinate,
controllate e caratterizzate da una data di inizio e una data di fine [ISO 9000]
Prototipizzazione GUI: Attivit di creazione di prototipi GUI di applicazioni software o di altri
prodotti per la modellazione dellInterfaccia Utente (User Interface). Vedere anche GUI
Prototipo: Un esempio o modello iniziale costruito per verificare un concetto o un processo, per
comprendere o imparare una funzionalit, per riprodurre successivamente. NellIngegneria dei
Requisiti i prototipi possono essere utilizzati per lidentificazione e la validazione dei requisiti.
Prototipo Orizzontale: Un prototipo che fornisce unampia visione di un sistema completo o ti un
sottosistema, focalizzandosi maggiormente sullInterfaccia Utente rispetto alle funzionalit di
sistema di basso livello.
Prototipo Verticale: Un prototipo che fornisce unelaborazione completa di una singola funzione o
di un sottosistema.
Punto di Vista: Un certa prospettiva su un sistema o sui requisiti.

Glossario
Q
QA (Quality Assurance): Vedere Garanzia della Qualit
Qualit: Il grado con cui un componente, un sistema o un processo soddisfa i requisiti specificati
e/o le esigenze e le aspettative dellutente/cliente. [IEEE 610]
Qualit del Software: Linsieme di funzionalit e caratteristiche di un prodotto software che si
riferisce alla sua capacit di soddisfare esigenze dichiarate o implicite. [In accordo con ISO/IEC
25000]

Glossario
R
Rational Unified Process (RUP): Un modello di processo iterativo incrementale (proprietario e
adattabile) che utilizza la notazione UML per modellare il software. Il ciclo di vita di progetto
composto da quattro fasi sequenziali (concezione, elaborazione, costruzione e transizione)
ciascuna eseguita attraverso una o pi iterazioni.
Recuperabilit: La capacit del prodotto di ristabilire uno specifico livello prestazionale e di
recuperare i dati corrotti, in caso di esito negativo (failure). [in accordo con ISO/IEC 25000,
prima ISO 9126] Vedere anche Affidabilit e Requisito Non Funzionale.
Release: (1) Una versione della soluzione che viene rilasciata per l'installazione e l'utilizzo da parte
dei clienti/utenti finali. (2) Un prodotto (o semi-lavorato) che viene rilasciato, spesso identificato
da una versione. Vedere anche Versione
Requisito: (1) Una condizione o capacit richiesta da una figura interessata al progetto
(stakeholder) per risolvere un problema o raggiungere un obiettivo. (2) Una condizione o
capacit che deve essere raggiunta o posseduta da un sistema, o da un suo componente, per
soddisfare un contratto, uno standard, una specifica, o altri documenti formalmente definiti. (3)
Una descrizione documentata di una condizione o capacit, come in (1) o (2). [In accordo con
IEEE 610]
Requisito di Business/Cliente: Requisito di alto livello che specifica cosa richiede il business ma
NON come implementarlo. Questo tipo di requisito esprime desiderata, richieste e aspettative del
cliente e viene spesso identificato come requisito di business di alto livello o requisito del
cliente.
Requisito del Cliente: Vedere Requisito di Business/Cliente
Requisito di Processo: Vedere vincolo.
Requisito di Prodotto: (1) I requisiti di prodotto specificano caratteristiche, funzionalit, qualit e
servizi richiesti per un dato prodotto e possono essere Requisiti Funzionali e Requisiti Non
Funzionali. Vedere anche Requisito Funzionale e Requisito Non Funzionale (2) Un requisito di
prodotto/componente il livello di astrazione pi basso di definizione dei requisiti (a partire dai
requisiti di soluzione/sistema). Indica una funzione o caratteristica della soluzione.
Requisito di Prodotto/Componente: Vedere punto (2) Requisito di prodotto
Requisito di Sistema: Vedere Requisito di Soluzione/Sistema
Requisito di Soluzione/Sistema: Raffinamento dei requisiti di Business/Cliente. Descrive la
soluzione, cio una delle possibili alternative per soddisfare i requisiti del cliente. La soluzione
pu considerare requisiti non-IT, relativi a modifiche di processo o cambiamenti di
ruolo/organizzativi. Questi requisiti esprimono i requisiti del cliente con termini pi tecnici, che
possono essere utilizzati per le decisioni di progettazione.
Requisito Esterno: Requisito richiesto dal Cliente

Glossario
Requisito Funzionale: Un requisito che specifica una funzionalit che un componente o sistema
deve possedere. [IEEE 610]. Specifica COSA il sistema deve fare
Requisito Interno: Requisito richiesto dal gruppo di progetto/organizzazione del fornitore del
prodotto
Requisito Non Funzionale: Un requisito che descrive gli attributi di qualit del sistema o di alcune
componenti/funzioni: come affidabilit, efficienza, usabilit, manutenibilit e portabilit.
Specifica COME il sistema dovrebbe eseguire le sue funzioni
Responsabile dei Requisiti: Manager dei Requisiti. Persona responsabile delle attivit di
documentazione, analisi, tracciabilit, prioritizzazione e coordinamento dellapprovazione dei
requisiti; successivamente si occupa di controllare le modifiche dei requisiti e comunicarle ai
principali stakeholder. Vedere anche Ingegnere dei Requisiti
Review: La valutazione di un prodotto o di uno stato del progetto per identificare discrepanze
rispetto ai risultati pianificati e per raccomandare miglioramenti. Esempi di review: management
review, la review informale, review tecnica, ispezione e walkthrough. [IEEE 1028]
Revisione: Vedere Review.
Review Formale: Una review caratterizzata da requisiti e procedure documentate, per esempio
lispezione.
Review Informale: Una review che non si basa su una procedura formale (documentata).
Revisore: La persona coinvolta nella review, che identifica e descrive le anomalie nel prodotto o
nel progetto sotto review. I revisori possono essere scelti per rappresentare differenti punti di
vista e ruoli nel processo di review.
Richiesta: Unesigenza di un dato stakeholder.[TGilb].
Ridondanza: Occorrenza multipla delle stesse informazioni in diversi punti.
Rilascio: Vedere Release.
Rischio: La possibilit che un evento indesiderato si verifichi e crei conseguenze non desiderabili o
problemi potenziali. Il livello di rischio determinato dalla probabilit che accada un evento
avverso e dal relativo impatto (il danno risultante dallevento) [ISTQB] Un rischio pu essere un
Rischio di Prodotto o un Rischio di Progetto
Rischio di Prodotto: Rischi di prodotto sono rischi collegati direttamente alla qualit del prodotto,
sono aree potenziali di insuccesso (eventi futuri avversi o pericolo) nel software o nel sistema.
Vedere anche Rischio.
Rischio di Progetto: Un rischio che limita la capacit del progetto a raggiungere i propri obiettivi.
Vedere anche Rischio.
RTM: Vedere Matrice di Tracciabilit dei Requisiti.
RUP: Vedere Rational Unified Process.

Glossario
S
SA: Vedere Analisi del Sistema
Scalabilit: La capacit del prodotto di essere esteso per adattarsi a carichi crescenti. [Gerrard]
Scenario: (1) La progettazione di una sequenza di azioni, eventi o situazioni che portano ad un
risultato specificato. (2) Una sequenza ordinata di interazioni tra entit specificate (ad esempio
un sistema e un attore). (3) In UML: una sequenza di esecuzione di uno use case.
Scrum: Una metodologia Agile per la gestione di progetti. Vedere anche Approccio Agile.
Sequence Diagram: In UML, un Behaviour Diagram che rappresenta le interazioni tra gli oggetti
nella sequenza in cui avvengono. E un tipo di Interaction Diagram. Per i dettagli fare
riferimento alla specifica UML [OMG]. Vedere anche Behavior Diagram e Interaction Diagram
Sicurezza: La capacit del prodotto software di proteggere informazioni/dati dalla
lettura/scrittura/modifica/accesso da parte di persone o sistemi non autorizzati [in accordo con
ISO/IEC 25000, prima ISO 9126] Vedere anche Requisito Funzionale.
Sistema: Un insieme di componenti organizzato per realizzare una specifica funzione o insieme di
funzioni. [IEEE 610]
S.M.A.R.T.: Un termine mnemonico che indica un metodo di definire degli obiettivi attraverso
specifici criteri. S.M.A.R.T. significa:
Specific Specifici e precisi
Measurable Misurabili (quantitativi)
Attainable - Fattibili
Relevant - Pertinenti
Timely - Tempestivi
SME: Subject Matter Expert, Vedere Esperti del Dominio

Soluzione: La risposta alle richieste di un cliente (requisiti di Business/Cliente). Una soluzione pu
essere un sistema o un suo componente, una funzionalit nuova o modificata, una configurazione
modificata, il miglioramento di un processo.
Sorgente dei Requisiti: La fonte da cui sono stati identificati i requisiti. Fonti dei requisiti possono
essere gli stakeholder, dei documenti, i processi di business, sistemi esistenti, il mercato, ecc.
Sostituibilit: La capacit del prodotto di essere utilizzato al posto di un altro prodotto specificato,
per lo stesso scopo e nello stesso ambiente. [in accordo con ISO/IEC 25000, prima ISO 9126]
Vedere anche Portabilit.
Specifica: Un documento che specifica, idealmente in modo completo, preciso e verificabile, i
requisiti, la progettazione, il comportamento o altre caratteristiche di un componente o di un
sistema. Pu specificare anche le procedure per verificare il contenuto ed il rispetto dei criteri di

Glossario
qualit di una Specifica (completezza, consistenza, tracciabilit, modificabilit) e dei requisiti.

[IEEE 610]
Specifica dei Requisiti: Una specifica che descrive l'area del problema di business. (Una specifica
dei requisiti di solito fornita dal cliente e contiene una descrizione delle capacit richieste da
una soluzione dal punto di vista del cliente).
Specifica della Soluzione: Una specifica che descrive larea della soluzione di business da
differenti punti di vista. Esistono differenti tipi di Specifica: Specifica funzionale, Specifica dei
Requisiti di Sistema o Specifica dei Requisiti Software.
Sponsor: Uno stakeholder responsabile per la contrattualizzazione o il pagamento del progetto.
Stabilit: La capacit del prodotto di evitare effetti inattesi a fronte di modifiche nel software. [in
accordo con ISO/IEC 25000, prima ISO 9126]. Vedere anche Manutenibilit.
Stakeholder: Qualsiasi persona che abbia un interesse in un progetto IT. Gli stakeholder del
progetto sono le persone e le organizzazioni che sono coinvolte attivamente nel progetto o i cui
interessi possono essere influenzati in base al risultato dellesecuzione o del completamento del
progetto. [TGilb]
Standard: Un insieme di requisiti, formali e a volte obbligatori, sviluppati e utilizzati per
prescrivere approcci coerenti al modo di operare, oppure per fornire linee guida (ad esempio,
standard ISO/IEC, standard IEEE e standard organizzativi). [CMMi]
State Machine Diagram: In UML un Behavior Diagram che rappresenta un sistema il cui
comportamento pu essere modellato attraverso un numero finito di stati, di transizioni tra stati,
e di azioni. Per i dettagli fare riferimento alla specifica UML [OMG]. Vedere anche Behavior
Diagram
Stima: Un valore numerico di un attributo scalare di sistema, che considera il valore passato,
attuale e futuro. Gli attributi considerati comprendono attributi di costo e prestazionali. Le stime
vendono di solito eseguite quando la misura diretta : impossibile (futuro), poco pratica (passato)
o dispendiosa ( attuale). [TGilb]
Structure Diagram: Diagramma Strutturale. In UML un tipo di diagramma che rappresenta gli
elementi strutturali di un sistema, indipendentemente dal tempo e dalla sequenza di esecuzione.
Sono compresi i Class Diagram, I Composite Structure Diagram, I Component Diagram, I
Deployment Diagram, gli Object Diagram e I Package Diagram.
Strumento di Defect Management: Uno strumento che facilita la memorizzazione ed il
tracciamento dello stato dei difetti e delle relative correzioni (bug fix). Questi strumenti hanno
spesso delle funzionalit per tracciare e controllare il ciclo di vita dei difetti (lassegnazione,
lanalisi, la diagnosi, la correzione ed il test confermativo), e per generare della reportistica.
Strumento di Gestione dei Requisiti: Uno strumento che supporta la memorizzazione dei requisiti
e dei relativi attributi (ad esempio priorit e criticit). Facilita anche la tracciabilit, attraverso la
definizione di requisiti di differenti livello, e la gestione delle modifiche dei requisiti. Alcuni
strumenti di Gestione dei Requisiti forniscono anche il supporto per lanalisi statica, come i
controlli di consistenza e di conformit a precise regole e criteri di qualit sui requisiti.

Glossario
Strumento di Modellazione: Uno strumento che supporta la creazione, la modifica e la verifica di

modelli di software o di sistemi. [Graham].
Sviluppatore dei Requisiti: Persona principalmente coinvolta nellidentificazione, analisi,
documentazione e prioritizzazione dei requisiti. Vedere anche Ingegnere dei Requisiti
Sviluppo dei Requisiti: Un insieme di attivit, compiti, tecniche e strumenti per identificare,
analizzare e validare i requisiti di Business/cliente, di soluzione/sistema e di
componente/funzione di un prodotto.
SysML: vedere Systems Modeling Language.
Systems Modeling Language (SysML): Un linguaggio di modellazione per applicazioni di
Ingegneria dei Sistemi. Supporta la specifica, l'analisi, la progettazione, la verifica e la
validazione di una vasta gamma di sistemi e di sistemi-di-sistemi.

Glossario
T
Testabilit: La capacit del prodotto (realizzato o modificato) di essere testato. [in accordo con
ISO/IEC 25000, prima ISO 9126] Vedere anche Manutenibilit.
Testabilit di un Requisito: Il livello di chiarezza ed esaustivit di un requisito, che consente
lanalisi e la progettazione del test e dei relativi casi di test, e la loro esecuzione per validare il
requisito. [IEEE 610]
Timing Diagram: In UML un diagramma che rappresenta il comportamento di uno o pi elementi
allinterno di una scala dei tempi (linea della vita), fornendo una rappresentazione visuale dei
cambiamenti di stato o di condizione degli oggetti in base a vincoli di durata e di tempo. Per i
dettagli fare riferimento alla specifica UML. [OMG]. E un tipo di Interaction Diagram. Vedere
anche Behavior Diagram e Interaction Diagram
Tolleranza allErrore: La capacit del prodotto di possedere un grado di affidabilit dei risultati
ottenuti in presenza di condizioni non standard. Vedere anche Affidabilit e Requisito Non
Funzionale
Tracciabilit: La capacit di identificare elementi correlati nella documentazione e nel software, ad
esempio, per esempio tra i requisiti di business ed i requisiti di soluzione, oppure tra i requisiti ed
i relativi casi di test.. Il collegamento tra gli artefatti di progetto pu essere tra elementi dello
stesso livello (tracciabilit orizzontale) o di livello differente (tracciabilit verticale). Vedere
anche Tracciabilit orizzontale, Tracciabilit verticale.
Tracciabilit dei Requisiti: La capacit di definire, identificare e seguire la tracciabilit dei
requisiti negli elementi correlati alla documentazione e al software, sia a partire dai requisiti fino
agli elementi di livello pi basso (p.e. documentazione di test), sia a partire dagli elementi di
livello pi basso fino ai requisiti. [Pinheiro FAC e Goguen J.A]. Vedere anche Tracciabilit,
Tracciabilit orizzontale, Tracciabilit verticale.
Tracciabilit Orizzontale: La tracciabilit tra artefatti sullo stesso livello di astrazione (per
esempio tracciabilit da un requisito di Business ad un altro Requisito di Business che lo estende
o da cui dipende la sua progettazione/implementazione)
Tracciabilit Verticale: La tracciabilit tra artefatti su diversi livelli di astrazione (per esempio
tracciabilit da un Requisito di soluzione al test case di validazione).
Transizione di Stato: Un passaggio da uno stato allaltro di un componente o sistema.

Glossario
U
UCP: Use Case Point
UML: Vedere Unified Modeling Language.
Unified Modeling Language (UML): (Linguaggio di Modellazione Unificato). Un linguaggio
standard per applicazioni dell'Ingegneria del Software. UML comprende una serie di tecniche di
notazione grafica per creare modelli visuali di sistemi software, come gli Use Case Diagram, gli
Activity Diagram, i Class Diagram e molti altri.
Usabilit: La capacit del prodotto di essere compreso, utilizzato e graditoallutente quando usato
sotto specifiche condizioni. [in accordo con ISO/IEC 25000, prima ISO 9126] Vedere anche
Use Case: Una sequenza di transazioni in uninterazione tra un attore ed il sistema (o un suo
componente) con un risultato tangibile, dove lattore pu essere un utente o chiunque possa
scambiare informazioni con il sistema.
Use Case Diagram: In UML un Behavior Diagram che rappresenta gli use case, gli attori e le loro
interrelazioni. Per i dettagli fare riferimento alla specifica UML. [OMG] Vedere anche Behavior
Diagram.
Use Case Point (UCP): Tecnica di stima software utilizzata per calcolare il costo di un progetto di
sviluppo software. la tecnica migliore nei progetti che utilizzano le metodologie UML (Unified
Modeling Language) e RUP (Rational Unified Process) durante le fasi di analisi e sviluppo
software. UCP richiede la scrittura dei requisiti di un sistema sotto forma di use case. La
dimensione del software (in UCP) viene calcolata basandosi sugli elementi degli use case di
sistema, tenendo conto anche di fattori legati a considerazioni tecniche e ambientali.
User Story: Le user story sono descrizioni semplici e brevi di una funzione definite dalla
prospettiva della persona che desidera la nuova capacit, generalmente un utente o un cliente
del sistema. Vengono espresse sotto forma di frase:
COME un [ruolo dellutente finale] DESIDERO CHE [desiderata] IN MODO TALE DA [il
razionale] [in accordo con Cohn]
Utente: Una persona che usa un prodotto software.
Utente finale: Vedere utente.
Utilizzo di Risorse: Vedere Efficienza e Requisito Non Funzionale

Glossario
V
Validazione: (1) Conferma, attraverso lesame e la valutazione di evidenze obiettive, che i requisiti
per un uso o per unapplicazione specifica siano stati soddisfatti. [ISO 9000] (2) Le attivit di
Validazione dimostrano che un prodotto o un suo componente esegue le attivit come richiesto,
quando posto nellambiente per cui stato sviluppato. Permettono quindi di capire di aver
costruito il prodotto CORRETTO [CMMi]
Validazione dei Requisiti: conferma, attraverso lesame e la valutazione di evidenze obiettive, che
un singolo requisito o un insieme di requisiti definisce il sistema corretto, come stato inteso
dagli stakeholder [in accordo con ISO/IEC/IEEE 29148]
Valutazione (Assessment): Attivit per determinare il valore quantitativo o qualitativo di un
prodotto, di un servizio, di unattivit o di un processo relativamente a determinati criteri di
qualit o di accettazione.
Valutazione del Processo: Una valutazione disciplinata dei processi software di un'organizzazione
con riferimento ad uno specifico modello. [ISO 15504]
Verifica: (1) Conferma, attraverso lesame e la valutazione di evidenze obiettive, che specifici
requisiti sono stati soddisfatti. [ISO 9000] (2) Fornisce dei momenti di controllo (checkpoint)
dove vengono eseguite delle verifiche su specifici rilasci (deliverable) o su prodotti intermedi,
che confermino di aver coperto prodotto correttamente [CMMi].
Verifica dei Requisiti: Conferma, attraverso lesame e la valutazione di evidenze obiettive, che un
requisito o un insieme di requisiti stato revisionato (review), per assicurarsi che le
caratteristiche di buon requisito siano soddisfatte [in accordo con ISO/IEC/IEEE 29148]
Versione: Un identificativo numerico univoco che permette di distinguere la specifica release di un
prodotto o di un software da precedenti e future release.
Venditore: Vedere Fornitore.
Vincolo: Una restrizione che modifica un requisito o un insieme di requisiti, limitando linsieme di
soluzioni accettabili. Vedere anche Vincolo di Business e Vincolo Tecnico.
Vincolo di Business: Una restrizione relativa alla flessibilit del progetto di implementare la
soluzione di business richiesta [BABOK]
Vincolo Tecnico: Una restrizione relativa allarchitettura della soluzione, come le piattaforme
hardware e software, il linguaggio di programmazione o la tecnologia, il software che deve
essere utilizzato [BABOK]
Vision di Progetto: Definisce un insieme di obiettivi di un progetto che permettono di verificare se
il progetto ha apportato il valore richiesto. Una Vision realizzata attraverso degli obiettivi visti
dalla prospettiva del business, che dovrebbero essere soddisfatti per uno specifico progetto e
dovrebbero essere S.M.A.R.T.
Vista: Vedere Punto di Vista

Glossario
V-Model: Vedere Modello a V

Glossario
X
XP: Vedere Extreme Programming

Glossario
W
Walkthrough: Una tipo di riunione in cui lautore presenta agli stakeholder il contenuto di un
documento, con lobiettivo di raccogliere informazioni e commenti, e di raggiungere una
comprensione comune del suo contenuto, senza la necessit di unattivit preparatoria pre-
riunione da parte degli stakeholder. [Freedman e Weinberg, IEEE 1028]. Vedere anche Peer
review.
Workshop: Un tipo di riunione focalizzato su di uno specifico argomento o documento
(preventivamente definito e annunciato ai partecipanti), che di solito coinvolge stakeholder
rappresentanti differenti aree e/o domini per un periodo breve ma intenso.

Glossario
6. ANNESSO A (INFORMATIVO)
Indice delle fonti; le seguenti fonti non-normative sono state usate nella costruzione di questo glossario:
[BABOK] A Guide to the Business Analysis Body of Knowledge (BABOK Guide),

http://www.iiba.org/BABOK-Guide/BABOK-Guide-Online/appendix-a-glossary.aspx
[Beizer] B. Beizer (1990), Software Testing Techniques, van Nostrand Reinhold, ISBN 0-442- 20672-0
[BPMN.ORG] Object Management Group/Business Process Management Initiative
[CMM] M. Paulk, C. Weber, B. Curtis and M.B. Chrissis (1995), The Capability Maturity Model,
Guidelines for Improving the Software Process, Addison-Wesley, ISBN 0-201-54664-7
[CMMI] M.B. Chrissis, M. Konrad and S. Shrum (2004), CMMI, Guidelines for Process Integration and
Product Improvement, Addison Wesley, ISBN 0-321-15496-7
[Cohn] http://www.mountaingoatsoftware.com/agile/user-stories
[Fenton] N. Fenton (1991), Software Metrics: a Rigorous Approach, Chapman & Hall, ISBN 0-53249-
425-1
[Freedman and Weinberg] D. Freedman and G. Weinberg (1990), Walkthroughs, Inspections, and
Technical Reviews, Dorset House Publishing, ISBN 0-932633-19-6.
[Gerrard] P. Gerrard and N. Thompson (2002), Risk-Based E-Business Testing, Artech House Publishers,
ISBN 1-58053-314-0.
[Gilb and Graham] T. Gilb and D. Graham (1993), Software Inspection, Addison-Wesley, ISBN 0-201-
63181-4.
[Graham] D. Graham, E. van Veenendaal, I. Evans and R. Black (2007), Foundations of Software
Testing, Thomson Learning, ISBN 978-1-84480-355-2
[Laplante] Laplante, Phil (2009). Requirements Engineering for Software and Systems (1st ed.).
Redmond, WA: CRC Press. ISBN 1-42006-467-3.
[OMG] OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2.
[Pinheiro F.A.C. and Goguen J.A] Pinheiro F.A.C. and Goguen J.A., An object-oriented tool for tracing
requirements, in: IEEE Software 1996, 13(2), pp. 52-64
[TGilb] see: http://gilb.com, Planguage Concept Glossary

Glossario
7. ANNESSO B (METODO DI COMMENTO AL PRESENTE GLOSSARIO)
Come descritto nel 1 del documento di supporto e completamento a questo Glossario, ovvero il gi
citato :
DOCUMENTO DI TRACCIABILIT dei termini tra GLOSSARIO REQB in LINGUA

ORIGINALE e GLOSSARIO REQB tradotto in LINGUA ITALIANA
la traduzione stata effettuata senza seguire il mero approccio di tradurre tutti i termini in ogni caso,
prescindendo magari addirittura a volte dalla semantica del termine da tradurre.
Lapproccio seguito stato invece improntato a cercare di esaminare la semantica del termine, la
sintassi e di cercare di trovare un compromesso tra le due che rendesse anche in Lingua Italiana il
significato del termine inglese. Questo talvolta stato molto naturale, a volte molto meno, ed in alcuni
casi addirittura impossibile.
Tale approccio sicuramente opinabile, ma ogni tentativo di traduzione di glossari di terminologia
tecnica che si sviluppano prevalentemente in una lingua presta il fianco a commenti e opinioni diverse.
Quindi commenti e suggerimenti sono sicuramente graditi e la loro approvazione sempre
soggetta ad una attenta analisi da parte del Comitato Scientifico di ITA-STQB. Qualora approvate, le
modifiche alla traduzione del presente Glossario, daranno luogo allemissione di una nuova revisione del
presente documento e del documento di supporto sopra citato, che sar identificata con le modifiche nel
Registro delle Revisioni di entrambi i documenti.
Per inviare commenti e suggerimenti si prega di mandare una e-mail al seguente indirizzo:
info@ita-stqb.org


GlossarioStandard Dei Termini Utilizzati Nella Ingegneria v1 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GlossarioStandard Dei Termini Utilizzati Nella Ingegneria v1 3

Uploaded by

Copyright:

Available Formats

Glossario Standard dei Termini utilizzati nellIngegneria

CODICE DOCUMENTO DATA DI EMISSIONE STATO

Versione 2013 Pagina 2 di 42 01 Gennaio 2013

STORIA DELLE MODIFICHE

CHI DATA VERSIONE CONTENUTO

Versione 2014 Pagina 3 di 42 31 Dicembre 2014

INDICE DEI CONTENUTI

Versione 2014 Pagina 4 di 42 31 Dicembre 2014

1. NOTE ALLA TRADUZIONE ITALIANA

Versione 2014 Pagina 5 di 42 31 Dicembre 2014

IEEE Standard 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology

Versione 2014 Pagina 6 di 42 31 Dicembre 2014

ISO 9000:2005. Quality Management Systems Fundamentals and Vocabulary.

ISO/IEC 12207:1995. Information Technology Software Lifecycle Processes.

ISO/IEC 14598-1:1999. Information Technology Software Product Evaluation - Part 1: General

ISO 31000: Risk Management - Principles and Guidelines on Implementation

IEC 31010: Risk Management - Risk Assessment Techniques

ISO/IEC 73: Risk Management Vocabulary

ISTQB Glossary of testing terms ver. 2.1

CMM e CMMI sono marchi registrati di Carnegie Mellon University

BPMN un marchio registrato di Business Process Management Initiative (BPMI), attualmente

RUP un marchio registrato di Rational Software Corporation

TMMI un marchio registrato di TMMi Foundation

UML un marchio registrato di Object Management Group

SysML un marchio registrato di Object Management Group

Versione 2014 Pagina 7 di 42 31 Dicembre 2014

Versione 2014 Pagina 8 di 42 31 Dicembre 2014

Versione 2014 Pagina 9 di 42 31 Dicembre 2014

termina con un rilascio (interno od esterno) di un prodotto eseguibile, un sottoinsieme del

Attributo di un Requisito: Informazioni descrittive di un requisito che arricchiscono la sua

Versione 2014 Pagina 10 di 42 31 Dicembre 2014

Versione 2014 Pagina 11 di 42 31 Dicembre 2014

Versione 2014 Pagina 12 di 42 31 Dicembre 2014

Versione 2014 Pagina 13 di 42 31 Dicembre 2014

Versione 2014 Pagina 14 di 42 31 Dicembre 2014

Versione 2014 Pagina 15 di 42 31 Dicembre 2014

Versione 2014 Pagina 16 di 42 31 Dicembre 2014

Versione 2014 Pagina 17 di 42 31 Dicembre 2014

Versione 2014 Pagina 18 di 42 31 Dicembre 2014

Versione 2014 Pagina 19 di 42 31 Dicembre 2014

Versione 2014 Pagina 20 di 42 31 Dicembre 2014

Versione 2014 Pagina 21 di 42 31 Dicembre 2014

Versione 2014 Pagina 22 di 42 31 Dicembre 2014

Milestone: Un momento temporale definito nella pianificazione di un progetto, in corrispondenza

Versione 2014 Pagina 23 di 42 31 Dicembre 2014

Versione 2014 Pagina 24 di 42 31 Dicembre 2014

Versione 2014 Pagina 25 di 42 31 Dicembre 2014

Versione 2014 Pagina 26 di 42 31 Dicembre 2014

Versione 2014 Pagina 27 di 42 31 Dicembre 2014

Versione 2014 Pagina 28 di 42 31 Dicembre 2014

Versione 2014 Pagina 29 di 42 31 Dicembre 2014

Versione 2014 Pagina 30 di 42 31 Dicembre 2014

Versione 2014 Pagina 31 di 42 31 Dicembre 2014

SME: Subject Matter Expert, Vedere Esperti del Dominio

Versione 2014 Pagina 32 di 42 31 Dicembre 2014

qualit di una Specifica (completezza, consistenza, tracciabilit, modificabilit) e dei requisiti.

Versione 2014 Pagina 33 di 42 31 Dicembre 2014

Strumento di Modellazione: Uno strumento che supporta la creazione, la modifica e la verifica di

Versione 2014 Pagina 34 di 42 31 Dicembre 2014

Versione 2014 Pagina 35 di 42 31 Dicembre 2014

Versione 2014 Pagina 36 di 42 31 Dicembre 2014

Versione 2014 Pagina 37 di 42 31 Dicembre 2014

V-Model: Vedere Modello a V

Versione 2014 Pagina 38 di 42 31 Dicembre 2014