Risposta.

SRS è un documento strutturato che descrive tutti i requisiti del sistema in fase di sviluppo. Il suo compito è tradurre in modo chiaro e completo le aspettative aziendali nel linguaggio del team di progetto. Le sezioni principali:

1. Introduzione (obiettivi, ambito di applicazione, terminologia)
2. Descrizione del prodotto e contesto aziendale
3. Descrizioni degli utenti e dei loro ruoli
4. Requisiti funzionali (use cases, user stories)
5. Requisiti non funzionali (sicurezza, prestazioni, usabilità)
6. Vincoli
7. Interfacce
8. Dipendenze esterne
9. Criteri di accettazione dei requisiti
10. Glossario dei termini

Caratteristiche chiave:

• L'SRS contiene sia requisiti funzionali che non funzionali.
• I requisiti sono formulati in modo univoco, con la minima ambiguità.
• L'SRS deve riflettere gli scenari di utilizzo, i vincoli, i criteri di successo.

Per controllare la completezza e la qualità, l'analista utilizza checklist di validazione, modelli, standard IEEE 830 e regolari approvazioni con i principali stakeholder.

Domande trabocchetto.

È sufficiente descrivere solo le user stories per avere un SRS completo?

No. Le user stories mostrano il lato funzionale, ma non coprono i requisiti non funzionali, i vincoli, le interfacce, gli scenari di eccezione e i criteri di accettazione.

È possibile utilizzare termini diversi per la stessa entità nel documento?

No. È necessario mantenere la coerenza della terminologia: per questo viene creato un glossario dei termini e viene condotta una revisione incrociata del documento.

L'SRS deve includere i requisiti di sicurezza e prestazioni?

Sì. I requisiti non funzionali sono critici: la loro mancanza porta a debito tecnico o impossibilità di utilizzare il sistema.

Errori comuni e anti-pattern

• Dettagli insufficienti sui requisiti, assenza di esempi e criteri di accettazione.
• Uso di formulazioni ambigue: "veloce", "conveniente", "affidabile" senza caratteristiche numeriche.
• Ignorare i requisiti non funzionali.

Esempio dalla vita reale

Caso negativo

L'SRS è stata scritta solo sulla base delle user stories, dimenticati i requisiti di prestazione e sicurezza.

Vantaggi:

• Preparazione rapida della documentazione.

Svantaggi:

• Il progetto non ha superato l'audit di sicurezza, non sopporta il numero necessario di utenti contemporanei.

Caso positivo

L'SRS copre l'elenco completo degli attributi necessari: funzionalità, requisiti non funzionali, criteri di accettazione, glossario.

Vantaggi:

• Prontezza per l'audit, requisiti chiari per tutti i partecipanti, alta gestibilità delle modifiche.

Svantaggi:

• Aumento del lavoro per la preparazione e l'approvazione della documentazione.