Parola migliore per i requisiti opzionali? [chiuso]

Qual è la parola migliore per un requisito opzionale nell'ingegneria del software? La frase è contraddittoria. Ho usato "Requisiti non fondamentali" in progetti precedenti.

Il termine "requisito fuori dal campo di applicazione" può essere eventualmente utilizzato. Ciò significa che il requisito è stato acquisito all'interno del processo ed è rintracciabile, ma è stato stabilito che il requisito è qualcosa che esula dall'ambito attuale del sistema, a causa di una serie di motivi, quali budget, pianificazione, tempo, o fattibilità.

Tuttavia, la frase "requisito facoltativo" viene comunemente utilizzata per indicare qualcosa che rientra nell'ambito di applicazione, ma non necessariamente richiesto dal sistema. È una misura della priorità del requisito. Nelle mie esperienze, i requisiti sono spesso prioritari come obbligatori, desiderabili o facoltativi (sebbene esistano anche altri schemi). Affinché un progetto sia considerato completo e pienamente funzionale, devono essere soddisfatti tutti i requisiti obbligatori. Date le risorse sufficienti, i requisiti desiderabili sarebbero implementati successivamente. Infine, qualsiasi cosa considerata facoltativa verrebbe inclusa.

Credo che la confusione derivi dal termine "requisito". In lingua inglese, un requisito è "una cosa necessaria" o "una condizione obbligatoria, obbligatoria o necessaria". Tuttavia, nell'ingegneria del software, il termine requisito è semplicemente una caratteristica documentata di un sistema software. Il concetto di facoltativo e obbligatorio descrive la priorità della caratteristica documentata del sistema software.

Ci riferiamo a loro come caratteristiche "belle da avere" in contrapposizione ai requisiti.

Per la documentazione dei requisiti software, la formulazione dei Requisiti opzionali è perfettamente OK, purché si utilizzi questo termine in conformità con RFC 2119 Parole chiave per indicare i Livelli dei requisiti , ovvero per indicare elementi che sono veramente opzionali.

Quando il testo della specifica implica verbo anziché aggettivo, utilizzare "MAGGIO" invece di "OPZIONALE".

Poiché è piccolo e facile da leggere, il testo RFC è completamente riportato di seguito:

    Network Working Group S. Bradner
    Richiesta di commenti: 2119 Harvard University
    BCP: 14 marzo 1997
    Categoria: Best Practice corrente


            Parole chiave da utilizzare nelle RFC per indicare i livelli dei requisiti

    Stato di questo memo

       Questo documento specifica le migliori pratiche attuali di Internet per il
       Internet Community e richiede discussioni e suggerimenti per
       miglioramenti. La distribuzione di questo memo è illimitata.

    Astratto

       In molti documenti di traccia standard vengono utilizzate diverse parole per indicare
       i requisiti nelle specifiche. Queste parole sono spesso
       capitalizzati. Questo documento definisce queste parole come dovrebbero essere
       interpretato nei documenti IETF. Autori che seguono queste linee guida
       dovrebbe includere questa frase vicino all'inizio del loro documento:

          Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DEVE", "DEVE
          NOT "," DOVREBBE "," NON DOVREBBE "," CONSIGLIATO "," MAGGIO "e
          "OPZIONALE" in questo documento deve essere interpretato come descritto in
          RFC 2119.

       Si noti che la forza di queste parole è modificata dal requisito
       livello del documento in cui vengono utilizzati.

    1. DEVE Questa parola, o i termini "RICHIESTO" o "SHALL", indicano che
       la definizione è un requisito assoluto della specifica.

    2. NON DEVE Questa frase, o la frase "NON DEVE", significa che il
       la definizione è un divieto assoluto della specifica.

    3. DOVREBBE Questa parola, o l'aggettivo "CONSIGLIATO", significa che lì
       possono esistere validi motivi in ​​particolari circostanze per ignorare a
       elemento particolare, ma le implicazioni complete devono essere comprese e
       attentamente valutato prima di scegliere un corso diverso.

    4. NON DOVREBBE che questa frase o la frase "NON RACCOMANDATO" significa che
       possono sussistere validi motivi in ​​particolari circostanze in cui il
       un comportamento particolare è accettabile o addirittura utile, ma completo
       le implicazioni dovrebbero essere comprese e il caso attentamente valutato
       prima di implementare qualsiasi comportamento descritto con questa etichetta.

    5. MAGGIO Questa parola, o l'aggettivo "OPZIONALE", significa che un oggetto è
       veramente facoltativo. Un fornitore può scegliere di includere l'articolo perché a
       un determinato mercato lo richiede o perché il venditore lo ritiene
       migliora il prodotto mentre un altro venditore può omettere lo stesso articolo.
       Un'implementazione che non include una particolare opzione DEVE essere
       pronto a interagire con un'altra implementazione che lo fa
       include l'opzione, anche se forse con funzionalità ridotta. Nel
       stessa vena un'implementazione che include una particolare opzione
       DEVE essere pronto a interagire con un'altra implementazione che
       non include l'opzione (tranne, ovviamente, per la funzione il
       opzione fornisce.)

    6. Guida all'uso di questi imperativi

       Gli imperativi del tipo definito in questo memo devono essere usati con cura
       e con parsimonia. In particolare, DEVONO essere utilizzati solo dove si trova
       effettivamente richiesto per l'interoperabilità o per limitare il comportamento che ha
       potenziale rischio di danno (ad es. limitazione delle ritrasmissioni)
       ad esempio, non devono essere utilizzati per tentare di imporre un metodo particolare
       sugli implementatori in cui il metodo non è richiesto per l'interoperabilità.

    7. Considerazioni sulla sicurezza

       Questi termini vengono spesso utilizzati per specificare il comportamento con la sicurezza
       implicazioni. Gli effetti sulla sicurezza della mancata attuazione di un MUST o
       DOVREBBE, o fare qualcosa che la specifica dice NON DEVE o DOVREBBE
       NON essere fatto può essere molto sottile. Gli autori dei documenti dovrebbero prendersi il tempo necessario
       per elaborare le implicazioni di sicurezza di non seguire
       raccomandazioni o requisiti che la maggior parte degli implementatori non avrà
       ha avuto il vantaggio dell'esperienza e della discussione che ha prodotto il
       specifica.

    8. Ringraziamenti

       Le definizioni di questi termini sono un insieme di definizioni prese
       da un numero di RFC. Inoltre, i suggerimenti sono stati
       incorporato da un numero di persone tra cui Robert Ullmann, Thomas
       Narten, Neal McBurnett e Robert Elz.

Non farebbe male se la tua documentazione si riferisse a RFC come fonte di definizioni:

Questo documento utilizza definizioni basate su quelle specificate in RFC 2119 .

Apprezzo che non sia una risposta alla tua domanda, ma nel mio mondo, è ancora un requisito, anche se per qualsiasi motivo non la soddisferai.

Mi piace l' approccio MoSCoW (Must Have, Should have, Potrebbe non avere, questa volta non avrò) alla classificazione dei requisiti con gli utenti, insieme ad altri fattori (nel mio mondo regolamentato, i requisiti possono essere critici o non critici, e molti l'argomento si accende su requisiti facoltativi ma critici.)

Una parola migliore per un requisito facoltativo è " Raccomandazione "

Che ne dite di identificarlo come una funzionalità opzionale o attività opzionali. Ciò avverrà solo se a un certo punto del progetto è stato stabilito che ci sono tempo e denaro disponibili per completare queste funzionalità.

Potrebbero anche essere attivati ​​se si verifica un evento esterno. Se i clienti passano a Windows 8, dovranno essere eseguite le seguenti attività ...

La descrizione della funzione dovrebbe includere una scadenza per determinare se verranno eseguite.

I requisiti sono classificati in 4 aree in Ingegneria del software:

1. Requisiti aziendali : si concentra sugli obiettivi aziendali generali e sugli obiettivi del sistema
2. Requisiti dell'utente : si concentra sugli obiettivi dell'utente e su ciò che gli utenti devono fare per utilizzare il sistema per raggiungere gli obiettivi aziendali
3. Requisiti funzionali : quali funzionalità e compiti deve svolgere il sistema per raggiungere gli obiettivi aziendali
4. Requisiti non funzionali : quali requisiti esistono oltre a quelli funzionali. Ciò include ambiente, vincoli, interfaccia, problemi di manutenzione, ecc.

Ora i requisiti possono essere opzionali o obbligatori , a seconda delle 4 categorie precedenti, che ho delineato sopra. I requisiti opzionali possono anche rientrare nell'ambito del sistema in esame o anche al di fuori del suo ambito. I requisiti opzionali sono buoni mezzi per evitare Scree Creep e definire l'ambito in termini precisi.

I requisiti opzionali faranno sempre parte dell'ingegneria del software in quanto ci aiutano a identificare l'ambito e sono un buon mezzo per evitare Scope Creep. Non si può mai dire che contraddicono le pratiche ingegneristiche di SDLC. Tuttavia, i requisiti devono essere prioritari e ben definiti.

Nel modello Volere viene utilizzato il termine "Sala d'attesa".

... Questo modello è destinato all'uso come base per le specifiche dei requisiti. Il modello fornisce ciascuno dei tipi di requisiti appropriati per i sistemi aziendali, scientifici e software di oggi. Fornisce una lista di controllo, struttura e tracciabilità per le vostre esigenze ... Il modello è indipendente dallo strumento ed è stato usato con successo con Yonix, Requisite, DOORS, Calibre RM, IRqA e altri strumenti popolari ...

Le tecniche di Volere sono descritte nel libro Mastering the Requirements Process di Suzanne Robertson e James Robertson ...

Nella mia attività (veicoli spaziali), sono chiamati "obiettivi", indicando che sono documentati e che gli sforzi saranno spesi per raggiungerli, ma il sistema sarà comunque considerato di successo se non vengono raggiunti; "desideri" (non una parola vera, ma eccoti qui), indicando che qualcuno li vuole e stanno cercando di raggiungere lo stato degli obiettivi ma non sono ancora accettati o documentati; o "requisiti striscianti" che è una versione più dispregiativa dei desideri che indica cose che stanno cercando di assorbire risorse ma che non valgono la pena in un progetto che cerca di ottenere "abbastanza buono" dove comprometteranno o minacceranno il raggiungimento dei requisiti reali.

Se le tue esigenze sono prioritarie , potresti considerarle requisiti a bassa priorità .

Sono abbastanza sorpreso che nessuno abbia mai detto che quelli sono chiamati "obiettivi". Ogni azienda per cui ho lavorato li ha chiamati così. Sono indicati con l'uso delle parole "volontà" o "dovrebbe" invece di "deve". A volte sono inclusi tra parentesi graffe quando si parla di numeri. ad es. il sistema deve funzionare ininterrottamente senza la necessità di attenzione dell'operatore per 100 {250} ore. Ciò significa che il requisito che deve essere soddisfatto è di 100 ore, ma l'obiettivo è di 250 ore.

Come nota a margine, raramente qualcuno progetta effettivamente di soddisfare i requisiti oggettivi, a meno che non vi sia una sorta di incentivo in questione.

Il termine "abbandono" viene talvolta utilizzato per requisiti opzionali. Tuttavia, potrebbe non essere appropriato per un documento formale.

Sono sorpreso che tutte le risposte riguardino i requisiti di monitoraggio nello sviluppo del progetto. Nonostante sia uno sviluppatore, non mi sono mai preoccupato troppo di questa terminologia in quel contesto. Quando ho letto per la prima volta la domanda, l'ho assunto in relazione alle specifiche del prodotto dell'utente, non allo sviluppo del prodotto. Ad esempio, un'enciclopedia potrebbe elencare una stampante a colori come requisito opzionale. È necessario se si desidera il pieno vantaggio dell'app ma facoltativo se si desidera visualizzare lo schermo. E se avessi ad esempio una stampante monocromatica? Come chiarire se la tua app funziona con l'ovvia restrizione che alcune foto potrebbero non essere così belle? O non stampare affatto? Come un altro esempio, come devo controllare una revisione della stampante per verificare se l'inchiostro è un requisito o un requisito facoltativo in una stampante multifunzione? In altre parole, posso ancora scansionare? Alcuni suggerimenti sulla terminologia e su cosa cercare sarebbero i benvenuti sia come sviluppatore / venditore del prodotto che come consumatore.

Le definirei "funzionalità opzionali", non requisiti opzionali. I requisiti sembrano qualcosa che devi avere , mentre le caratteristiche sembrano un componente aggiuntivo del prodotto originale.