Che cos’è una specifica dei requisiti di sistema (SRS)?

Una specifica dei requisiti di sistema (SRS) (nota anche come specifica dei requisiti software) è un documento o un insieme di documentazione che descrive le caratteristiche e il comportamento di un sistema o di un’applicazione software. Include una varietà di elementi (vedi sotto) che tenta di definire la funzionalità prevista richiesta dal cliente per soddisfare i loro diversi utenti.

oltre a specificare in che modo il sistema dovrebbe comportarsi, la specifica definisce anche ad alto livello, i principali processi aziendali, che saranno supportati, quali ipotesi sono state fatte e quali i parametri chiave delle prestazioni dovranno essere soddisfatti dal sistema.

Elementi principali

A seconda della metodologia utilizzata (agile vs waterfall) il livello di formalità e dettaglio nell’SRS varierà, ma in generale un SRS dovrebbe includere una descrizione dei requisiti funzionali, dei requisiti di sistema, dei requisiti tecnici, dei vincoli, delle ipotesi e dei criteri di accettazione. Ognuno di questi è descritto in modo più dettagliato di seguito:

  • Driver di Business
  • Modello di Business
  • Funzionali e Requisiti di Sistema
  • Business Sistema e Casi d’Uso
  • Requisiti Tecnici
  • Sistema di Qualità
  • Vincoli e Assunzioni
  • i Criteri di Accettazione

fattori

in Questa sezione descrive le ragioni per cui il cliente sta cercando di costruire il sistema. La logica del nuovo sistema è importante in quanto guiderà le decisioni prese dagli analisti aziendali, dagli architetti di sistema e dagli sviluppatori. Un altro motivo convincente per documentare la logica aziendale dietro il sistema è che il cliente può cambiare personale durante il progetto. La documentazione che identifica chiaramente le ragioni di business per il sistema contribuirà a sostenere il supporto per un progetto se lo sponsor originale si muove su.

I driver possono includere sia problemi (motivi per cui i sistemi / processi attuali non sono sufficienti) che opportunità (nuovi modelli di business che il sistema renderà disponibili). Di solito è necessaria una combinazione di problemi e opportunità per fornire motivazione per un nuovo sistema.

Modello di business

Questa sezione descrive il modello di business sottostante del cliente che il sistema dovrà supportare. Ciò include elementi come il contesto organizzativo, i diagrammi di stato attuale e futuro, il contesto aziendale, le funzioni aziendali chiave e i diagrammi del flusso di processo. Questa sezione viene solitamente creata durante la fase di analisi funzionale.

Requisiti funzionali e di sistema

Questa sezione di solito consiste in un’organizzazione gerarchica dei requisiti, con i requisiti aziendali / funzionali al più alto livello e i requisiti di sistema dettagliati elencati come elementi secondari.

Generalmente, i requisiti sono scritti come istruzioni come “Il sistema ha bisogno della capacità di fare x” con dettagli e informazioni di supporto inclusi se necessario.

Casi d’uso aziendali e di sistema

Questa sezione di solito consiste in un diagramma del caso d’uso UML che illustra le principali entità esterne che interagiranno con il sistema insieme ai diversi casi d’uso (obiettivi) che dovranno eseguire. Per ogni caso d’uso ci sarà una definizione formale dei passaggi che devono essere eseguiti per raggiungere l’obiettivo aziendale, insieme alle eventuali pre-condizioni e post-condizioni necessarie.

I casi d’uso aziendali sono in genere derivati dai requisiti funzionali e i casi d’uso del sistema sono in genere derivati dai requisiti di sistema.

I passaggi dei casi d’uso possono anche essere rappresentati come un diagramma di flusso:

Requisiti tecnici

Questa sezione viene utilizzata per elencare tutti i requisiti “non funzionali” che essenzialmente incarnano l’ambiente tecnico in cui il prodotto deve operare e includono i vincoli tecnici in cui deve operare. Questi requisiti tecnici sono fondamentali per determinare in che modo i requisiti funzionali di livello superiore verranno scomposti nei requisiti di sistema più specifici.

Qualità del sistema

Questa sezione viene utilizzata per descrivere i requisiti “non funzionali” che definiscono la “qualità” del sistema. Questi elementi sono spesso conosciuti come”- ilities “perché la maggior parte di loro finiscono in”ility”. Includevano elementi quali: affidabilità, disponibilità, facilità di manutenzione, sicurezza, scalabilità, manutenibilità.

A differenza dei requisiti funzionali (che di solito sono narrativi in forma), le qualità del sistema di solito consistono in tabelle di metriche specifiche che il sistema deve soddisfare per essere accettato.

Vincoli e ipotesi

Questa sezione illustrerà tutti i vincoli di progettazione che sono stati imposti al design del sistema dal cliente, eliminando così alcune opzioni dall’essere considerate dagli sviluppatori. Inoltre, questa sezione conterrà tutte le ipotesi che sono state fatte dal team di ingegneria dei requisiti durante la raccolta e l’analisi dei requisiti. Se una qualsiasi delle ipotesi risulta falsa, la specifica dei requisiti di sistema dovrebbe essere rivalutata per assicurarsi che i requisiti documentati siano ancora validi.

Criteri di accettazione

Questa sezione descrive i criteri con cui il cliente “firmerà” il sistema finale. A seconda della metodologia, ciò può accadere al termine della fase di test e garanzia della qualità, o in una metodologia agile, al termine di ogni iterazione.

I criteri di solito si riferiscono alla necessità di completare tutti i test di accettazione dell’utente e la rettifica di tutti i difetti/bug che soddisfano una soglia di priorità o gravità predeterminata.

Alternative

Nelle metodologie agili come extreme programming o scrum formale, la documentazione statica come una specifica dei requisiti software (SRS) viene solitamente evitata a favore di una documentazione più leggera dei requisiti, ovvero mediante storie utente e test di accettazione.

Questo approccio richiede che il cliente sia facilmente accessibile per fornire chiarimenti sui requisiti durante lo sviluppo e presuppone anche che i membri del team responsabili della scrittura delle storie utente con il cliente saranno gli sviluppatori che costruiscono il sistema. Un approccio più formale potrebbe essere necessario se il cliente è inaccessibile e / o un team separato di analisti aziendali svilupperà i requisiti.

Nelle metodologie Rapid Application Development (RAD) come DSDM o Unified Process (RUP, AUP) la specifica dei requisiti è spesso mantenuta ad un livello superiore con gran parte dei requisiti dettagliati incorporati nei prototipi e nei mockup del sistema pianificato. Questi prototipi sono un modo più visivo per rappresentare i requisiti e aiutare il cliente a comprendere più facilmente ciò che è pianificato (e quindi fornire un feedback più tempestivo).

Lascia un commento

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