要求仕様を関数型プログラミングの述語ロジックに変換することは一般的な方法ですか？

最近、Haskellで実装されている小さなプロジェクトに取り組むよう割り当てられました。オブジェクト指向/命令的な背景から来て、コーディングの前に要件/ユーザーストーリーをユースケースとシーケンス図に変換することに慣れています。

しかし、私が割り当てられているHaskellプロジェクトでは、チームはユーザーの要件を述語論理命題/ステートメントに変換することを好みます。セーフティクリティカルなシステムやソフトウェアエンジニアリングの正式な方法でロジックが使用されていることは知っていましたが、日常のプログラミングではそれほどではありませんでした。これはFPレルムで一般的な方法ですか？これについてどこでもっと知ることができますか？

要件を「モデル化」し、述語から「関数」を導き、関数が操作するために必要な型仕様を書き留めるのは自然な方法のようです。しかし、それは実際にどのように行われる/推奨されるのですか、それとも私のチームに固有のものですか？

（ここでこの質問をする前に徹底的に検索してみました。「関数型プログラミングの要件仕様」（および異なるキーワードの同義語と組み合わせ）を検索しても、意味のあるものは何もありません。）

関数型プログラミングに限らず、プロジェクトの目標との関連性が高いと言えます。述語ロジック（高次ロジック）を使用することで、要件で使用されるロジックの証明を作成できます。ロジックを関数型言語に変換する方がおそらく簡単です。その後、実証済みの関数型言語の実装を手続き型言語に変換して、実装のある種の実証済みの方法を取得することもできます。

プログラムを証明できれば、テストする必要はありません。プログラムが1000回のテストに合格したとしても、それはまだ証明されていません。もちろん、証明を作成するのは簡単ではないので、代わりにテストを作成します。

また、定理証明者であるisabelle / holを検索することもできます。

これは、関数型プログラミングを処理する1つの方法です。「昔」のフローチャートやデータフロー図から外れる傾向があります。オブジェクトの観点から考えるのではなく、関数型プログラミングは実行する必要のあるアクションに焦点を合わせる傾向があります。データは偶発的なものになり、あなたがしようとしていることを保持するために運ばれる綿毛のビットです。