システム開発を行う場合，ざっくり企画，要件定義，設計，実装，テスト，ローンチというプロセスを経ると思いますが，要件定義と設計の間に大きなギャップがあることに気づくことがあります．
- 要件一覧は出てるけどあまり構造化されてないなぁ
- 将来的に変化が大きい部分とほとんど変化しない部分の境界が明確じゃないなぁ
- ビジネスルール，システムルール，原理原則を見出したいなぁ
などなど．
それぞれに対する対策を要件定義に含める場合もあれば設計で実施する場合もあり，開発組織によってまちまちだとは思いますが，何れにせよ上記のようなイシューに対してどういったアクションを取ればよいのか，明確でないことが多いです．
筆者の経験では，ドメインモデル，プロセスモデル，ルールの３つを思考してみるとしっくり来ることが多かったです．
全部が揃っていれば良いというわけでもありませんし，全てが必要というわけでもありません．どの順番で考えればよいということでもなく，システム化対象となるものによって必要となるモデルはまちまちです．しかしながら，将来のニーズを取り込める土台を作り，システムの賞味期限を永らえるにあたって有効だったという経験則ではあります．
ドメインモデル
筆者は昔からドメインモデルと同等のアプローチを取ることが多かったので，最近の動向にはワクワクしながら，いろいろなケースを拝見しては共感したり学びに変えたりしています．
ドメインモデルは各オブジェクトの存在や意味，オブジェクト間の関係性を明確化し，構造化することに優れており，事象の原理原則をあぶり出すのに有効な手法でありつつ，一方でIT，非IT限らず広く共有できる点でも強力なツールだと考えています．
最近は他の場で多く語られている分野ですので，ここでは割愛します．
プロセスモデル
プロセスモデルの描き方として有名なのはBPMLであり，多くの製品が世の中で使われていると思いますが，これはアクターのアクションに着目したものであるため，要件の確認においてはかなりの効力を発揮します．
一方で，下記の問題により要件漏れが発生するリスクが高いと考えています
- あらゆるケースを同時に表現しきることが難しいため，ケースを網羅するためには複数枚のモデル図が必要となる
- アクターとアクションの組み合わせが厳密ではなく，多様な組み合わせが想定できるケースが多いため，モデルとしての堅牢性が低い
- プロセスが存在している目的がわかりにくい（複数の目的を持っていることもある）ため，設計の際にはさらなる分解が必要
短い業務プロセスであればBPMSを活用した自動化も図れると思いますが，長い業務プロセスに対しては可視化に留めるのが懸命かもしれません．
プロセスが長い場合には，主要なオブジェクトの状態遷移を描いてみるのが意外とおすすめです．
かなり抽象的なので一定の慣れは必要となりますが，オブジェクトの状態がデータの状態に対応することが多いため，実装やテストにおいて想定すべきケースの洗い出しに便利です．
また，状態遷移はアクターからは独立しているため，
- 将来的にビジネスニーズが変化した際にも，アクターが変わるだけで状態遷移は変わらない
- アクターが変わるとビジネスがどう変化するかなど，水平思考的にビジネス展開の幅が想像できる
- 状態遷移に手が入る場合にはビジネスの構造自体に変化がある
といった副次的な効果も期待できるため，要件定義の効率化にも寄与すると考えています．
一方で，複数オブジェクトの状態変化が同期する場合（ほとんどそうですが）は状態管理が複雑化するため，注意が必要です．あくまでも主要なオブジェクトへの適用にとどめておきたいところです．
ルール
一時期，ルールエンジンの登場によって注目され，最近ではRPA技術の発展の文脈でも注目されています．
主に業務の自動化に資するものとして期待されている考え方ですが，自動化はともかくとして，パラメータとアルゴリズムのあぶり出しと分離に一役を担う存在と言えます．
ビジネスルールは現実に発生する事象をベースに説明されるために曖昧なことが多く，汎用的に構造化すること自体の難易度が非常に高いため，またビジネスの現場との共通理解を優先し，一般的には要件をやや直接的に実装することが多いと思いますが，抽象化して構造的に捉えることで汎用性が高まり，多少のニーズの変更に対して堅牢なシステムを構築することが可能となります．
課題はあります．
抽象度，実装難易度，エンハンスコストがそれぞれ相関することになり，技術組織のレベルによってルールの抽象度をコントロールする必要があると筆者は考えます．
抽象度が上がると，数多ある高度なアルゴリズムおよびそれらの組み合わせの適用が可能になってくることが多くなりますが，実装難易度も相応に上がり，エンハンスの機会自体は減少しますがエンハンスに当たる人財は高度なスキルが要求されることもあります．
技術組織の現状のレベルや今後の育成計画，採用の難易度，事業全体の組織のバランス等を加味して方針を決める必要があると思っています．
最後に
とはいえ，モデル化の方法は多様であり，またシステム化の対象によって進め方も様々です．ここではあくまで考え方の一例を紹介させていただきました．
ITにおける実装業務を経験されている読者であれば思考の中で実施していることではあると思うので，まずは簡単なプロジェクトから可視化を始めてみて，その効果や課題を体感した上で各々の技術組織にあったやり方を模索していってください．