Mappatura tra requisiti funzionali e moduli software

Relazione tra requisiti e moduli

La relazione tra requisiti e moduli non è in generale ovvia, quindi ti ritroverai sempre con molti a molti:

• è molto raro che un modulo implementa un singolo requisito. Di solito un modulo implementa diversi requisiti correlati.
• spesso ci sono alcuni requisiti generali (ad es. requisiti di sicurezza non funzionali o requisiti dell'interfaccia utente come ad esempio la disponibilità di un pulsante di aiuto) che dovrebbero essere implementati in molti se non in tutti i moduli.

Pertanto, avere uno schema altamente interconnesso non significa necessariamente che i requisiti siano imperfetti. Può anche suggerire che hai a che fare con un sistema complesso. O che hai identificato molti requisiti generali.

Come semplificare l'immagine?

Un primo passo per padroneggiare la complessità è decidere cosa vuoi rappresentare:

• cerchi di rappresentare come vengono implementati i requisiti nel sistema? In questo caso, puoi ridurre i collegamenti che mostrerai nel diagramma, limitando i collegamenti alle relazioni "è implementato in". Quindi se un requisito generale è implementato in un modulo di utilità che fornisce la funzionalità all'altro modulo, avresti un solo collegamento.
• vuoi mostrare come i moduli sono conformi ai requisiti dal punto di vista dell'utente? In questo caso non è possibile evitare collegamenti di tipo "offerti all'utente", che moltiplicheranno i collegamenti.

Un altro approccio consiste nel prevedere categorie di requisiti. Ad esempio:

• requisiti generali non funzionali (previsti in tutti i moduli)
• usa i requisiti del caso (requisiti transazionali, relativi a funzioni aziendali specifiche: questi sarebbero previsti in un modulo)
• requisiti dell'utilità (inclusi o estesi, usati in diversi casi d'uso diversi: ci si aspetterebbe questi in un modulo di utilità o in più moduli)
• requisiti dell'interfaccia utente (previsti in moduli che interagiscono con i moduli dell'interfaccia utente)

Come utilizzare questo diagramma per migliorare il sistema?

Quindi, in generale, alte interconnessioni non significano requisiti imperfetti.

Tuttavia, alcune teorie fondamentali sui sistemi, come ad esempio La scienza dell'artificiale di Herbert's Simon , suggeriscono che in un sistema strutturato ottimale, ci si aspetterebbe una maggiore interrelazione all'interno di un sottosistema piuttosto che tra sottosistemi.

Pertanto, se disegni solo "è implementato in" link e rimuovi tutti i requisiti generali (o meglio, prendi solo i requisiti transazionali del caso d'uso), allora dovresti venire di più ad una situazione come il diagramma a sinistra .

Con un diagramma semplificato / filtrato, un'elevata interconnessione potrebbe suggerire che i requisiti dei casi d'uso sono imperfetti (ancora troppo generici o troppo ambigui). O che il raggruppamento in moduli non fosse idealmente pensato.

Quindi, non pensarci in questi termini. Sono molteplici punti di vista che creano l'intera immagine che è molto importante altrimenti le cose vengono perse.

• BRD (documento relativo ai requisiti aziendali) viene prelevato dal cliente.
• Questi sono poi scritti per quantificare le esigenze del cliente da una comprensione aziendale
• I requisiti tecnici vengono scritti per tradurre le esigenze aziendali in termini tecnici che possono essere programmati. Questi vengono poi aggiunti alla RTM (Requirements Traceability Matrix)
• I casi d'uso sono scritti per esemplificare gli scenari e i flussi di lavoro che sono destinati al completamento del prodotto.
• RTM / Use Case vengono forniti all'architettura per lavorare su Arch Design
• RTM / Use Cases e Arch Design sono forniti allo sviluppo per lavorare sulla progettazione dettagliata

Questo è il punto in cui siamo nella tua domanda. La progettazione dettagliata dovrebbe aderire al 100% alla progettazione dell'arco, che dovrebbe rispettare i requisiti tecnici che dovrebbero rispettare i requisiti aziendali. Questo può essere un rapporto molti a molti in quanto l'implementazione tecnica può essere semplice o complessa, ma deve fare ciò che è tecnicamente corretto, mentre il business deve articolarsi in modo corretto. Quindi il business potrebbe avere 400 cose che sono realizzate da 30 moduli dove potrebbe anche essere che 40 moduli realizzino 9 cose di business. Quelle prospettive devono essere mantenute, ecco perché a volte è complessa e altre volte è davvero semplice.

• Il test consiste nel verificare l'approccio tecnico e di business che richiederà diversi approcci ai test. L'ingegneria di prova corretta sta ricostruendo l'originale e la finale per fornire l'analisi completa dell'immagine del prodotto finale rispetto all'intenzione originale. Più è complesso, più esperto deve essere il tester. Questo è anche il motivo per cui è un lavoro completamente diverso in quanto è un modo di pensare completamente diverso.

Detto questo è importante che i tuoi moduli tecnici aderiscano alle parti come scritte indipendentemente dal numero di relazioni semplici o complesse, così come è altrettanto importante che anche le altre prospettive e i ruoli facciano lo stesso. I "disaccordi" o "multi-allineamenti" sono lì apposta per garantire il pieno successo dell'applicazione come quelli che puntano a possibili buchi e a ripensare cose che altrimenti potrebbero essere facilmente accettate.