複雑なビジネスルールとロジックにどのように取り組むか？
私には協力するドメインの専門家がいますが、彼は口頭で多くの詳細を私に投げます。ビジネスロジックは複雑で、ビジネスルールは頻繁に変更されます。ビジネスプロセスは長く、マルチエンド/中間の待機状態です。対処すべきケースはたくさんあります（アカウント、製品、サブスクリプションには多くの状態があるため）。
それを処理する最良の方法は何ですか？ BPMNダイアグラムは、説明するのに十分なレベルではありません。文書化されたドキュメントは、書き込みと読み取りに時間がかかります。 UML状態図は非常にすぐに非常に複雑になる可能性があります。
何かアドバイスをいただければ幸いです。
私はユースケースとユーザーストーリーに焦点を当てます。それらをおそらくwikiに文書化し、それぞれにID（UC00001など）を与えることができます。次に、単体テストや統合テスト、あるいはその両方を作成したときに、それらに通知するユースケースでラベルを付けます。
次に、相互に排他的であるため両方に合格できない2つの単体テストに到達すると、それら2つのユースケースをドメインエキスパートに返却し、調整してもらいます。それが私がそれをすべてまっすぐに保つために考えることができる唯一の方法です。
それを分解する：
最初に一般的な概要を取得し、シンプルなバージョンの暫定的なデザインを作成します
次に、ビジネスロジックに沿って複雑さを追加し始めますが、変更を小さくし、予想される更新と互換性を保ちます（ただし、常に一貫性を保ちます）
（これはトップダウンのアプローチです）
ドメインエキスパートをシャットダウンするか、必要に応じて定期的に質問/コメントで彼を中断します。何をすべきかわからないなら、あなたは助けることができません
また、ビジネスルールは頻繁に変更するべきではありません。変更すると、スコープの問題が発生する可能性があります。それが修正できるかどうかを確認してください
非常に複雑なビジネスロジックとドメインエキスパートで作業した経験から、ドメインエキスパートの時間は非常に貴重なものになる傾向があり、小規模な企業ではなおさらです。
当然のことながら、彼にとっては無限の詳細と微妙なニュアンスを不満に思っています。それは彼にとっては当然のことですが、第二に、彼は非常に忙しい人である可能性が高いためです。これらのタイプの人々は自分自身を繰り返す必要はありません。
これは奇妙に聞こえるかもしれませんが、まともなデジタルボイスレコーダーはジャーナリストが持ち歩くようなものです。座って、ただ彼に脳を捨てさせてください。彼が話している間、メモを取ってくださいメインポイントだけを書き留めてください。
完了したら、一度に1つのポイントに取り組み、オーディオセクションを再生して、見逃したすべての詳細を要約します。あなたが聴覚障害者でない場合は、会話をテキストで口述することができます。または、オフィスに秘書または管理アシスタントが利用を許可されている場合は、会話をテキストドキュメントにコピーするよう依頼してください。
これは私の意見では最良の方法であり、ドメインエキスパートは、彼/彼女が録音されていることを知っているので、はるかに明確で説明的であることがわかります。実行する前に、彼/彼女がこれに慣れていることを確認してください。さらに、週末はあなたの短期記憶に大混乱をもたらします、あなたは月曜日にやって来て、ドメインエキスパートがすでに終わっているしつこい質問でドメインエキスパートをバグにするように強いる重要な情報を忘れます。
そうして初めて、生の情報を手に入れて、ユースケースとユーザーストーリーを策定することができます。
あなたは非常に複雑な仕事をしているように見え、それに値する敬意を持ってそれを扱う必要があります。あなたはそれを飼い猫だと思っている尾のそばにトラがいないと確信していますか？そのような間違いの結果はかなり予測可能です。
ドキュメントは複雑なドキュメントを必要とする非常に複雑な仕事であるため、しばらく時間がかかります。 UMLは、仕事が複雑で理解しにくいため、複雑で理解しづらくなります。他に証明されない限り、その仕事は大きな複雑な仕事として扱われる必要があります。
したがって、私のアドバイスは、プロジェクトマネージャーとビジネスアナリストの「雇用」から始まります。あなたが「それ」であれば、ソフトウェア開発者になる前に、コンパイラを片付け、上記の2つの仕事についての本を読み、それらの役割を果たす。
これは珍しいことではないと思います。要件収集におけるすべての文献は、ここで回答の資格を得ることができますが、もちろん他の場所でこれを見ることができます。
高レベルでは、私はこの方法で問題に取り組みます：
目前の問題を明確に特定します。
システムの目的を定義します。
これで、操作するスコープができました。主なビジネスプロセスを特定します。
スコープ内のビジネスプロセスごとに、入力、出力、アクター、およびビジネスルール（事前条件、事後条件、ルール、例外）を定義します。
BPMNを使用して、ビジネスの観点から重要なビジネスフローを文書化し、プロセスの関係を示す
この時点で、ビジネスの理解を文書化しました。それを確認し、問題を解決するためにソフトウェア設計でこの時点から続行します。
分析に費やされた時間は、それだけの価値があります。