Qual è la differenza tra requisiti e specifiche? [chiuso]

122

Mi è stato assegnato il compito di sviluppare requisiti e specifiche per un progetto che sta iniziando il nostro gruppo.

Mi sono reso conto che non conosco la differenza; una ricerca su Google mi ha confuso di più - sembra che alcune persone affermino che le specifiche sono requisiti, ma a un livello inferiore.

requirements specifications

Concordo con le risposte di alto voto, ma penso anche che il termine specifica sia talvolta usato come un termine più generico nel settore del software in riferimento a qualsiasi documento che descriva un sistema o un pezzo di software. Come prova - google "specifica dei requisiti". Quando viene utilizzato in questo modo, significa un documento che specifica qualcosa, ovvero: specifica i requisiti per un software. Non giudicherò se questo è un uso corretto della parola o non volevo solo sottolineare che le specifiche non significano sempre la stessa cosa per tutti.

— Shane Wealti,

1

Sì, ecco perché le persone dovrebbero dire "Requisiti aziendali" e "Specifiche di progettazione" / "Specifiche tecniche" o qualcosa del genere. Le parole da sole sono piuttosto vaghe.

— user606723

Pensala in questo modo (parlando rozzamente): Requisiti = documenti e specifiche dei requisiti = casi d'uso / documenti di progettazione

— Dottorato di ricerca

4

Perché non chiedi alle persone per le quali stai realizzando? Solo loro possono rispondere a ciò che è necessario nel tuo caso specifico .

— Jaap

Questo articolo offre una risposta esaustiva: ece.cmu.edu/~koopman/des_s99/requirements_specs

— Julien-L

129

La risposta mordace è che i requisiti sono ciò che il tuo programma dovrebbe fare, le specifiche sono come pensi di farlo.

Un altro modo di osservarlo è che i requisiti rappresentano l'applicazione dal punto di vista dell'utente o dell'azienda nel suo complesso. Le specifiche rappresentano l'applicazione dal punto di vista del team tecnico. Specifiche e requisiti comunicano approssimativamente le stesse informazioni, ma a due destinatari completamente diversi.

— Bryan Oakley
fonte

4

Il cosa / come il morso del suono è giusto, una specie di; ma confuso, perché puoi anche guardare le specifiche di un programma che descrivono cosa dovrebbe fare e il design è come dovrebbe farlo. Un altro è pl dichiarativo (come prolog e SQL), in cui si afferma il cosa non il come . Una risoluzione è che sono una gerarchia di astrazioni, con un genitore che afferma cosa e bambini che affermano come (fuori contro dentro). Preferisco di gran lunga il tuo secondo punto di vista, che è più vicino a "ciò che è per il " contro "quello che è ", cioè a beneficio vs. funzione.

— 13ren

In generale sarei d'accordo con te, ma è solo 'un'altra' opinione e non la risposta corretta. Ad esempio, dai un'occhiata alla pagina Wiki per Requisiti ( en.wikipedia.org/wiki/Requirement ). Esistono requisiti non funzionali, che per definizione è per il team tecnico. O requisiti di architettura e vincoli, di nuovo tecnici ma non li chiamano "specifiche". Penso che non ci sia una risposta corretta e sarà sempre "sfocato" da società a società e da sviluppatore a sviluppatore.

— Jeach,

1

Dai un'occhiata alla risposta "Adam Wuerl" qui sotto, penso che sia la dichiarazione più accurata alla domanda postata.

— Jeach,

1

@Jeach: "muggito" [sic] è relativo. Potrebbe essere sotto questo post in questo momento, ma potrebbe spostarsi sopra, rendendo il tuo commento più difficile da capire

— Bryan Oakley

1

Un'altra prospettiva. Wikipedia definisce le specifiche come un "insieme di requisiti". Ciò significa che una specifica può essere solo 1 requisito, s: = {r1}. Sembra più che i "requisiti" colloquiali siano requisiti di "alto livello", mentre le "specifiche tecniche" sono requisiti di basso livello, una cosa LOD.

— Lance Pollard,

38

I requisiti documentano ciò che è necessario: non dovrebbero specificare il come, ma il cosa.

Le specifiche documentano come raggiungere i requisiti: devono specificare come.

In molti luoghi questi documenti non sono separati e sono usati in modo intercambiabile.

— Oded
fonte

2

Nella mia azienda normalmente utilizziamo i termini "specifica dei requisiti" per il che cosa (si specifica, si annotano i dettagli, di quello che si cosa) e "specifica del progetto" per il come (si specifica, si annotano i dettagli, di come si pianificare di implementarlo).

— Giorgio,

16

Sono un ingegnere di sistemi nel settore aerospaziale, dove entrambi i termini sono ampiamente utilizzati. La distinzione è chiara e non complessa come la fanno gli altri.

Una specifica è un documento che specifica un sistema o un prodotto, ad esempio una specifica di sviluppo di un articolo principale per un F-14. Ci sono molte sezioni / contenuti in una specifica: requisiti, definizioni, documenti di riferimento, glossario, informazioni di verifica, ecc.

Un requisito è una singola dichiarazione di qualcosa che il prodotto o il sistema deve fare. Una specifica può contenere centinaia di requisiti. La metodologia della vecchia scuola afferma che la dichiarazione dei requisiti deve usare la parola "deve", per separare i requisiti dalle dichiarazioni dei fatti o dalle definizioni. (Non sono sicuro se i nuovi bambini agili si attengano a tutto questo o no; la meticolosità ha il suo uso ma a volte è un po 'esigente.)

Quindi una specifica è un documento pieno di requisiti, oltre ad altre informazioni di supporto e accessorie.

— Adam Wuerl
fonte

4

Come ho detto in un altro commento, è molto sfocato per tutti e probabilmente lo sarà sempre. Ma basandomi sulle mie ricerche MOLTO approfondite su questo argomento esatto, direi che la tua risposta è la più accurata per i miei risultati / conclusioni.

— Jeach,

2

Sempre utile per ottenere il contributo di un vero ingegnere. Grazie!

— LeWoody,

In alternativa, una specifica può contenere 0 requisiti. Il tuo esempio è davvero valido per una disciplina di ingegneria aeronautica molto specifica. Non sono così sicuro che sia generalmente applicabile al dominio di sviluppo / programmazione del software. Quando la maggior parte dei software è guidata dalle esigenze aziendali, ha senso iniziare con un documento dettagliato sui requisiti aziendali prima di valutare i vincoli tecnici e progettare una soluzione. Le specifiche tecniche seguiranno il BRD, i vincoli dei documenti e forniranno un approccio dettagliato e specifico per soddisfare i requisiti aziendali nel BRD.

— Bryan 'BJ' Hoffpauir Jr.

1

@ Bryan'BJ'Hoffpauir Sono sicuro che ci sono casi in cui i documenti sono etichettati con specifiche e non hanno requisiti in essi, ma direi che quelli sono un uso improprio del termine. Una specifica è un documento di requisiti - fine della storia. È un termine ampiamente accettato in tutti i settori dell'aerospazio e della difesa ed è inattaccabile dall'ingegneria dei sistemi, che è la disciplina responsabile dei requisiti e della verifica. Anche nel caso in cui descrivi il termine si applica: il BRD è una specifica, anche la specifica tecnica suona come una, solo con diversi tipi di requisiti.

— Adam Wuerl,

13

Requisiti:

Determinare le esigenze o le condizioni da soddisfare per un prodotto nuovo o alterato, tenendo conto delle esigenze eventualmente contrastanti dei vari stakeholder.

specifiche tecniche:

Forniscono un'idea precisa del problema da risolvere in modo da poter progettare in modo efficiente il sistema e stimare il costo delle alternative di progettazione. Forniscono una guida ai tester per la verifica (qualifica) di ciascun requisito tecnico.

La citazione è tratta da "Fondamenti di ingegneria dei sistemi ^* ".

I requisiti si basano sulle esigenze delle parti interessate, le specifiche sono più un documento dettagliato e tecnico interno. Sono diversi, ma parlano della stessa cosa.

_{* Defense Acquisition University Press, 2001. Versione PDF del testo.}

— talabes
fonte

Penso che sia importante che la tua definizione affermi che le specifiche definiscono il PROBLEMA. In questo modo, una specifica PROBLEMA è un requisito. Una specifica SOLUTION o DESIGN fa parte del design.

— LeWoody,

6

I requisiti sono la descrizione degli utenti di ciò che il prodotto finito, ai loro occhi, dovrebbe fare.

La specifica è la descrizione tecnica della soluzione in generale, che copre i requisiti e molto altro - ad es. Costi, tecnicismi, problemi, ecc.

Pertanto, uno dei punti principali è che i Requisiti devono venire prima di poter scrivere una Specifica.

(Notare la terminologia - prodotto e soluzione - la stessa cosa ma da diverse prospettive ...)

— Arj
fonte

1

Vorrei scambiare i termini "prodotto" e "soluzione", perché una soluzione è di solito in termini di problema del cliente, mentre un prodotto è di solito in termini di venditore (cioè implementatore tecnico). Un contrasto simile è beneficio / caratteristica, in cui vantaggio è in termini di clienti (che serve a loro), e funzionalità è in termini di implementazione (che in realtà è che, in modo che possiamo rendere).

— 13

1

Vedo il tuo punto, ma penso che entrambe le angolazioni descrivano adeguatamente la situazione. Ho ritenuto che un cliente avrebbe acquistato un prodotto, proprio come quando vai in un negozio. Un fornitore di software offrirebbe quindi la propria soluzione al problema di fondo. Se dovessi andare a fare shopping per trovare una soluzione al mio problema, probabilmente penserei "Ho bisogno di un prodotto che fa xyz", non "Ho bisogno di una soluzione al mio problema di abc". Penso sia solo una questione di preferenza.

— Arj,

interessante. Vedo i clienti "alla ricerca di un prodotto", quando esiste una categoria di prodotti consolidata. Ma cercano quel prodotto perché hanno già capito che risolverà il loro problema - cioè cercano quel prodotto, non per se stesso, ma come soluzione. È anche vero che un fornitore commercializza il proprio prodotto come una "soluzione", ma è perché stanno cercando di comunicare con i clienti (che cercano soluzioni ai loro problemi) e costruire qualcosa che sarà desiderato. Realmente costruendo il prodotto (vale a dire, la cosa stessa e le sue caratteristiche indipendentemente dal motivo per cui sono necessari)

— 13ren

Riesco a vedere i clienti "alla ricerca di un prodotto", quando esiste una categoria di prodotti consolidata, ma lo cercano come soluzione a un problema / bisogno che hanno. I venditori commercializzano i loro prodotti come "soluzioni", perché comunicano con i clienti (che hanno problemi a richiedere soluzioni). Quando si costruisce il prodotto (la cosa stessa e le sue caratteristiche, non il motivo per cui li stanno costruendo). Un argomento è che un problema può avere soluzioni molto diverse, ma un prodotto è una cosa specifica.

— 13

[spiegando perché due commenti]: I commenti SO sono così dolorosi: premere "return" invierà il commento, anche se si tratta di un'area di testo a più righe. E se impiegherai più di 5 minuti per terminarlo, non accetterà la modifica. Quindi devi inviarlo come secondo commento. Stavo modificando solo per adattarlo alla lunghezza. sospiro . La prossima volta mi limiterò a diffondere due commenti in primo luogo ... [comunque, sono d'accordo che il punto di vista - acquirente / venditore - è la distinzione principale. Sono turbato dalla tua terminologia, ma penso che approfondisca la mia comprensione per cercare di articolare il perché.]

— 13ren

4

Requisito: cosa deve (deve) fare il sistema o sottosistema.

Specifica: cos'è il componente, sottosistema o sistema.

Ciò è fondamentale nel settore manifatturiero dei dispositivi medici poiché è necessario condurre una verifica in base ai propri requisiti (input) per dimostrare di disporre di specifiche valide (output). Le insidie tipiche di questo settore sono le aziende (1) che dimenticano di definire i requisiti (perché non comprendono la differenza tra requisito e specifica); (2) Effettuare la verifica solo in base alle specifiche e (3) Non assicurare che i requisiti vengano tradotti accuratamente in sottoassiemi e specifiche dei componenti.

Al termine, viene richiesto di convalidare i requisiti utente per il prodotto.

— Paolo Bacco
fonte

3

Forse la confusione è che ho sentito che le specifiche si riferiscono ai documenti sulle specifiche dei requisiti aziendali o ai documenti SRS (specifiche sui requisiti software) standard IEEE.

Esempio di modello SRS standard IEEE

Ho anche sentito che i termini specifiche si riferiscono in modo più informale alle specifiche tecniche che spiegano le decisioni di progettazione e un piano di attuazione.

EDIT: Ho appena notato che il link non è corretto ... Tra poco pubblicherò un link corretto.

— albero_acero
fonte

1

Un buon punto sul termine SRS!

— LeWoody,

2

Il collegamento è ora completamente interrotto. Non sono sicuro di cosa indicasse né di quale materiale là fuori dovrebbe indicare.

3

Una specifica è un requisito che ha superato la fattibilità ed è pronta per essere implementata. È un requisito che si è evoluto in fase di progettazione.

In altre parole:

Un requisito è il comportamento (o non comportamento) "come pianificato" o "come desiderato"
Una specifica è il comportamento (o non comportamento) "da costruire" o "come costruito"

Esempio:

requisito: 1. l'utente preme il pulsante OK 2. il sistema stampa la fattura
specifica: 1. l'utente preme il pulsante OK 2. il sistema stampa la fattura

Come puoi vedere, il contenuto di entrambi può essere lo stesso. La differenza è che il requisito è un artefatto di analisi. La specifica è un artefatto di progettazione.

In una documentazione finale costruita, in genere troverai la parola "specifica", anziché "requisito", poiché i requisiti sono stati convertiti in specifiche.

Nota: l'esempio sopra contiene elementi di progettazione, a causa del vincolo di progettazione.

— fox.bailey
fonte

0

I requisiti sono ciò che l'applicazione fa

Le specifiche sono COME l'applicazione fa quello che fa.

Devono essere ortogonali!

I responsabili di prodotto scrivono i requisiti, gli ingegneri capo scrivono le specifiche.

— jayunit100
fonte

2

Non sono sicuro che siano completamente ortogonali, almeno in pratica. C'è molto grigio purtroppo.

— LeWoody,

Sono grigi solo se si lasciano fuori i modificatori: requisiti aziendali, requisiti funzionali, requisiti non funzionali si riferiscono a una capacità del sistema (il COSA fa). Le specifiche tecniche sono ortogonali ai requisiti aziendali (il COME lo fa).

— Bryan 'BJ' Hoffpauir Jr.

0

In un modo, forse non nel modo giusto, per vederlo:

I requisiti sono elementi (capacità, caratteristiche, comportamenti, ecc.) Che danno valore all'utente. Non preoccupato per gli interni; solo gli input e gli output del box (e forse dimensione, forma e colore) sono importanti qui.

Le specifiche sono elementi (capacità, caratteristiche, comportamenti, ecc.) Che abilitano quel valore per l'utente. Qui i box interni sono importanti, perché insieme alle interfacce esterne e alle caratteristiche sopra menzionate definiscono l'intero sistema.

— berad
fonte

è solo questa la tua opinione o puoi sostenerla in qualche modo?

— moscerino del

2

@gnat, ho pensato che fosse affrontato nella linea di apertura? Certo, questo è per esperienza e non sto rivendicando nient'altro - da quello che raccolgo questa è una domanda in qualche modo soggettiva in un forum piuttosto soggettivo, e questo post suggerisce che le domande dovrebbero essere il più obiettive possibile ma fa poca menzione delle risposte . Ma ne ho uno con il mio nome e tu ne hai molti di più, quindi sono aperto all'istruzione :-)

— Berlino,

0

Nella mia ricerca, ho trovato specifiche da utilizzare per brevetti e costruzione di case (come parte di un contratto).

La definizione di un requisito dal Webster's Unabridged Dictionary (3rd New Int'l Ed.) È:

a) qualcosa che è desiderato o necessario: necessità b) qualcosa richiesto o richiesto: una condizione necessaria o essenziale: una qualità, un corso o un tipo di formazione richiesti

Penso che quanto sopra mostra loro di essere chiaramente diversi. Immagino che potresti chiamare i requisiti di livello inferiore delle specifiche, ma penso che sia una perversione del termine imho requisito.

— LeWoody
fonte

0

In una precedente azienda che creava prodotti commerciali avevamo la seguente distinzione:

I requisiti sono ciò che il sistema deve fare. Possono essere di livello inferiore, requisiti dettagliati e possono essere funzionali o non funzionali.

Le specifiche sono quelle cose che fa il sistema come costruito in realtà. Ad esempio potresti avere un requisito secondo cui il sistema deve avere un comportamento X a -10 ° C. La specifica effettiva del sistema potrebbe essere che il sistema esegue X a -5 ° C; questo sarebbe nel foglio inviato ai potenziali clienti quando vogliono acquistare il sistema.

NB in questo caso la specifica non corrisponde al requisito.

— Royd
fonte

-1

Pensa, costruirai un grattacielo su una terra.

Ora devi considerare i Requisiti prima di iniziare, come ad esempio:

Ingegnere di architettura o design
Ingegnere del test del suolo
Team di test della pressione del vento
demolisher
scavatrice
Man Power
Fornitura d'acqua
Area di lavoro / riposo dei lavoratori
Abbastanza fondo
Gestione di progetto
Gestione della qualità
Sicurezza e controllo di sicurezza

Eccetera.

Ora i contenuti di cui sopra fanno parte dei Requisiti per costruire un grattacielo. Dal team di cui sopra, ottieni il risultato tecnico, che detengono come parte della professione.

Questo è esattamente ciò che sta accadendo nell'industria del software, un gruppo di professionisti coinvolti per fornire conoscenze per costruire le specifiche tecniche, come qualcuno che lavora alla progettazione dell'interfaccia utente, alla progettazione OO, alla progettazione di database, alla progettazione grafica, alla progettazione di test case, alla codifica, all'integrazione , team di distribuzione ecc.

Il precedente paragrafo farà parte del manuale, che è possibile chiamare le specifiche tecniche.

— Mohammed Hoq
fonte

1

Penso che tu stia confondendo i requisiti con le risorse ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

— Jay Elston,