#Etichetta del prodotto
Un software Requirements specification (documento SRS) descrive come un sistema software deve essere sviluppato. In poche parole, un SRS fornisce a tutti i soggetti coinvolti una tabella di marcia per quel progetto.
Offre definizioni di alta qualità per le specifiche funzionali e non funzionali del software e può anche includere casi d’uso che illustrano come un utente interagirebbe con il sistema al completamento.,
Nota: Cerchiamo di aiutare a scrivere una specifica Requisiti software. Richiedi una chiamata con il nostro CTO compilando questo modulo.
Sommario
Perché un documento SRS è importante?
Supponiamo che tu voglia creare un’app di chat con un aspetto e una funzionalità specifici e desideri che sia orientata specificamente alle imprese. Ritieni di poter ritagliare le funzionalità extra che le app di chat commerciali utilizzano per attirare il pubblico e concentrarsi sulle funzionalità di cui le aziende hanno bisogno. Ma tu non sei uno sviluppatore.,
Quindi è necessario esternalizzare lo sviluppo dell’app. Ma devi anche assicurarti che chiunque assuma per trasformare la tua idea in realtà sappia esattamente cosa stai cercando di realizzare. Senza tutti i dettagli per completare l’applicazione, tempo e costi possono rapidamente sfuggire di mano. Gli sviluppatori possono prendere una svolta sbagliata e devono rifattorizzare il codice se il prodotto finito non corrisponde all’immagine che avevi in testa.
Un documento SRS ti costringe a mettere l’idea su carta per coprire tutti questi dettagli. È necessario tradurre questa idea in un linguaggio che gli sviluppatori capiscono., Un documento SRS descrive ciò che un cliente vuole e ciò che gli sviluppatori forniranno. E ‘ l’accordo scritto su ogni dettaglio della app.
Avere un chiaro set di requisiti garantisce che un team di sviluppo crei software che soddisfi le esigenze dei clienti. Un SRS aiuterà a stimare il costo del lavoro e a coprire l’ambito del progetto. Dà anche ai programmatori un’idea dello stack tecnologico di cui avranno bisogno e li aiuta a pianificare il loro lavoro, ma non è tutto:
- I progettisti ottengono approfondimenti di progetto attraverso i documenti SRS in modo che possano abbinare il design al caso d’uso.,
- Tester ottenere le linee guida per la creazione di casi di test che corrispondono alle esigenze del business.
- Gli utenti finali utilizzano SRS per comprendere il software.
- Fornisce agli investitori una panoramica delle funzionalità del sistema in modo che possano prendere decisioni di investimento.
Un SRS è importante perché è un’unica fonte di informazioni e aspettative, che evita incomprensioni tra project manager, sviluppatori, designer e tester.
Cosa include un SRS?,
Un SRS dovrebbe avere informazioni sufficienti per gli sviluppatori per completare il software descritto. Non solo delinea la descrizione del software in fase di sviluppo, ma anche lo scopo che servirà: ciò che il software dovrebbe fare e come dovrebbe eseguire.,del software o che cosa è supposto per fare
La Differenza Tra funzionali e Non Funzionali Requisiti
i requisiti Funzionali sono gli obiettivi del nuovo sistema che si sta progettando., Descrivono il sistema e come funzionerà per aiutare con le attività di un utente. Definiscono come il sistema risponderà all’input dell’utente e hanno dettagli su calcoli, input di dati e processi aziendali. È possibile considerare i requisiti funzionali una descrizione dettagliata delle funzionalità dell’applicazione e delle esigenze dell’utente. Senza soddisfare i requisiti funzionali, il sistema non funzionerà.
Mentre i requisiti funzionali specificano cosa fa un sistema, i requisiti non funzionali descrivono come lo farà il sistema. I requisiti non funzionali non influiscono sulla funzionalità dell’applicazione., Anche senza soddisfare requisiti non funzionali, il sistema eseguirà le attività desiderate.
I requisiti non funzionali sono importanti anche perché definiscono le caratteristiche generali che influenzano l’esperienza dell’utente. Invece di concentrarsi sui requisiti degli utenti, si concentrano sulle aspettative degli utenti e coprono argomenti come prestazioni, sicurezza, affidabilità, disponibilità e usabilità.,
Come scrivere un documento di specifica dei requisiti software
È meglio organizzare il processo utilizzato per scrivere un documento SRS iniziando con uno scheletro e informazioni generali sul software che stai sviluppando e finendo aggiungendo dettagli per rimpolpare la bozza. Qui ci sono sei passi coinvolti nella creazione di un documento SRS:
Get Software Requirements Specification Document
Abbiamo aiutato 200+ aziende a costruire i loro prodotti software. Assumi il nostro analista aziendale con 6 anni di esperienza per scrivere un SRS per te.,
Richiedi SRS
Crea una struttura
Il primo passo del processo consiste nel creare una struttura per il tuo SRS. È possibile creare da soli o utilizzare un modello SRS esistente come punto di partenza. Ecco un esempio di base di uno schema SRS:
Scarica l’ebook
- Introduzione
- Funzione
- destinatari
- destinazione d’Uso
- Ambito
- Definizioni
- Descrizione Generale
- Esigenze dell’Utente
- Assunzioni e Dipendenze
- Caratteristiche del sistema e dei Requisiti
- Requisiti Funzionali
- Interfaccia Esterna Requisiti
- Funzionalità del Sistema
- Requisiti Non funzionali
Definire lo Scopo
una Volta che si dispone di un profilo, è necessario che la carne fuori., Inizia con la definizione dello scopo del prodotto nell’introduzione del tuo SRS. Qui descriverai il pubblico previsto e come utilizzeranno il prodotto. Ecco come si dovrebbe strutturare lo scopo:
- Definire lo scopo del prodotto
- Descrivere il valore che fornirà
- Mostrare chi utilizzerà il software
- Dettagliare come aiuterà con il lavoro degli utenti previsti
Dare una panoramica
Dopo aver definito lo scopo del prodotto, riassumere come funzionerà., Qui si darà una descrizione generale delle caratteristiche del software e come si adattano alle esigenze dell’utente.
Descriverai anche le ipotesi che stai facendo sulla funzionalità del prodotto e su tutto ciò che dipende dall’attuale ecosistema tecnologico.
Descrivi i requisiti funzionali e non funzionali
Ora che hai scritto le informazioni generali, è il momento di ottenere più specifici. Completare la panoramica prima di lavorare su requisiti funzionali e non funzionali fornisce un riferimento per assicurarsi di soddisfare le esigenze di base dell’utente mentre si compila i dettagli.,
Questa descrizione dettagliata dei requisiti del sistema è la componente più essenziale di un documento SRS. Descrivi i requisiti funzionali in modo abbastanza dettagliato in modo che gli sviluppatori possano mettersi al lavoro e i requisiti non funzionali come le specifiche di sicurezza e le prestazioni.
Qui è dove aggiungi casi d’uso per descrivere vividamente come un utente interagirà con il tuo sistema. È dove gli obiettivi del tuo progetto sono dettagliati e misureranno come il progetto sta progredendo durante lo sviluppo.,
Aggiungi dettagli supplementari
L’ultimo passaggio nella creazione della bozza del documento SRS consiste nell’aggiungere tutti i dettagli che potrebbero aiutare gli sviluppatori a completare il lavoro sotto forma di appendici, glossari di termini e riferimenti.
Ottieni approvazione
Una volta aggiunti abbastanza dettagli all’SRS per descrivere ciò che il sistema dovrebbe fare, è ora che le parti interessate approvino il documento.
Molto probabilmente dovrai fare una presentazione alle persone coinvolte nel processo di sviluppo., Potrebbero richiedere modifiche e dovrai aggiornare il documento SRS in base al feedback degli stakeholder prima dell’approvazione finale.
Questo è un buon segno. Significa che sia gli sviluppatori che le parti interessate stanno rendendo il documento più preciso, quindi il progetto è meno come andare fuori pista.
Come scrivere casi d’uso software in un SRS
Un caso d’uso descrive come un utente interagirà con il sistema. Descriverà il prodotto dal punto di vista dell’utente finale in un semplice formato di storia. Scrivere casi d’uso ti costringe a pensare a cosa faranno gli utenti con il software e come risponderà., È la visualizzazione reale dei requisiti funzionali.
Ecco i passaggi che puoi seguire per scrivere un caso d’uso:
- Descrivi gli utenti finali del tuo prodotto.
- Concentrarsi su uno di questi utenti.
- Suddividi le interazioni di questo utente in casi d’uso. Ogni interazione è un caso d’uso.
- Descrivere la sequenza di eventi per ogni caso d’uso.
- Scrivi una descrizione dettagliata delle azioni dell’utente e di come il sistema dovrebbe rispondere.
- Espandi ogni caso d’uso con azioni utente e risposte di sistema alternative.
- Ripetere 1-6 per ogni tipo di utente finale.,
Quali sono le caratteristiche di un grande SRS?
Ci sono caratteristiche specifiche che ogni SRS dovrebbe avere. Rivedendo questo elenco e confrontandolo con il tuo SRS, puoi assicurarti che sarà un documento utile per tutte le parti interessate.
Esplicito
Un documento SRS dovrebbe essere facile da capire. Nulla dovrebbe essere vago, quindi non ci sono incomprensioni tra le parti interessate.,
Misurabile
I requisiti nel documento SRS devono essere misurabili, in modo che il prodotto finito possa essere convalidato e verificato rispetto alle specifiche.
Completo
Un documento SRS dovrebbe avere informazioni sufficienti per il team di sviluppo per completare il prodotto e per i tester per convalidare che il prodotto soddisfi le esigenze dell’utente senza bug.
Vitale
I requisiti dovrebbero adattarsi alla realtà dell’ambiente attuale, inclusi budget, timeline e tecnologia. Non dovrebbero dipendere dalle prossime scoperte tecnologiche.,
Flessibile
Poiché le cose potrebbero cambiare nell’ambiente di lavoro, il documento SRS dovrebbe essere abbastanza flessibile da consentire gli aggiornamenti. Non aggiungere informazioni ridondanti a più sezioni che devono essere aggiornate ad ogni modifica.
Verificabile
Tutti i membri del team di sviluppo dovrebbero avere accesso al documento in modo da poterlo fare riferimento con la frequenza necessaria. I requisiti devono essere precisi in modo che i membri del team non debbano chiedere maggiori dettagli. Dovrebbero essere tutti disponibili nel documento SRS.,
Coerente
I requisiti devono adattarsi a vicenda. Una sezione del documento dei requisiti non dovrebbe entrare in conflitto con un’altra. Il documento deve essere formattato in modo coerente e utilizzato la stessa terminologia in tutto.
Nessun vincolo di implementazione
Un documento SRS dovrebbe essere abbastanza dettagliato per completare il lavoro, ma non dovrebbe essere eccessivamente specifico, perché ciò potrebbe limitare lo sviluppo. Un sacco di sviluppo dipende da servizi di terze parti su cui gli sviluppatori non hanno alcun controllo.,
Accurate
Gli obiettivi in un documento dei requisiti devono essere precisi per evitare confusione. Evitare quanto segue:
- Scappatoie: “L’applicazione dovrebbe caricare in 3 secondi se può essere fatto.”
- Ambiguità: “Il prodotto MVP dovrebbe essere rilasciato il più rapidamente possibile.”
- Soggettività: “L’interfaccia utente dovrebbe essere facile da usare.”
- Superlatives: “Questa dovrebbe essere la migliore applicazione della sua classe.”
- Comparativo: “Questa applicazione dovrebbe essere migliore di Slack.,”
Un esempio di Software Requirement Specification (SRS)
Ecco un esempio ridotto di un documento SRS per un’app di chat aziendale chiamata eChat:
Introduzione
Questo documento descrive in dettaglio il piano di progetto per lo sviluppo di ” eChat.”
È destinato a sviluppatori, designer e tester che lavorano su “eChat” e investitori di progetti., Questo piano prevede una sintesi di:
- come il funzionamento del sistema
- ambito del progetto dal punto di vista di sviluppo
- la tecnologia utilizzata per sviluppare il progetto, e
- i parametri utilizzati per determinare l’avanzamento del progetto
- Descrizione Generale
le Aziende hanno bisogno remoto strumenti di comunicazione, soprattutto ora che sempre più persone stanno lavorando da casa. Il problema è che la maggior parte delle aziende finiscono per utilizzare più applicazioni per realizzare questo: uno per la chat di testo, uno per la chat video, e uno per conferenze e riunioni., “eChat” risolverà questo problema combinando queste funzionalità in un’unica applicazione.
Scarica il whitepaper
Clienti
I clienti saranno enterprise aziende. Non si rivolgerà al pubblico in generale.
Funzionalità
- Gli utenti dovrebbero essere in grado di registrarsi con gli account LDAP aziendali.,
- Gli utenti dovrebbero essere in grado di creare gruppi di chat ad hoc composti da gruppi di utenti e inviare messaggi privati a singoli utenti.
- Gli utenti dovrebbero essere in grado di avere chat di testo che possono rompere in thread.
- L’applicazione dovrebbe essere in grado di gestire chat video di gruppo fino a 100 utenti alla volta.
Piattaforma
L’applicazione sarà sviluppata in React Native per consentire la creazione di un’applicazione basata sul web, un’app mobile iOS e un’app mobile Android.
Queste applicazioni si connetteranno a un’API REST costruita con .,NET Core per memorizzare e recuperare i dati da un database MySQL.
L’autenticazione avverrà tramite installazioni LDAP esistenti.
Responsabilità di sviluppo
Gli sviluppatori del team “eChat” saranno responsabili della scrittura di tutto il codice per l’applicazione, dello sviluppo del database e della gestione delle versioni.,
Classe Utente e Caratteristiche
non Ci sarà una classe di utenti denominato admin che si dispone delle autorizzazioni per accedere a tutte le funzionalità di app, tra cui:
- Creazione di canali in cui più utenti possono interagire
- Fare questi canali pubblici per l’intera azienda o per un gruppo di persone
- l’Eliminazione di questi canali
- l’Archiviazione di questi canali
Standard, gli utenti avranno accesso a tutte le funzionalità dell’app ad eccezione di quelli elencati sopra.,
Caratteristiche del sistema
Requisiti funzionali
- Gli utenti dovrebbero essere in grado di creare gruppi di chat ad hoc che comprendono gruppi di utenti e inviare messaggi privati ad altri utenti.
- Gli utenti dovrebbero essere in grado di avere chat di testo che possono rompere in thread.
- Le chat dovrebbero poter essere archiviate indefinitamente in modo che gli utenti possano fare riferimento alle chat passate.
- Gli utenti dovrebbero essere in grado di caricare i file in chat per riferimento.
- Requisiti di interfaccia esterna
Interfacce utente
- Software front-end: React Native
- Software back-end: .,s sistemi operativi attraverso il loro browser web predefinito
- iPhone
- Android
- Requisiti Non Funzionali
Requisiti e Prestazioni
- L’applicazione deve caricare e essere utilizzabile entro 3 secondi
- L’applicazione deve aggiornare l’interfaccia di interazione all’interno di 2 secondi
- Il database deve essere normalizzato per evitare la ridondanza dei dati e migliorare le prestazioni
- Il database dovrebbe essere distribuito per evitare interruzioni
Requisiti di Sicurezza
- i Database devono utilizzare sharding essere ridondanti per evitare la perdita di dati.,
- I backup dei database devono essere eseguiti ogni ora e conservati per una settimana.
Requisiti di sicurezza
- Qualsiasi chiave utilizzata per l’API REST deve essere memorizzata in modo sicuro.
- Solo l’API REST dovrebbe essere in grado di connettersi ai database.
- I database dovrebbero essere dietro un firewall.
Attributi di qualità del software
- Disponibilità: Poiché questa applicazione è fondamentale per la comunicazione aziendale, avremo un obiettivo di quattro nove(99,99%) disponibilità.,
- Correttezza: L’applicazione non dovrebbe mai permettere a nessuno di leggere messaggi o discussioni non destinati a quella persona.
- Manutenibilità: L’applicazione dovrebbe utilizzare l’integrazione continua in modo che le funzionalità e le correzioni di bug possano essere distribuite rapidamente senza tempi di inattività.
- Usabilità: L’interfaccia dovrebbe essere facile da imparare senza un tutorial e consentire agli utenti di raggiungere i loro obiettivi senza errori.
Sommario
Un documento SRS è una parte necessaria per completare un progetto di sviluppo software., È la roadmap che dà indicazioni a tutti coloro che sono coinvolti nel progetto, in modo che il prodotto finale soddisfi le esigenze dell’utente.
Senza un documento SRS completo in atto prima di iniziare un progetto, sarà difficile dire quando un progetto è finito e potrebbe sviare lo sviluppo nella creazione di funzionalità indesiderate. Un documento SRS ti dà la possibilità di stimare un progetto con precisione e assegnare compiti in modo efficiente.
La creazione di un documento SRS può essere un processo meticoloso e dispendioso in termini di tempo., Fortunatamente, il team di Relevant ha aiutato oltre 200 aziende a creare documenti SRS e lanciare nuovi prodotti. Siamo pronti ad aiutare con il vostro prossimo progetto software, basta mandarci una riga.