"Tutte le transazioni devono essere crittografate."
Questo è un requisito non funzionale. Lei afferma che non è misurabile. Perché non dovrebbe essere? Posso fare un test che passerà se una determinata azione richiede HTTPS e fallisce se funziona attraverso HTTP.
Non significa che sia un requisito utile. Avere solo HTTPS non significa che le transazioni siano sicure. Potresti avere un certificato non valido. O una versione obsoleta di SSL che si è dimostrata non sicura. Tuttavia, affermare che "tutte le transazioni devono essere crittografate" è un buon inizio e da lì, puoi espandere una serie di requisiti più tecnici ma ancora verificabili, come ad esempio che il sito web dovrebbe avere una valutazione di A + su Mozilla Observatory , dato che un test sarà ovvio da fare, grazie all'open source .
Se gestisci informazioni finanziarie, assicurati che i requisiti siano redatti da un esperto di sicurezza in collaborazione con un avvocato e poi esaminati da altri esperti di sicurezza. I requisiti effettivi saranno probabilmente dettagliati e molto specifici, che richiedono una versione precisa di SSL e un'autentica autorità di certificazione, con dettagli controlli e registri e in che modo tali registri sono archiviati, ecc. "Tutte le transazioni devono essere crittografate" è troppo generico: dovrei utilizzare semplicemente HTTPS tra il cliente e il mio proxy inverso? O dovrei mantenere l'intera catena crittografata, fino al database?
"Il sistema dovrebbe facilitare l'aggiunta di nuove funzioni."
Questo non è un requisito. Non annotarlo, poiché non è possibile eseguire un test che dimostrerà inequivocabilmente che il requisito è soddisfatto. In generale, termini come "facile", "veloce", "bello", "comodo", "conveniente", "piacevole", sono un buon segno che questo non è un requisito. Un requisito deve essere perfettamente obiettivo; indipendentemente dalla persona che verifica la conformità del sistema al requisito, il risultato dovrebbe essere sempre lo stesso.
Ciò che potrebbe essere misurato, tuttavia, è l'indice di manutenibilità, ed è qui che i requisiti non funzionali potrebbero essere utili. Ad esempio, dicendo che:
Requirement 12.34: maintainability index
Every method should have a maintainability index of 60%.
Every class should have a maintainability index of 75%.
In average, the system should have a maintainability index of 95%.
The maintainability index of Java and JavaScript code is measured using SonarQube definitions specified in appendix C, part 2. Bash scripts are excluded from the maintainability index. If the project needs to use an additional language, this document should be revised.
The measurement is limited to the code which is written specifically for the project. All third-party libraries, would they be imported through package managers such as npm, or committed directly to the version control, are excluded.
stai fornendo criteri misurabili che porteranno a un test pass-fail.
"Il sistema dovrebbe presentare messaggi di errore comprensibili."
Questo non è un requisito neanche. Ancor peggio, impone l'implementazione e limita il lavoro dei designer dell'interazione. È come dire che il codice dovrebbe contenere metodi di dieci LOC o meno: non ha senso limitare gli sviluppatori senza motivo.
Una cosa è dire che "I pulsanti dovrebbero essere belli". Si scrive un requisito inutile, ma almeno non fa troppi danni al di fuori del documento dei requisiti. È una storia diversa quando si finisce con requisiti come "I pulsanti dovrebbero avere angoli arrotondati e avere una bella ombra." Non solo il requisito è ancora inutile, ma ora costringe il progettista a prendere decisioni che si tradurranno in un interfaccia scadente, invece di fare il suo lavoro.
Senza i "comprensibili messaggi di errore" constraint , un interaction designer può portare le sue abilità per fare un prodotto che dovrebbe essere comprensibile, ad esempio eliminando l'errore messaggi in primo luogo. Quando tali messaggi sono rilevanti, il progettista dell'interazione assicurerebbe che riflettono effettivamente l'approccio dell'utente per essere comprensibile (dato che le differenze culturali possono renderli molto meno comprensibili se tradotti in altre lingue).
Vedi anche
Requisiti funzionali o non funzionali?