In un documento dei requisiti funzionali, la sezione Presupposti è pericolosa?

L'aderenza alla guida raccomandata per escludere ipotesi da un documento dei requisiti funzionali dipende da alcune cose.

In primo luogo, quanto è rigorosa la cultura e il progetto?

A volte le pratiche raccomandate sono trattate come pratiche richieste defacto. È "buona pratica" assicurare quanto strongmente tali cose siano semplicemente raccomandate e che siano in pratica richieste. Sforzati di avere qualche idea su quali potrebbero essere le conseguenze se fai o non aderisci alla "guida". Questo è il mio disclaimer.

Secondo, qual è la logica alla base della guida?

Quindi quale potrebbe essere il motivo per cui i requisiti funzionali di guida documentano i redattori e i contributori dall'includere una sezione dedicata alle ipotesi?

Nella mia esperienza, le persone e i progetti visualizzano le esigenze funzionali in modo diverso a volte. In alcuni casi, i requisiti funzionali ( cosa accade e il sequenziamento o quando succede qualcosa) sono chiaramente distinti dai requisiti di sistema o di servizio ( dove o come succede qualcosa). Trovare la distinzione quando il sistema o l'ambiente sono fondamentali per lo sforzo (dispositivo o interfacce di servizio o driver di dispositivo, ad esempio) potrebbe rivelarsi più impegnativo di quanto valga, e quindi in quei casi lo affermerei come prima ipotesi e poi andare avanti.

Nel caso del documento sui requisiti funzionali, la motivazione per non includere una sezione delle ipotesi può essere presunta che, se una sezione per le assunzioni si ritiene necessaria, allora forse i requisiti non sono funzionali. In altre parole, se ritieni che ci siano delle ipotesi rilevanti che dovrebbero essere documentate in relazione ai requisiti inclusi; il requisito potrebbe essere troppo specifico per un'implementazione o un particolare servizio e forse non appartiene a quel particolare documento. D'altra parte, forse i requisiti appartengono ma sono semplicemente riscritti in modo diverso da non essere così specifici che una particolare implementazione e le relative ipotesi non dovrebbero più essere applicate. Probabilmente è inteso che la guida non è un divieto, ma piuttosto un controllo di integrità o una bandiera arancione per i redattori e i contributori del documento.

Se dovessi affrontare un documento dei requisiti funzionali nel senso più stretto, i requisiti di sistema e di servizio non apparirebbero lì. Se questi tipi di requisiti non sono inclusi nelle specifiche funzionali, è molto meno probabile che sia necessario fare o dichiarare qualsiasi tipo di ipotesi globale (spesso pertinente per l'ambiente o l'utente). Se scopri che le ipotesi globali iniziano ad applicare i requisiti inclusi, potrebbe indicare che i requisiti non sono stati scritti come requisiti funzionali o che l'ambiente o l'utente sono fondamentali per lo sforzo.

Se non hai una sezione di ipotesi, avrai solo le ipotesi sconosciute dei programmatori mentre stavano codificando.

Devi costantemente formulare ipotesi deliberate e inconciliabili quando stai costruendo qualcosa - potresti anche averle scritte.

L'assunzione è una parola strong. Sicuramente fai vuoi una sezione di ipotesi. Ma anche fai vuoi che la sezione venga convalidata per la precisione.

Se, ad esempio, stai progettando un'applicazione con l'assunto che tutti i suoi utenti saranno utenti esperti, allora è meglio che sia vero.

Quindi, in pratica, chiamalo come vuoi (presupposti, prerequisiti, qualsiasi cosa), ma deve essere presente in modo che le persone siano consapevoli di ciò che sta guidando le tue scelte progettuali.

Se il mio requisito è un nuovo rapporto e suppongo che i dati richiesti siano già presenti nell'applicazione, non è importante? Devo renderli consapevoli per quando mi citano, nel caso in cui non lo sapessero.

Penso che le assunzioni siano importanti. e non sono necessariamente requisiti