Operazione: Requisiti non funzionali del servizio del documento
Questa attività definisce e specifica il servizio e la struttura di una soluzione orientata al servizio in termini di collaborazioni degli elementi di progettazione contenuti e di sottosistemi/interfacce esterni.
Scopo
  • Definire i servizi e la struttura di una soluzione orientata al servizio in termini di collaborazioni di elementi di progettazione contenuti e sottosistemi/interfacce esterni.
  • Per analizzare il servizio per l'associazione e la variabilità (consultare Linea guida: Analisi delle variabilità).
  • Documentare la specifica dei servizi.
  • Determinare le dipendenze e la comunicazione tra i servizi.
Relazioni
Descrizione principale
Questa attività raffina l'insieme di Artefatto: Specifica del servizio identificate e qualificate durante l'Attività: Analisi asset esistente e fornisce un'altra struttura ed il dettaglio. Questo dettaglio a livello del progetto include l'interfaccia, il messaggio e la composizione dei servizi e l'assegnazione dei servizi ai provider.
Passi
Requisiti non funzionali del documento

L'utilizzo di una SOA (Service-Oriented Architecture) fornisce l'opportunità di scegliere  Artefatto: Provider del servizio non solo in base alla funzionalità che fornisce, ma anche sulle QoS (Qualities of Service) che può  garantire. Uno dei motivi per cambiare un provider del servizio potrebbe essere spesso il risultato di una modifica nei requisiti non funzionali che necessitano di un nuovo livello di QoS non al momento supportato da un provider esistente. Potrebbe inoltre risultare dalla degradazione nella QoS prevista dal consumatore del servizio. Una SOA (Service-Oriented Architecture) consente questa agilità ad un costo più basso, in generale, rispetto agli stili strutturali.

QoS può essere visualizzato da due prospettive: quella del Provider e quella del Consumatore. Il Provider del servizio garantisce di fornire e mantenere una qualità di servizi per ogni servizio o gruppo dei servizi. Il consumatore del servizio, d'altro lato, acquista la QoS desiderata e scegli un provider in base alla QoS. È inoltre importante notare che nelle impostazioni commerciali dove il consumatore ed il provider entrano in un contratto legale sull'utilizzo del servizio, queste garanzie della qualità del servizio sono raffinate negli Accordi del livello di servizio, frequentemente con multe associate a mancanze da parte del provider nel rispettare tale accordi.

Quindi, è molto importante specificare chiaramente i requisiti non funzionali richiesti dal consumatore (ad esempio, il costo della transazione, la prestazione, la disponibilità, la sicurezza, ecc...) per un servizio o un insieme di servizi. In questa attività della specifica del servizio, vengono identificati i requisiti non funzionali per la QoS desiderata. I requisiti non funzionali verranno utilizzati per eseguire il commit delle risorse per i componenti del servizio che offrono i servizi e per fondare la realizzazione e la manutenzione dei componenti del servizio che assicurano la distribuzione della QoS nel tempo. Le decisioni strutturali chiave devono essere eseguite per assicurare che sia raggiunta la qualità promessa del servizio basato sui requisiti non funzionali.

Il modo in cui sono collegati i requisiti non funzionali alla Artefatto: Specifica del servizio non è definito in questa guida. Non ci sono limiti impostati su cosa costituisce tale requisiti, ovviamente QoS, la protezione è stata già menzionata, e gli esempi potrebbero includere:

  • La disponibilità (ad esempio il tempo che passa tra un errore e l'altro)
  • Finestra operativa (esiste un momento in cui non si prevede che il servizio venga utilizzato?)
  • Tempo di risposta (quanto velocemente il servizio deve rispondere ad una richiesta)
  • Velocità di immissione picco (quante richieste per il servizio possono arrivare per unità di tempo come per secondo, minuto, per ora)
Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni