Documentazione delle specifiche dei requisiti software da parte dei professionisti

Per alcune organizzazioni, lo SRS è un documento molto importante. Altre organizzazioni non si preoccupano. Quindi il significato del documento dipenderà dall'organizzazione e dal loro processo di sviluppo.

Le organizzazioni più grandi, "meno agili" tendono a fare affidamento su di esse più, ma non intendo iniziare una guerra di fiamma per il loro utilizzo rispetto a varie metodologie di sviluppo. Entrambi gli approcci di processo a cascata e unificato hanno un posto per il documento SRS.

L'SRS può essere molto utile per assicurare che i clienti aziendali esprimano chiaramente le loro esigenze dell'applicazione agli architetti e agli sviluppatori. Può anche essere utile per identificare i requisiti in conflitto e fornire le basi per risolvere tali conflitti. Quanto prima i conflitti vengono scoperti e risolti, tanto meno è probabile che siano richieste costose modifiche alla progettazione e alla codifica.

In generale, i rappresentanti del business, degli analisti aziendali, degli architetti e dei programmatori principali contribuiranno allo SRS in varie fasi. Qualsiasi istanziazione particolare dipenderà da quell'organizzazione e da quel progetto. In definitiva, devono essere coinvolte almeno due persone: una per esprimere ciò che è richiesto e l'altra per acquisire tali requisiti in un modo che abbia un significato per gli sviluppatori.

Techniques used to prepare an SRS è un argomento enorme e ci sono un numero di risorse disponibili per descrivere il processo. Prendi in considerazione il libro di ingegneria del software della conoscenza come corso introduttivo sullo sviluppo di SRS.

_{Normalmente, fornirei un collegamento a SWEBOK ma è in fase di revisione per la prossima versione e IEEE ha spostato l'URL di hosting in giro. Al momento, è più semplice cercare su google.}

Si tratta di una prefettura dettagliata dettagliata del comportamento del sistema da sviluppare. Documento SRS è un accordo tra lo sviluppatore e il cliente che copre i requisiti funzionali e non funzionali del software da sviluppare.