Raffinamento dei requisiti tra due livelli di specifica

3

Attualmente sto lavorando alla definizione dell'architettura di documentazione di un sistema, dalle esigenze dei clienti ai requisiti software / hardware. Incontro un grosso problema con il livello di perfezionamento dei requisiti.

L'architettura classica è: PTS - > SSS - > SSDD - > SRS / HRS con PTS: Specifiche tecniche Purshaser SSS: Specifiche del sistema fornitore SSDD: descrizione del design del segmento di sistema SRS / HRS: specifica dei requisiti hardware / software.

I requisiti di PTS vengono rielaborati in SSS, questo documento esprime solo le esigenze (nessun requisito di progettazione è definito a questo livello). Quindi, la progettazione del sistema è descritta in SSDD: allochiamo i requisiti dall'SSS alle funzioni dal progetto e le funzioni vengono quindi assegnate al componente (Software o hardware) (siamo ancora al livello SSDD). Infine, per ogni componente, scriviamo uno SRS o un HRS. I requisiti in SRS o HRS sono il raffinamento dei requisiti da SSS (e la matrice di tracciabilità viene fatta tra questi due livelli).

Il mio problema è il seguente:

Il nostro sistema è complesso e alcuni dei requisiti dell'SSS devono essere affinati due volte per essere al livello giusto nell'SRS (significa che le persone del software possono comprendere il requisito per effettuare la codifica). Ma con questa architettura di documento, posso solo perfezionare una volta soddisfatti i requisiti dell'SSS. Il secondo problema è che solo una parte dei requisiti dell'SSS deve essere ridefinita due volte. L'altra parte richiede solo un perfezionamento.

Nell'immagine sottostante, le caselle verdi sono requisiti al livello giusto per SRS o HRS. Le scatole viola sono requisiti intermedi che non possono essere inclusi in SSS poiché sono requisiti di progettazione. Dove posso inserire questi requisiti viola ??

C'è qualcuno che ha già riscontrato questo problema? Devo scrivere due documenti a livello SRS? Devo includere i requisiti intermedi in SSDD? Devo includere i due livelli di perfezionamento (viola e verde) nello stesso documento SRS (non è sicuro che sia possibile dal momento che uno SRS è solo per un componente) ???

Grazie per il tuo aiuto e la tua esperienza; -)

    
posta user107149 07.11.2013 - 18:47
fonte

3 risposte

1

Lo scopo del perfezionamento delle specifiche è duplice:

  • Traduci requisiti di livello superiore a qualcosa utilizzabile dagli sviluppatori: ad esempio, da voglio una "Google Maps" con immagini spaziali a La navicella deve seguire un'orbita polare a un gruppo di attrezzature - sensori e attuatori - e un ciclo di controllo implementato da software che coinvolge quaternioni e alcuni sistemi operativi in tempo reale.

  • Fornisci un modo per verificare che ogni esigenza del cliente sia stata implementata, attraverso la tracciabilità.

Pertanto, è sufficiente chiarire se Req 3.1 è interamente implementato da Req 4.1, in modo che lo sviluppatore si concentri su Req 4.1 (e inserirò Req 3.1 in SSS) o debba implementare sia Req 3.1 che Req 4.1 (e inserisco Req 3.1 in SRS).

    
risposta data 07.01.2014 - 09:34
fonte
0

Poiché la domanda è vaga, risponderò in 2 modi.

1) Supponendo che il tuo sistema abbia solo 1 elemento di configurazione, motivo per cui tale documento sembra mancare nella tua descrizione precedente, quindi stai semplicemente mappando i requisiti SSS ai documenti hardware e software. In tal caso, non ci sono requisiti "viola". Le persone che scrivono SRS / HRS sono responsabili della trasformazione del requisito SSS (possibilmente utilizzando l'SSDD e qualsiasi DID come riferimento, che potrebbe essere il luogo in cui i requisiti "viola" provengono) e trasformando tali requisiti SSS e derivati nell'SRS appropriato / Requisito HRS.

2) Se il sistema ha più elementi di configurazione, i requisiti SSS vengono mappati sul documento delle specifiche di prestazione "Elemento di configurazione". Questo documento è dove i tuoi requisiti "viola" vanno insieme a reinterpretazioni specifiche dei moduli dei requisiti SSS mappati su di esso (possibilmente ancora usando SSDD / DID come riferimento). Quindi quel documento viene utilizzato per mappare l'hardware e il software che vengono poi utilizzati per creare un SRS / HRS separato. Sospetto che questo sia quello che stai cercando di fare.

    
risposta data 07.11.2013 - 20:07
fonte
0

Se avessi una specifica che diceva 'abbiamo bisogno di una portaerei con una bandiera', sarebbe ovviamente folle dividere il sistema in queste due parti, e quindi specificare il vettore e la bandiera allo stesso livello di dettaglio .

La maggior parte di tali standard di sviluppo formale lo riconosce e ha un modo di personalizzare il livello di scomposizione e tracciabilità a qualcosa che ha più senso dal punto di vista contestuale. Il problema è che questo tende a essere trattato come un caso speciale avanzato che si impara a fare correttamente qualche volta dopo aver specificato e consegnato la terza portaerei.

C'è molto da chiedere a un fornitore di bandiere.

Ho il sospetto che il problema sia che gli elementi elencati nell'SSS dovrebbero essere quelli che hanno dimensioni appropriate per essere specificati nel modo standard. Se quella divisione è sbagliata, dovrebbe essere cambiata in modo che sia corretta. Speriamo che questo non abbia implicazioni contrattuali.

    
risposta data 08.03.2014 - 13:47
fonte

Leggi altre domande sui tag