Ingegneria dei Requisiti: Analisi funzionale e specifica dei requisiti del software

Ingegneria dei Requisiti: Analisi funzionale e specifica dei requisiti del software

L’attività di analisi e specifica dei requisiti termina con la redazione di un documento, il Software Requirements Specification, il quale dovrebbe mostrare caratteristiche di completezza e coerenza. Nel dettaglio, la fase di analisi e specifica dei requisiti si ritiene conclusa dopo che:

  1. sia stato studiato il contesto e raccolte le esigenze del cliente,
  2. siano analizzate le richieste per capirne la realizzabilità,
  3. siano state negoziate le priorità di sviluppo.

Richiedere queste caratteristiche per un sistema software relativo ad un sistema di grandi dimensioni e complesso è un’impresa impegnativa, se non impossibile per due ragioni: la prima riguarda la facilità nel commettere errori ed omissioni nello scrivere le specifiche dei requisiti, la seconda riguarda le esigenze, a volte contrastanti, degli stakeholder coinvolti.
Per scovare le incongruenze in un documento di specifica dei requisiti è, quindi, necessaria un’analisi attenta che, purtroppo, a volte viene effettuata solo a valle della consegna del prodotto software al cliente.

Ingegneria dei Requisiti: Analisi funzionale e specifica dei requisiti del software

I requisiti non funzionali specificano o limitano le proprietà complessive del sistema come le prestazioni, la disponibilità, la protezione: spesso sono più critici dei singoli requisiti funzionali tanto da poter rendere il sistema inutilizzabile nel caso in cui non trovino corrispondenza nella specifica. Infatti, essi possono essere vincolati a limiti di budget, alle politiche organizzative, di sicurezza, privacy (dove i principali tipi di requisiti non funzionali sono: i requisiti di prodotto, i requisiti esterni, i requisiti organizzativi), alla necessità di interoperabilità con altri sistemi software o hardware.

Una difficoltà che accompagna tali requisiti riguarda la loro verificabilità: infatti, è abbastanza comune che gli utenti o i clienti si riferiscano ad essi come obiettivi generali che il sistema deve perseguire, dando la libertà agli sviluppatori di interpretarli in maniera arbitraria. Questa potrebbe essere una causa di malcontento da parte del commitente, una volta rilasciato il prodotto.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *