L'obiettivo è (1) fornire un sistema che soddisfi il cliente e (2) garantire che le persone che utilizzano i requisiti abbiano tutto ciò di cui hanno bisogno. Fornisci il livello di dettaglio minimo che esegue entrambi e hai risposto alla tua domanda.
Più in particolare, la tua organizzazione ha standard di requisiti ? Presumo non dalla tua domanda, ma i modelli comuni oi documenti dei requisiti precedenti possono implicare il livello di dettaglio richiesto. Chiedi anche alle persone anziane della tua organizzazione.
Chi utilizzerà i requisiti , come sviluppatori, UX e QA? Nel tuo esempio, quanto ne sanno dei dipendenti? Hanno lavorato su sistemi simili per anni e probabilmente lo conoscono meglio del cliente o sono nuovi in questo tipo di sistema? Ad esempio, sapranno quali campi ha un dipendente e le sue regole di convalida? In caso contrario, includi questi. Vedi sotto per altri esempi.
Qual è il livello di dettaglio del requisito di accettazione richiesto dal cliente ? Sono disposti a sperimentare con diversi build / measure / learn cicli (meno dettagli) o hanno dettagliato e severo requisiti di conformità (maggiori dettagli)?
Cattura quando un requisito non è importante (ad esempio, nessun requisito di tempo di attivazione del sistema) perché la mancanza di un requisito può essere altrettanto importante.
I requisiti possono essere specificati in diversi modi . Molti preferiscono storie di utenti o casi d'uso. Una sequenza UML o un diagramma di attività potrebbero essere migliori per i processi complessi. Comunicare bene i requisiti è tanto importante quanto assicurare che siano completi e coerenti.
Non tutti i requisiti sono adatti a tutti i segmenti di pubblico . Ad esempio, i clienti che confermano che il sistema soddisfa i loro requisiti probabilmente vorranno informazioni diverse per gli sviluppatori che eseguono l'implementazione a basso livello. Prendi in considerazione la possibilità di dividere le grandi liste in quelle più piccole per vari tipi di pubblico.
Al di là di questo e forse leggermente fuori tema, la raccolta dei requisiti non si limita a specificare ciò che chiede il cliente e a quale livello di dettaglio. Quali requisiti puoi aggiungere ? Ad esempio (quasi un elenco definitivo):
- I dipendenti verranno aggiunti in blocco? In tal caso, l'interfaccia utente necessita di un'opzione di aggiunta di massa (ad esempio una tabella) anziché di un modulo? Possono invece essere importati da un sistema HR?
- Chi inserirà i dettagli del dipendente? A chi non dovrebbe essere permesso di vedere i dati dei dipendenti? Chi autorizza i nuovi utenti e rimuove quelli vecchi? Se qualcuno apporta una modifica, deve essere controllato? Per quanto tempo devono essere conservati i registri di controllo? Le modifiche devono essere approvate da altri?
- Quanti record di dipendenti ci saranno? Dieci? Dieci mila? Dieci milioni? Come saranno ricercati, ordinati e filtrati? Quante persone accederanno al sistema contemporaneamente?
- Da dove verranno inseriti i dettagli del dipendente? Un browser Web su un computer desktop nell'ufficio dell'organizzazione o un dispositivo mobile utilizzato dal capo cantiere in un cantiere?
- Qual è l'impatto del sistema che va giù? Posso applicare patch ai sistemi durante l'orario lavorativo?
- Ci sono dei motivi per cui non potrei considerare un sistema "off the shelf" invece di scriverlo da soli?
- Il cliente richiede che io segua qualsiasi standard, ad es. Common Criteria , FIPS 140 , ISO 27001 ? Esistono requisiti contrattuali o legali per la conservazione o la privacy?
- Le organizzazioni spesso impongono requisiti impliciti. Ad esempio, i costi e la tempistica del progetto possono essere stimati dai requisiti? Se no, cosa manca? Come si inserisce questo nella strategia tecnologica della mia organizzazione?
- Ci sono dei vincoli sullo sviluppo, come scadenze fisse, limiti di budget o vincoli tecnologici?
Questo aggiunge davvero valore, in particolare quando la raccolta dei requisiti diventa una conversazione bidirezionale con i clienti.