Gara contro requisiti e progettazione della soluzione

Question

Gara contro requisiti e progettazione della soluzione

#1 da (4 voti)
#2 da (3 voti)

1

Convenzionalmente, quale dei suddetti documenti è considerato il più importante per quanto riguarda l'accettazione del sistema?

Recentemente ho avuto una conversazione in questo senso:

È stato affermato che i requisiti iniziali / la documentazione di gara dovrebbero essere utilizzati per determinare l'accettazione del sistema. Si è detto che il design della soluzione serve solo a descrivere il modo in cui il sistema risolverà il problema, non il problema che risolverà. Inoltre, è stato affermato che se i requisiti non vengono rispettati durante la progettazione della soluzione, i requisiti dovrebbero essere referenziati durante l'accettazione del sistema e che in caso di mancanze di requisiti si dovrebbe fare riferimento all'offerta originale.

Al contrario, ho suggerito che - mentre i requisiti potrebbero essere basati sulla gara d'appalto originale - la sostituiscono una volta concordati con gli stakeholder. Inoltre, durante la progettazione della soluzione, vengono eseguite analisi per indirizzare e perfezionare questi requisiti iniziali, traducendoli in un sistema in grado di soddisfare i requisiti effettivi. Una volta firmato dagli utenti interessati, questo design di soluzione deve assolutamente rappresentare i requisiti (in virtù del fatto che è stato progettato su di essi) ma in realtà li sostituisce come base per l'accettazione del sistema.

Uno dei suddetti argomenti è più valido dell'altro?

EDIT: scuse per i termini ambigui. In questa situazione, la gara d'appalto è il documento che il cliente ha immesso sul mercato durante lo shopping per un fornitore - include i dettagli di tutte le funzionalità di alto livello che stanno cercando. Il design della soluzione non è un documento tecnico, è la specifica funzionale.

requirements documentation systems-analysis acceptance-testing

posta Tom Tom 07.11.2013 - 18:04

fonte

2 risposte

3

L'accettazione del sistema dovrebbe essere contraria ai requisiti del cliente. È corretto che l'analisi e la derivazione siano eseguite rispetto al set iniziale di requisiti del cliente. Spesso, le esigenze dei clienti non sono sufficienti per progettare e implementare, quindi è necessario elaborare le esigenze del cliente, perfezionare le proprie esigenze e produrre requisiti di sistema tecnici adatti agli ingegneri contro cui lavorare. In alcuni casi, potrebbe persino essere necessario aggiungere requisiti a causa delle normative o per raggiungere gli obiettivi aziendali. Tutti questi perfezionamenti e derivazioni devono essere convalidati con il cliente per garantire che tutti comprendano cosa deve essere fatto e quali saranno i prodotti finali.

I requisiti derivati dovrebbero essere riconducibili ad alcuni requisiti di livello superiore, un requisito del cliente, un regolamento o un obiettivo aziendale. Ciò garantirà che la progettazione e l'implementazione soddisfino i requisiti noti. Garantire che ogni requisito del cliente sia identificato a livello di sistema / requisiti tecnici aiuta anche ad evitare i requisiti mancanti nelle attività di progettazione e implementazione.

risposta data 07.11.2013 - 18:41

fonte

Leggi altre domande sui tag requirements documentation systems-analysis acceptance-testing

Richiede uno specifico ordine di compilazione Come determinare il design migliore?

score 4 · Accepted Answer

Il superamento dei test di accettazione è un'indicazione che il sistema soddisfa i requisiti degli utenti in modo accettabile. In quanto tale, il documento dei requisiti è generalmente considerato la fonte della verità per i criteri di accettazione.

Ci sarà quasi sempre un'ulteriore elaborazione dei requisiti durante la progettazione. Se questi sono veramente un'espansione dello scopo, il documento dei requisiti dovrebbe essere aggiornato per riflettere questo. A seconda di come è formale la tua procedura, questo può comportare richieste di cambiamento, bla bla bla.