Sto studiando per l'esame CPRE Foundation da Consiglio di ingegneria dei requisiti internazionali . Nell'esame, c'è una dichiarazione:
Quality Requirements are elicited after the Functional Requirements.
La risposta a questa affermazione è fornita come falsa. Ciò significa che i requisiti di qualità dovrebbero essere evocati prima dei requisiti funzionali o contemporaneamente dei requisiti funzionali?
Non ho familiarità con il modo in cui l'IREB insegna l'ingegneria dei requisiti o i contenuti che raccomandano per conoscere l'ingegneria dei requisiti . Conosco l'ingegneria dei requisiti del software dai lavori di Karl Wiegers e Joy Beatty , Anthony Chen e Joy Beatty e Stephen Withall oltre alle mie esperienze personali di raccolta e analisi dei requisiti.
Poiché sai che l'affermazione secondo cui i requisiti di qualità sono richiesti dopo che i requisiti funzionali sono falsi, ci sono solo due possibili significati. O tutti i requisiti dovrebbero essere evocati simultaneamente o i requisiti di qualità sono richiesti prima dei requisiti funzionali.
Considerando ciò che è considerato un requisito non funzionale o un attributo di qualità, alcuni attributi di qualità sono specificamente correlati a specifiche funzionalità. Esempi di questi possono includere prestazioni e stabilità: una determinata funzione deve essere completata in un determinato periodo di tempo o il sistema deve essere misurabile in risposta a determinati carichi o durante l'esecuzione di determinati lavori. Altri attributi di qualità hanno maggiori probabilità di influenzare il sistema nel suo complesso: disaster recovery, fault tolerance, maintainability, security. Un terzo set di attributi di qualità si applica al prodotto e ai processi utilizzati: gestione della configurazione, impegno, licenza.
L'affermazione che i requisiti di qualità sono richiesti prima dei requisiti funzionali non ha senso. È difficile parlare di requisiti specifici di rendimento in un modo che rende un buon requisito a meno che tu non stia parlando di funzionalità prima o simultaneamente.
Pertanto, l'intenzione è riconoscere che gli attributi di qualità dovrebbero essere suscitati dagli stakeholder in concomitanza con i requisiti funzionali. Tuttavia, la discussione di alcune caratteristiche dei requisiti (come la completezza o la coerenza) deve essere fatta in un contesto che includa tutti i requisiti - funzionali e non funzionali.
L'NFR deve essere indotto prima del funzionale in quanto presenta l'ambito necessario per i requisiti funzionali.
Ciò non significa che non possa cambiare nel corso del tempo.
Pensiamo a un esempio pratico di cosa succede quando fai il contrario.
Requisito funzionale. Recupera tutti i record nel database in modo che l'utente possa scorrere un elenco preciso online.
Senza una NFR che indica per quanto tempo un normale tempo di transazione dovrebbe essere assegnato a un carico. Il requisito di cui sopra è facile da implementare con una query e può essere prontamente approvato.
Ora aggiungiamo alcuni NFR.
Se li unisci, il design della soluzione cambia radicalmente da qualcosa di semplice a qualcosa che richiede un po 'più di ingegneria o negoziazione.
Prima di avere gli NFR in primo luogo è possibile respingere gli FR o modificare gli NFR per essere più ragionevoli.
Gli NFR sono anche più facili da definire e capire al di fuori delle zone di sviluppo in quanto si tratta solo di numeri di destinazione.
Per prima cosa è necessario avere requisiti funzionali. Puoi iniziare a pensare alla qualità solo quando sai a cosa penserai. La qualità senza soggetto è priva di significato.
Leggi altre domande sui tag requirements quality-attributes functional-requirements