Operazione: Sviluppo di specifiche supplementari
Questa attività cattura i requisiti che non si applicano a specifici casi di utilizzo.
Discipline: Requisiti
Scopo
Per catturare i requisiti che non sono prontamente catturati nei Casi d'uso.
Relazioni
Descrizione principale

In ogni parte delle attività dei requisiti, sulla base delle richieste del portatore d'interesse raccolte, i requisiti non applicabili a specifici Casi d'uso vengono acquisiti nelle Specifiche supplementari. Entrambi i requisiti funzionali e non funzionali possono essere integrati nella specifica supplementare. 

Per maggiori informazioni sulla classificazione e sulla cattura dei requisiti consultare la sezione Concetto: Requisiti.

Mentre si esegue questa attività è importante accertarsi che tutti i requisiti siano specificati a un livello di dettaglio richiesto per la consegna ai progettisti e ai responsabili del test e della stesura della documentazione. Se viene eseguita la traccia dei requisiti o altrimenti se gestiti in maniera formale, accertarsi che ciascun requisito sia evidentemente identificato e classificato.

Passi
Cattura dei requisiti non specifici del caso d'uso

I requisiti funzionali descrivono i comportamenti (funzioni o servizi) del sistema che supporta gli obiettivi, le attività o funzioni dell'utente [MAL2001].

Mentre molti dei requisiti funzionali saranno documentati nella sezione Casi di utilizzo, esistono alcuni requisiti funzionali che non possono essere applicati a specifici casi di utilizzo.  Ad esempio, la segnalazione, il controllo, la stampa, la sicurezza, il supporto/applicazione della concessione di licenze, i requisiti di autenticazione, ecc.  Tali requisiti funzionali sono documentati nelle  Specifiche supplementari.  

Se esiste un numero significativo di requisiti funzionali del sistema, è importante dedicare l'attenzione all'organizzazione di questa sezione.  Una tipica organizzazione è di tipo impostazione funzione/funzione, ma sono possibili dei metodi organizzativi alternativi.  Ad esempio, l'organizzazione per utente o l'organizzazione per sottosistema potrebbe anche essere appropriato.

I requisiti funzionali rappresentano la 'F' in "FURPS+.  Per maggiori informazioni su "FURPS+", consultare Concetto: Requisiti.

Cattura delle qualità di sistema

I requisiti non funzionali includono sia la qualità che i vincoli [MAL2001].  In questa fase vengono discusse le qualità.  I vincoli vengono descritti in una diversa fase.

Le qualità [sistema] sono proprietà o caratteristiche del sistema curate dai relativi portatori d'interesse e perciò influiranno sul loro livello di soddisfazione del sistema. [MAL2001]

Le qualità rappresentano "URPS" in "FURPS+".  Le considerazioni su ciascuna di queste categorie di requisiti sono riportate di seguito:

  • Utilizzabilità  Aspetto e coerenza nell'interfaccia utente.
  • Affidabilità  Disponibilità (la quantità di sistema "attiva"), accuratezza dei calcoli del sistema e la capacità del sistema di ripristinarsi da un errore.
  • Prestazioni: Produttività, tempo di risposta, tempo di recupero, tempo di avvio e tempo di chiusura.
  • Supportabilità: Verificabilità, adattabilità, manutenibilità, compatibilità, configurabilità, installabilità, scalabilità e individuabilità.

Per maggiori informazioni su "FURPS+", così come sulla cattura dei requisiti non funzionali, consultare Concetto: Requisiti.

A seconda del numero delle qualità da documentare per il sistema, si possono fornire delle sezioni secondarie per ciascuno di questi tipi di qualità.

Le seguenti sezioni forniscono alcuni esempi dei tipi di informazioni che si intendono acquisire per ciascuna di queste qualità:

Utilizzabilità

Quando si descrivono i requisiti di utilizzabilità, si possono specificare:

  • Tempo di addestramento richiesto per utenti normali e utenti molto esperti per diventare produttivi durante particolari operazioni.
  • Tempi di attività misurabili per attività tipiche
  • Requisiti conformi ai comuni standard di utilizzo, ad esempio gli standard CUA IBM o gli standard GUI Microsoft

Affidabilità

Quando vengono descritti i requisiti di affidabilità, è possibile specificare:

  • Disponibilità – specificare la percentuale di tempo disponibile ( xx.xx%), le ore di utilizzo, l'accesso alla manutenzione, le operazioni carenti della modalità e così via.
  • MTBF (Mean Time Between Failures) – questa funzione viene di solito specificata in ore, ma può essere anche specificata in termini di giorni, mesi o anni.
  • MTTR (Mean Time To Repair) – quanto tempo è consentito al sistema di restare inattivo dopo un'interruzione.
  • Esattezza – specificare la precisione (risoluzione) ed accuratezza (mediante qualche standard conosciuto) richieste negli output dei sistemi.
  • Numero massimo di errori o incidenza di difetti – di solito espresso in termini di errori/KLOC (migliaia di righe di codice) oppure errori/punto funzione.
  • Incidenza di errori o difetti – classificato in termini di errori meno gravi, significativi e critici: i requisiti devono definire il significato di un errore "critico"; ad esempio, perdita totale di dati o completa incapacità di utilizzare determinate parti della funzionalità del sistema.

Prestazioni

Quando vengono descritti i requisiti delle prestazioni, è possibile specificare:

  • Tempo di risposta per una transazione (medio, massimo)
  • Velocità di elaborazione (ad esempio, transazioni al secondo)
  • Capacità (ad esempio, il numero di clienti o transazioni che il sistema può accogliere)
  • Modalità di riduzione (qual'è la modalità di funzionamento accettabile quando il sistema ha un calo di prestazioni)
  • Utilizzo della risorsa: memoria, disco, comunicazioni e così via

Quando vengono documentati i requisiti delle prestazioni, accertarsi di includere i specifici tempi di risposta. Quando applicabile, fare riferimento al caso d'uso mediante nome.

Supportabilità

Quando si descrivono i requisiti di supportabilità, si possono specificare:

  • Standard di codifica
  • Convenzioni di denominazione
  • Librerie classi
  • Accesso alla manutenzione
  • Programmi di utilità della manutenzione
Cattura dei vincoli

In questa fase vengono documentati tutti i vincoli progettuali sul sistema in costruzione. In termini generali, un vincolo è una limitazione del livello di indipendenza di cui si dispone nel fornire una soluzione [LEF2000].  I vincoli di progettazione rappresentano delle decisioni strutturali che sono state imposte e a cui è necessario aderire. 

Un elemento Vincoli rappresenta il segno '+' in "FURPS+" e può essere ulteriormente classificato come segue:

  • Vincolo di progettazione: Specifica o vincola le opzioni per strutturare e/o progettare un sistema. Ad esempio, richiedere l'utilizzo di un  database relazionale per la persistenza.
  • Vincolo di implementazione: Specifica o limita la codifica o la costruzione di un sistema. Ad esempio, standard richiesti, processi, strumenti, linguaggi di implementazione, piattaforme hardware, sistemi operativi, componenti di terze parti, librerie classi e limitazioni delle risorse (utilizzo di memoria o di spazio su disco).
  • Vincolo interfaccia: Specifica un elemento esterno con cui un sistema deve interagire oppure i vincoli sui formati o su altri fattori utilizzati in un'interazione di questo tipo.  Ad esempio, realizzando un'interfaccia con un sistema esterno via le code di messaggi.
  • Vincolo fisico: Specifica un vincolo fisico imposto sull'hardware utilizzato per ospitare il sistema — forma, dimensione o peso ad esempio.

A seconda del numero dei vincoli da documentare per il sistema, si possono fornire delle sezioni secondarie per ciascuno dei tipi di vincoli. Inoltre:

  • Se i requisiti includono l'acquisto di componenti di terze parti, accertarsi di documentare una qualsiasi concessione di licenza o limitazione d'uso applicabile e tutti gli standard di compatibilità/interoperabilità o d'interfaccia associati. Si consiglia una diversa sezione per componente acquistato.
  • Se i requisiti includono delle specifiche esigenze di interfaccia, si consiglia di fornire sezioni separate per i diversi tipi di interfacce (ad esempio, utente, hardware, software). Per ogni interfaccia, accertarsi di includere un'adeguata specificità, i protocolli, le porte, gli indirizzi logici e così via, in modo da poter sviluppare e verificare il software rispetto ai requisiti dell'interfaccia. Nello specifico:
    • Descrivere le interfacce utente che devono essere implementate dal software.
    • Per le interfacce hardware, includere la struttura logica, gli indirizzi fisici, il comportamento previsto e così via.
    • Per le interfacce software, includere una descrizione delle interfacce verso altri componenti del sistema software. Si potrebbe trattare di componenti acquistati, componenti riutilizzati da un'altra applicazione o componenti sviluppati per sottosistemi fuori dall'ambito di questo sistema, ma con cui questa applicazione software deve interagire.

Per maggiori informazioni su "FURPS+", così come sulla cattura di vincoli, consultare Concetto: Requisiti.

Cattura di requisiti di conformità

Vengono incluse le conformità standard (compresi gli standard regolatori, gli standard di codifica o le guide allo stile dell'interfaccia utente), così come le dichiarazioni di non responsabilità legali, le garanzie, gli avvisi di copyright, i brevetti, i marchi e/o la conformità dei logo.

I requisiti di conformità potrebbero essere realizzati in relazione ad altri requisiti (funzionali, non funzionali e vincoli).  In questi casi, i dettagli di quei requisiti devono essere documentati nelle sezioni applicabili delle Specifiche supplementari come descritto nelle fasi iniziali.  Tuttavia, è importante riepilogare gli standard ed i criteri con cui un sistema deve essere conforme.  I requisiti di conformità risultanti potrebbero fare riferimento ai requisiti dettagliati applicabili quando necessario.

A seconda del numero di requisiti di conformità da documentare per il sistema, si possono fornire delle sezioni secondarie per i diversi tipi di conformità riguardanti il sistema.

Le seguenti sezioni forniscono alcuni esempi dei tipi di informazioni che si intendono acquisire per diversi tipi di conformità:

Requisiti di licenza

Definire tutti i requisiti di applicazione della licenza o altri requisiti di limitazione dell'uso che devono essere presentati dal software.

Legale, copyright e altri avvisi

Descrivere tutte le problematiche di conformità delle dichiarazioni di non responsabilità legali, delle garanzie, degli avvisi di copyright, dei brevetti, dei marchi e dei logo per il software.

Standard applicabili

Descrivere (mediante riferimento) tutti gli standard applicabili e le sezioni specifiche di tali standard che si applicano al sistema descritto. Ad esempio, ciò può includere standard legali, di qualità e regolatori, standard industriali per l'utilizzabilità, l'interoperabilità, l'internazionalizzazione, la conformità del sistema operativo e così via.

Cattura dei requisiti della documentazione

In questa fase, vengono descritti i requisiti, se disponibili, per la documentazione. I requisiti di documentazione potrebbero includere dei requisiti per la guida in linea, oltre alla documentazione per l'utente finale (ad esempio, le guide all'installazione, le guide per l'utente, il materiale didattico, ecc.).  

Così come per i requisiti di conformità, i requisiti di documentazione conducono ad altri tipi di requisiti.  Nello specifico i requisiti funzionali (il sistema deve fornire l'accesso funzionale di supporto per la guida in linea), così come i requisiti di utilizzabilità (l'accesso on demand alle informazioni sull'utilizzo del sistema supporta l'utilizzabilità complessiva del sistema). 

Quindi, come per i requisiti di conformità, i requisiti dettagliati che supportano i requisiti di documentazione devono essere documentati nelle sezioni applicabili delle Specifiche supplementari come descritto nelle fasi iniziali, ma è anche importante documentare e riepilogare i requisiti di documentazione globali per il sistema. I requisiti risultanti potrebbero fare riferimento ai requisiti dettagliati applicabili.

A seconda del numero di requisiti di documentazione da documentare per il sistema, si possono fornire delle sezioni secondarie per i diversi tipi di documentazione da fornire per il sistema.

Considerazioni chiave

I requisiti che si applicano ai casi d'uso (possibilmente requisiti di sistema) tendono a guidare lo sviluppo dell'architettura del sistema. Di fatto, su alcuni progetti, tali requisiti possono essere significativamente più importanti delle relative controparti più specifiche del dominio (o specifiche del caso d'uso). Ad esempio, se si stanno sviluppando dei sistemi di assistenza medica, allora i requisiti di affidabilità saranno fondamentali.

Sfortunatamente, requisiti di questo tipo sono spesso difficili da raccogliere e quindi sono frequentemente non rilevati. Questa attività descrive l'approccio globale per la raccolta di tali requisiti.  Per maggiori informazioni su un approccio "sistematico" per la raccolta dei requisiti utilizzando questionari specifici, consultare [EEL2004].

Ulteriori informazioni