Sulla progettazione del software, di solito il documento chiave è l'SDD, il Documento di progettazione software , che descrive in dettaglio come funziona il software, come sarebbe finito (ad esempio nel tempo presente: il sistema HA ..., utilizza...). Dal momento che il firmware è solo un tipo di software, presumo che un FDD sarebbe solo un SDD, con caratteristiche specifiche relative al firmware.
Troverai molte parole senza senso su come strutturare il tuo documento. Penso solo a questo: un sistema è un insieme di parti interconnesse (Von Bertalanffy et.al.). Quindi, è necessario descrivere il sistema software in due parti: il sistema (statica) e le interrelazioni (dinamica). Google per i modelli SDD e vedrai che è la struttura generica. Quindi, avrai un'introduzione, la sezione statica, la sezione dinamica e una parte conclusiva, che prenderebbero in considerazione le conseguenze del progetto.
Non dimenticare che lo scopo non è quello di fornire un documento, ma di pensare effettivamente (e consentire ad altri di pensare) in modo sistematico sui dettagli dell'implementazione .
L'ultimo SDD che ho scritto ha risposto a una serie di requisiti del cliente (sì, i sistemi hanno uno scopo!). Quindi, il documento aveva quasi questa struttura:
- Un'introduzione che descrive il software e il suo contesto, breve, un abstract. Cioè, che cos'è questo software? quale funzione svolge? per quali obiettivi? riferimenti alla documentazione (o contenuto effettivo, se il progetto è di piccole dimensioni), dove si parla del progetto, quali squadre partecipano, i loro ruoli, ecc. Una persona che legge questo documento dovrebbe conoscere il progetto o avere un modo per conoscerne il dettagli. Nel nostro caso, i requisiti del software erano già definiti, quindi i riferimenti sono stati inclusi.
- La metodologia di progettazione del software è stata eseguita e come è implementata. Nel mio caso, si tratta di un progetto di ricerca, sono state fatte ricerche sui domini teorici e che è stato utilizzato per utilizzare i casi, che hanno definito la struttura statica del sistema, componenti, test, blahblah. Importante per descrivere gli strumenti (ad esempio UML, Agile, ecc.). Presumo che tu abbia bisogno di includere funzionalità specifiche per l'hardware, i circuiti, perché e come.
- Innanzitutto, ciò che chiamo la sezione statica : il sistema, i suoi componenti (sottosistemi, sotto-canali ...), le interfacce, la struttura, l'implementazione, ecc. Personalmente, ritengo che sia molto importante descrivere nella parte 2. i casi d'uso (ad esempio una persona preme un pulsante e una luce è attivata), il che aiuterebbe a definire il sistema e i suoi sottosistemi (ad esempio, abbiamo bisogno di un pulsante, un diodo luminoso, una batteria). I test possono essere considerati componenti, in casi specifici, perché agiscono più volte come implementazioni di riferimento. Nei sistemi che gestiscono i database, le strutture dei dati devono essere incluse in una sezione adeguata o in un intero capitolo, se necessario. Nel tuo caso, dovresti prestare attenzione a tutte le caratteristiche statiche del tuo sistema: componenti, specifiche, alternative, ecc. Le interfacce sono un elemento chiave, poiché determinano le interazioni tra le parti.
- In secondo luogo, la sezione dinamica : le interazioni tra le parti (che determinano le relazioni). Seguendo l'esempio, qui dirai "le parti sono collegate usando cavi come questo, poiché il pulsante consente il passaggio di corrente, quindi la corrente scorre all'interno dei cavi A e B, e il LED è soggetto a una differenza di potenziali che lo inducono ad emettere luce e fa scaricare la batteria alla velocità X ".
- Quindi, sentiti libero, secondo i tuoi criteri personali, di inserire i dettagli che consideri importanti per chiarire. Nel nostro sistema a LED a batteria pulsante, potremmo introdurre l'impatto di avere un circuito così fragile esposto, quindi perché una scatola lo racchiude; con quale frequenza il pulsante deve essere modificato a causa del rischio di errore, una raccomandazione per includere un misuratore di livello della batteria, l'impatto economico (costoso, ma a buon mercato a lungo termine) e come sarebbe connesso, ecc.
Sentiti libero di guardare altri modelli e includere parti che ritieni importanti, ma all'interno della struttura definita in precedenza.