Come chiamare i requisiti "assunto" / "invisibile" / "molto ovvio"

I dettagli dell'infrastruttura sono definiti requisiti "non funzionali". È un termine strano che descrive quei requisiti che non sono visibili all'utente finale, ma sono comunque necessari per il corretto funzionamento dell'applicazione.

Tuttavia,

The application shall provide a mechanism for allowing the user to change his password

e

The user session must time out after 30 minutes

sono non requisiti non funzionali, e sono non ovvi. Prendi sempre questi requisiti e inseriscili nella tua matrice dei requisiti.

Classificherei quelli come requisiti "impliciti". Come "L'utente deve essere in grado di accedere" implica che esiste la nozione di un utente (con una tabella di database associata / archivio di qualche tipo), qualche nozione di password o altre credenziali e il requisito per memorizzare l'ID utente o qualche altro token nella sessione. Ciò implicava anche (per me, in ogni caso) che ci fosse un qualche tipo di processo di manutenzione per l'aggiunta e la rimozione degli utenti, e probabilmente un rapporto di qualche tipo che mostra nome utente, prima data di accesso, ultima data di accesso, account e-mail associato e qualsiasi altra cosa di cui tieni traccia.

Penso che la cosa più vicina a cui possa pensare sia un "requisito derivato". Questi sono requisiti generati dal team di sviluppo, basati su numerose fonti come agenzie di regolamentazione, linee guida aziendali e esperienze passate su progetti simili.

Tuttavia, anche dopo aver ottenuto requisiti aggiuntivi dai requisiti del cliente / utente, è importante convalidarli con il cliente / utente per assicurarsi che siano corretti. Dopo averli convalidati, li segui esattamente come ogni altro requisito. Si noti che solo perché alcune linee guida o esperienze suggeriscono che un requisito non significa che il cliente lo desidera. In effetti, potrebbe essere contrario a ciò che ci si aspetta dal sistema.

Vorrei andare con assumptions (o, unwritten assumptions se dovrebbe essere più preciso).

Implicit , da un'altra risposta, non funziona, perché ciò che è stato richiesto non si basa necessariamente su di essi. Ad esempio, user must be able to change their password non è implicito a meno che un altro requisito faccia riferimento a un utente che modifica la propria password supponendo che funzioni già.

Very obvious , dalla domanda, in realtà non funziona. Potrebbe facilmente essere qualcosa che è evidente solo a qualcuno con una conoscenza di dominio appropriata o che lavora a stretto contatto con il prodotto. Oppure, per usare l'esempio di password, potrebbe essere che gli utenti non dovrebbero essere in grado di cambiare le loro password, e solo gli amministratori possono.

Quello che stai descrivendo sono cose che il client assumed sarebbe fatto.

L'ho trovato da un altro sito e volevo aggiungere i miei due centesimi.

Dal mio punto di vista nel momento in cui un cliente / manager inizia a usare frasi come "è ovvio" o "era ovvio" il contratto tra il proprietario del progetto e gli sviluppatori si rompe.

Quando uno sviluppatore implementa qualcosa correttamente, ma manca qualcosa che è "ovvio" (ma non specificato) sarà colpa dello sviluppatore; quando implementano qualcosa che non è stato specificato, sarà colpa loro se non seguono le specifiche. Questo è il modo in cui lo sviluppo del software funziona in aziende in cui gli sviluppatori sono incolpati di ogni mancanza, di solito con un manager debole che è felice di avere persone a cui scaricare la colpa.

Tutti i requisiti dovrebbero essere documentati, esplicitamente, anche se sembra che l'ovvio venga dichiarato. In questo modo non vi è alcun dubbio su ciò che viene costruito e una chiara pista di controllo per spiegare perché qualcosa non è come il cliente avrebbe sperato.