Come affrontare regole e regole aziendali complesse?

Mi concentrerei su casi d'uso e storie degli utenti. Potrei documentarli, magari in un wiki, e dare a ognuno un ID (come UC00001). Poi, quando ho scritto test unitari e / o test di integrazione, li etichettavo con il caso d'uso che informavano.

Poi, quando arriverò a due test unitari che non possono entrambi passare perché si escludono a vicenda, rinvierei questi due casi di utilizzo all'esperto del dominio e lo farei riconciliare. Questo è l'unico modo in cui posso pensare di mantenere tutto dritto.

scomposizione:

1. ottenere prima una struttura generale e creare un progetto preliminare della versione semplice

2. quindi inizia ad aggiungere complessità in linea con la logica aziendale, ma tieni le modifiche piccole e compatibili con gli aggiornamenti previsti (ma mantieni sempre la coerenza)

(questo è un approccio dall'alto verso il basso)

chiudi l'esperto del dominio e / o interrompilo regolarmente con domande / commenti se necessario. non puoi aiutare se non sai cosa dovrebbe essere fatto

e le regole aziendali non dovrebbero cambiare spesso, è probabile che ci sia un problema di ambito. vedi se può essere riparato

La mia esperienza con la logica aziendale estremamente complessa e un esperto di dominio è che il tempo dell'esperto di domini tende ad essere estremamente prezioso, ancor più in una società di piccole dimensioni.

Certamente ti sferrerà innumerevoli dettagli e sfumature perché per lui è naturale, e in secondo luogo perché è probabilmente una persona estremamente impegnata. A questi tipi di persone non piace dover ripetere se stessi.

So che sembra strano, ma prendi un decente registratore digitale come il tipo che un giornalista potrebbe portare con sé. Siediti e lascia che sia lui a scaricare il cervello. Mentre sta parlando prende appunti, ma annota solo i Punti principali .

Quando hai finito, affronta un singolo punto alla volta e ripeti le sezioni audio per ricapitolare tutti i dettagli che hai perso. Se non sei una persona auditiva puoi dettare la conversazione in testo o se il tuo ufficio ha una segretaria o un'assistente amministrativa che sei autorizzato a utilizzare, quindi chiedi a lei di copiare la conversazione in un documento testuale per te.

Questo è il modo migliore secondo me e scoprirai che l'esperto di dominio sarà molto più chiaro e descrittivo sapendo di essere registrato, ma assicurati che lui / lei sia a suo agio prima di te. Inoltre i fine settimana sconvolgeranno la tua memoria a breve termine, entrerai lunedì e dimenticheresti le informazioni critiche che ti obbligano a mettere a bug l'esperto di dominio con domande fastidiose che ha già finito.

Solo quando hai le informazioni non elaborate puoi formulare casi d'uso e storie degli utenti.

Sembra che tu abbia un compito molto complesso e devi trattarlo con il rispetto che merita. Sei sicuro di non avere una tigre per la coda che la pensa come un gatto domestico. L'esito di un tale errore è abbastanza prevedibile.

La documentazione richiederà un po 'di tempo perché è un lavoro complesso e complesso che richiede documenti complessi. L'UML diventa complesso e difficile da capire perché il lavoro è complesso e difficile da comprendere. Il lavoro deve essere trattato come un grande lavoro complesso, fino a prova contraria.

Quindi il mio consiglio è iniziare con "impiegare" un Project Manager e un Business Analyst. Se sei "it", metti da parte il compilatore e leggi un libro sui due precedenti lavori ed esegui quei ruoli, prima di diventare uno sviluppatore di software.

Penso che non sia insolito. Tutta la litratura nella raccolta dei requisiti può qualificarsi per una risposta qui, ma è possibile vederla altrove, naturalmente.

A un livello elevato, vorrei affrontare il problema in questo modo:

1. Identifica chiaramente il problema.

2. Definisci l'obiettivo del sistema.

3. Ora hai un ambito su cui lavorare. Identifica i principali processi di business.

4. Per ogni processo aziendale nell'ambito, definire: input, output, attori e regole aziendali (pre condizioni, condizioni post, regole, eccezioni)

5. Utilizza BPMN per documentare il flusso aziendale essenziale da una prospettiva di business per mostrare come i processi si riferiscono

A questo punto, hai documentato la tua comprensione del business. Confermalo e procedi da questo punto con il tuo software design per risolvere il problema.

Il tempo speso per l'analisi è valsa la pena.