Mi chiedo quale sarebbe il metodo formale e il più comunemente praticato per documentare le regole aziendali? Inoltre, come documentare le specifiche dell'interfaccia utente degli artefatti di sviluppo (ad esempio, documentare i campi dei moduli e il comportamento dei pulsanti sul modulo, sul testo delle informazioni, ecc.)
Per le regole aziendali penso che @Joppe abbia sottolineato l'UML che tutti stavamo pensando.
Use Case Diagrams offre un'eccellente panoramica di come gli attori / i ruoli interagiscono con il sistema e il sistema. Per caso d'uso complesso, ulteriori informazioni spiegate testualmente aiuteranno molto ( precondizioni , postcondizioni , dipendenze dalle precedenti esecuzioni UC , etc )
Ci sono diagrammi che forniscono anche grandi panoramiche dell'azienda a diversi livelli:
Solo un consiglio, assegna un codice a ciascun caso d'uso (cioè: UC-1 , UC-n ). Questi saranno utili in seguito, durante la documentazione dell'interfaccia utente.
Per la documentazione dell'interfaccia utente la pratica comune (in questi giorni) è quella di fare wireframes . Molto meglio delle schermate perché sembra più pulito e semplice. Ad esempio, dai un'occhiata a WireframeSketcher
I wireframe potrebbero non essere una documentazione sufficiente, quindi, per ogni schermata fare una breve introduzione e descrivere ogni pulsante. Inoltre, fai riferimento all'UC coinvolta nello schermo ( vedi ora perché i codici UC sono utili ). Ciò renderà la tua documentazione coerente.
Il punto di strumenti come Wireframesketcher è che fanno i prototipi interattivi. Perfetto per dare qualcosa di interattivo al cliente mentre stai ancora progettando o sviluppando.
Non dimenticare di documentare il piano di navigazione . Nav. Il piano non ha un diagramma UML, ma è possibile utilizzare Diagramma macchina di stato . Non è per quello che è stato fatto, ma ancora.
Infine, tieni a mente a chi ti stai rivolgendo.
Tecnico : puoi approfondire i dettagli e utilizzare i tecnicismi.
Non tecnico : evita gli aspetti tecnici (né relativi a languaje né a codice). Cerca di essere chiaro e semplice e usa gli stessi termini / parole utilizzati dal cliente. Pensa come se non avessi idea di programmazione.
La documentazione viene spesso eseguita in casi d'uso e altre forme di prosa. Inoltre può essere estremamente utile avere diagrammi UML e altre forme grafiche che ti offrono una panoramica su un livello superiore e sono facili da comprendere in un tempo più breve rispetto alla lettura di pagine e pagine.
E, ultimo ma non meno importante, la migliore documentazione sono i casi di test che eseguono le regole aziendali. In questo modo puoi modificare il codice e scoprire che stai violando una regola aziendale. Altrimenti la documentazione è sempre sotto il rischio di diventare obsoleta e obsoleta.
Probabilmente la forma più comune è Use Cases . Puoi integrarli con i mock-up e le descrizioni dello schermo.
Un libro che consiglierei è "Scrivere casi d'uso efficaci" di Alistair Cockburn. Descrive come è possibile scrivere casi d'uso a vari livelli di dettaglio, come evitare di cadere per l'approccio basato su "template" e semplicemente limitarsi a documentare i bit necessari e rilevanti.
Qualunque sia il metodo che usi, assicurati che possano essere mantenuti attivamente. Dovrebbero essere documenti viventi. Ospitare i documenti in un sistema di controllo delle versioni o in qualche tipo di sistema di gestione dei documenti come Sharepoint, può fare molto per mantenerli. Tenere traccia delle regole aziendali attraverso i documenti di parole allegati alle e-mail è un modo orribile per affrontare il problema, poiché porta a diverse versioni in giro.
Consiglio vivamente di separare rigorosamente le regole di business dalle specifiche di sistema solo facendo riferimento alle regole aziendali dal caso d'uso e dalla progettazione dell'interfaccia utente. La mia tecnica preferita è: - Avere un elenco di regole aziendali identificate in un foglio di calcolo. - Nella progettazione del sistema, utilizzare la specifica del caso, le storie degli utenti o qualsiasi altra cosa, basta specificare "L'utente inserisce le informazioni come specificato nella regola aziendale BR012", "Il sistema calcola l'importo totale come specificato nella regola aziendale BR510". Raccomando questo articolo link
Leggi altre domande sui tag documentation business-rules