Qual è la parola migliore per un requisito facoltativo nell'ingegneria del software? La frase è contraddittoria. Ho usato "Requisiti non-core" nei progetti precedenti.
Qual è la parola migliore per un requisito facoltativo nell'ingegneria del software? La frase è contraddittoria. Ho usato "Requisiti non-core" nei progetti precedenti.
È possibile utilizzare il termine "requisito fuori ambito". Ciò significa che il requisito è stato acquisito nel tuo processo ed è tracciabile, ma è stato determinato che il requisito è qualcosa che va oltre l'ambito attuale del sistema, a causa di una serie di motivi, come budget, pianificazione, tempo, o fattibilità.
Tuttavia, la frase "requisito facoltativo" è comunemente usata per indicare qualcosa che è in ambito, ma non necessariamente richiesto dal sistema. È una misura della priorità del requisito. Nelle mie esperienze, i requisiti sono spesso considerati prioritari come obbligatori, desiderabili o facoltativi (sebbene esistano anche altri schemi). Affinché un progetto sia considerato completo e pienamente funzionale, tutti i requisiti obbligatori devono essere soddisfatti. Date le risorse sufficienti, i requisiti desiderabili sarebbero implementati successivamente. Infine, qualsiasi cosa considerata facoltativa sarebbe inclusa.
Credo che la confusione derivi dal termine "requisito". Nella lingua inglese, un requisito è "una cosa che è necessaria" o "una condizione obbligatoria, obbligatoria o necessaria". Tuttavia, nell'ingegneria del software, il requisito del termine è semplicemente una caratteristica documentata di un sistema software. Il concetto di facoltativo e obbligatorio descrive la priorità delle caratteristiche documentate del sistema software.
Ci riferiamo ad esse come caratteristiche "belle da avere" rispetto ai requisiti.
Per la documentazione sui requisiti software, la dicitura Requisiti opzionali è perfettamente OK, a condizione che si usi questo termine in conformità con RFC 2119 Parole chiave per indicare i livelli di fabbisogno - vale a dire per indicare elementi realmente opzionali.
Se il testo della specifica implica verbo anziché aggettivo, utilizza "MAG" invece di "FACOLTATIVO".
Poiché è piccolo e di facile lettura, il testo RFC è completamente citato di seguito:
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement Levels
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmissions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for interoperability.
7. Security Considerations
These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification.
8. Acknowledgments
The definitions of these terms are an amalgam of definitions taken
from a number of RFCs. In addition, suggestions have been
incorporated from a number of people including Robert Ullmann, Thomas
Narten, Neal McBurnett, and Robert Elz.
Non sarebbe male se la tua documentazione si riferisce a RFC come fonte di definizioni:
This document uses definitions based upon those specified 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 lo realizzerai.
Mi piace l'approccio MoSCoW (deve avere, dovrebbe avere, potrebbe avere, non avrà questa volta) categorizzazione dei requisiti con gli utenti, insieme ad altri fattori (nel mio mondo regolamentato, i requisiti possono essere critici o non critici, e molti argomenti divergono su requisiti facoltativi ma critici.)
Una parola migliore per un requisito facoltativo è " Raccomandazione "
Che ne dici di identificarlo come una funzione opzionale o attività opzionali. Questi saranno fatti solo se a un certo punto del progetto è stato determinato che ci sono tempo e denaro disponibili per completare queste funzionalità.
Possono anche essere attivati se si verifica un evento esterno. Se i clienti effettuano il passaggio a Windows 8, sarà necessario eseguire le seguenti attività ...
La descrizione della funzione dovrebbe includere una scadenza per determinare se verranno eseguiti.
I requisiti sono suddivisi in 4 aree in Ingegneria del software:
Ora i requisiti possono essere Facoltativi 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 al di fuori del suo ambito. I requisiti facoltativi sono buoni mezzi per evitare Scope Creep e definire il tuo ambito in termini precisi.
I Requisiti Opzionali faranno sempre parte di Ingegneria del Software poiché ci aiutano a identificare l'ambito e sono un buon mezzo per evitare Scope Creep. Non si può mai dire che contraddicano le pratiche ingegneristiche di SDLC. Tuttavia, i requisiti devono essere prioritari e ben definiti.
Nel modello di Volere viene utilizzato il termine "Sala d'attesa".
...This template is intended for use as the foundation for your requirements specifications. The template provides for each of the requirements types appropriate for today's business, scientific and software systems. It provides a checklist, structure and traceability for your requirements... The template is tool independent, and has been successfully used with Yonix, Requisite, DOORS, Caliber RM, IRqA and other popular tools...
The Volere techniques are described in the book Mastering the Requirements Process by Suzanne Robertson and James Robertson...
Nella mia azienda (veicoli spaziali), sono chiamati "obiettivi", che indicano che sono documentati e che lo sforzo sarà speso per soddisfarli, ma il sistema sarà comunque considerato di successo se non vengono raggiunti; "desideri" (non una parola vera, ma ci sei), 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 di desideri che indicano cose che stanno cercando di raccogliere risorse ma che non ne valgono la pena in un progetto che cerca di raggiungere "abbastanza buono" dove comprometteranno o minacceranno di raggiungere i requisiti reali.
Se i tuoi requisiti sono prioritari , potresti considerarli requisiti a bassa priorità .
Sono abbastanza sorpreso che nessuno abbia menzionato che quelli sono chiamati "obiettivi". Ogni azienda per cui ho lavorato li ha chiamati così. Sono indicati con l'uso delle parole "will" o "should" invece di "shall". A volte sono inclusi in parentesi quando si parla di numeri. per esempio. Il sistema deve funzionare ininterrottamente senza richiedere l'intervento dell'operatore per 100 {250} ore. Significa che il requisito da rispettare è di 100 ore, ma l'obiettivo è di 250 ore.
Come nota a margine, molto raramente qualcuno ha mai progettato per soddisfare il requisito oggettivo, a meno che non ci sia un qualche tipo di incentivo.
Il termine "Desiderio" viene talvolta usato per requisiti facoltativi. Tuttavia, potrebbe non essere appropriato per un documento formale.
Sono sorpreso che tutte le risposte riguardino i requisiti di tracciamento 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, ho pensato che si riferisse alle specifiche del prodotto dell'utente, non allo sviluppo del prodotto. Ad esempio, un'enciclopedia potrebbe elencare una stampante a colori come requisito facoltativo. È necessario se si desidera il massimo vantaggio dell'app ma facoltativo se si desidera visualizzare lo schermo. Ma cosa succede se tu avessi per esempio una stampante monocromatica? Come chiarire se la tua app funziona con la restrizione ovvia che alcune foto potrebbero non sembrare così buone? Oppure non stampare affatto? Come un altro esempio, come dovrei 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 eseguire la scansione? Alcuni suggerimenti sulla terminologia e su cosa cercare sarebbero benvenuti sia come sviluppatore / venditore di prodotti sia come consumatore.
Li definirei "funzioni opzionali", non requisiti facoltativi. I requisiti sembrano qualcosa che devi avere , mentre le funzioni sembrano un componente aggiuntivo del prodotto originale.
Leggi altre domande sui tag requirements terminology