英語のような自然言語で明確な仕様を記述できますか？

自然言語の形式張らない性質のために、曖昧さのない完全なソフトウェア仕様を英語で書くことはおそらく不可能だと私には思えます。したがって、本当に明確な仕様には、正式に指定された言語で書かれたコードを含める必要があります。

これは既知の結果ですか、それとも何か不足していますか？

弁護士が曖昧さを避けるためにいつもやったことではありませんか？

結果は、彼らが最も不自然な方法で書く、彼らの論文を読むことはこれまで以上に困難であり、それにもかかわらず、常に不整合とあいまいさが存在します。

そうです、曖昧さのない完全なソフトウェア仕様を作成することはできませんが、正式な指定言語を実装することはできません。

これは、コードを文書化する理由でもあります。なぜなら、頭の中で読むのが難しい場合があるからです。

別のコードでコードを文書化しても意味がありません。

無理だよ？それが望ましいかどうか最初に尋ねましょう。それが不可能だと私たちが同意し、そこにまだ有用なソフトウェアがたくさんある場合、明確な仕様の目標は学術的であるように見えます。

私は、仕様とソフトウェアの両方にとって、すべてが完璧で明確であることを証明することは不可能だと思います。

問題の大きさによると思います。問題が十分に小さく、本質的に数学であり、おそらく他に欠けている基準がいくつかある場合は、機能する仕様を作成することが可能だと思います。

問題が大きくなればなるほど、聴衆が広くなるほど、それを行うことは難しくなります。

しかし、アビオニクスやその他の複雑な問題は、大きな問題を解決するために「十分に良い」仕様を英語で書くことが可能であることを示唆しています。

まあ..問題の完全に明確な仕様は、実際のコード自体です:)

これは既知の問題であり、特別なミッションクリティカルなシステムでは、明確な仕様を正式な（プログラミング）言語で記述し、それを仕様に示されていると思われるコードに変換する必要があります。これは非常に狭い分野です。開発者の99.999％はこのようなタスクを実行する必要はありませんが、交通制御/鉄道システムのためにこれを行った人と一度話をしました。

私はW3Cのフォロワーで、仕様に基づいて記事を書く傾向があります。私の経験によると、サンプルコードを書かずに仕様を読むことは、頭痛の種に過ぎません。

私は完全に同意し、主な理由は、開発者がコードを読み、理解する傾向があることだと思います。数式のない数学の紙を想像してみてください。

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

または：

result = (x + y) / b

どちらが短いですか？どちらがより読みやすいですか？どちらがそれをより理解するでしょうか？

仕様についても同様です。多くの場合、技術的な部分にたどり着くときに、1行のコードを記述することで、説明の長い段落を明確にすることができます。

明確な仕様を記述できる正式な言語があるとします。次に、英語のサブセットへの全単射マッピングが必要であることを提案します。したがって、このサブセットに固執する場合は、明確な仕様を記述できるはずです。

しかし、何か面白いことをするのに十分表現力のある正式な言語は、矛盾がないわけではありません（ゲーデルの不完全性）。

人々があいまいで不正確であるため、仕様はあいまいで不正確です。完璧な人を見つければ、おそらく完璧な仕様を得ることができます。

英語、スワヒリ語、サンスクリット語、バビロニア語でも違いはありません。

あいまいさは、実際にはこのコンテキストの強みです。

理由を説明するには、聞かせてのは、瞬間のために想定しているプログラムで解決することができるいずれかの問題が完全かつ明確に表現することができるように、完全に明白な方法で英語を使用することが可能。この英語のバリアントを使用し、私たちの説明が完全かつ明確に書かれたプログラムを実際に説明している場合、ターゲットのプログラミング言語への自動翻訳を実行することが可能でなければならないということは論理的に従います-言い換えれば、私たちが考えた英語は、実際にはプログラミング言語そのものです。

設計ドキュメント（特に機能設計）を読む人は、実際にはこのレベルの詳細を望んでいません。C++、Java、または曖昧でない英語でプログラムのソースを読むことは、平均的な非プログラマーの頭をはるかに上回ります。これが自然言語の出番です。仕様の作成者は、詳細スケールでいずれかの方法でスライドしたり、無関係な実装の詳細をサブテキストに移動したり、完全に未指定のままにしたりできます。正確な定義を提供していなくても、自然言語は意味を比較的明確に伝えるためのデバイスでいっぱいです（これは自動翻訳を困難にするものの一部です）。

したがって、目標は通常、完全で正しい明確な仕様ではありません。目標は、作成しようとしているものを人間に明確に示す仕様を作成することです。

正確で明確である必要があり、とにかく技術が進歩しているときはいつでも、疑似コードは自然言語や厳密な形式のものよりも価値があることがよくあります-未指定の機能/プロセスを呼び出すことで無関係な詳細を省くことができますが、構造は明確です。

人間が読むためのドキュメントが書かれていることを除いて、あなたは何も見逃していません。簡潔なテキストは読みにくいため（=人間向けではない）、多少のあいまいさが予想され、歓迎されます。

形式言語のドキュメントをさらに別の形式言語で指定することは、鶏と卵の問題のようなものです。

正式な仕様が本当に必要な場合は、モデルをチェックする正式な方法があります。これは活発で非常に興味深い研究分野ですが、ここでの「ユーザー」とは、人間ではなく機械です。

（私の指摘のいくつかはすでに他の回答でほのめかされていますが、私はこれをコメントではなく回答に値するように十分に異なる視点を提供していると感じています。）

仕様を本当に完全に明確にすることができるかどうかの問題に取り組む前に、少なくともあなたが求めているレベルで、明確にする必要があるかどうかの問題に取り組む必要があります。

小規模から中規模のプロジェクトに取り組んでいるプログラムマネージャー、またはより大きなプロジェクトの一部としての機能の観点から、これに取り組みましょう。通常、このようなプロジェクト用に作成される仕様には、機能（またはPM）仕様と設計（またはDev）仕様の2つの異なるタイプがあります。

• 機能仕様には、プロジェクトまたは機能が何をすべきかを、多くの場合顧客の視点から説明するという役割があります。一般的に、これがどのように行われるべきかを記述すべきではありません。プロジェクトのタイプに応じて、顧客は外部向けAPIがどのように見えるかを気にするかもしれませんが、クラスAがクラスBから継承するのか、インターフェースCを実装するのかを気にしますか？彼はすべきではない。また、機能仕様も同様です。これはすでに1つのレベルのあいまいさ、つまり技術設計のあいまいさをもたらしています。
• 設計仕様には、機能またはプロジェクトの設計者または技術設計者の観点から、機能要件がどのように満たされるかを記述する役割があります。これは、技術設計の高レベルのあいまいさを解決することを目的としています。これには、プロジェクトのスコープと規模に応じて、クラスの構造、継承、場合によっては個々の関数やメソッドなど、ソリューションのアーキテクチャなど、機能仕様に必要のない詳細が含まれます。アーキテクトは、一時変数と呼ばれるもの、または内部データ型にリストと配列のどちらを使用するかを気にしますか？彼女が開発者を信頼しているとすれば、彼女は信用すべきではなく、設計仕様も信用すべきではありません。これにより、2番目のレベルのあいまいさが発生します。それは実装です。

一般に、これらの実装レベルの詳細は、正式な文書内に捕捉されていない、むしろ、文書自体のコメントを含む、コードで、それ自体を。このレベルのあいまいさにより、優れた開発者は自分のスキルを使用して、優れた個々の開発者の特徴である詳細指向の技術的決定を行うことができます。このため、仕様のあいまいさは実際には良いことだと言うのをためらうことはありません。これにより、開発者は自分の仕事を実行できるようになり、単なる「コードモンキー」よりも高くなります。

ただし、これは、ドキュメント全体にあいまいさが存在する必要があるということではありません。高いレベルでは、顧客とのインターフェースについて曖昧さはありません。機能が公開APIを備えている場合は、厳密に定義する必要があります。システムが仕事をするために日付を渡す必要がある場合、この日付はローカルタイムゾーンまたはUTCのどちらにする必要がありますか？どのようなフォーマットが必要ですか？ミリ秒まで正確である必要がありますか、それとも分で問題ありませんか？

自然言語を使用して明確な仕様を作成できるかどうかという問題に戻ると、このレベルの明快さを捉えるのはあまり得意ではありません。私はそれが特定の限られた状況で行われるのを見てきましたが、それらはおそらく私たちが普遍的に適用することができないユニークな例外です。ほとんどの場合、あいまいさは、専門用語、図、または疑似コードの助けを借りて解決されます。そのようなツールの助けを借り始めると、自然言語は唯一の記述子ではなくなります。これらのツールは、完全に機能的に明確な仕様でさえもより明確にすることができるので、私はそのような事業は試みられるべきではないと言ってもいいでしょう。

とは言っても、自然言語は一般にこれらのツールによって補完されて機能的に明確になるため、自然な言語だけではすべての場合に明確な仕様を作成するには十分ではないというのが私の専門家の意見です。

自然言語を比較的明確にすることができますが、非常に困難です。

法律専門家は、言語をできるだけ明確にする必要があります。法律がどのように適用されるかについては多くのことを解釈する可能性がありますが、その言葉が意味することはそうであってはなりません。

これは法律家の発明につながります。あなたはどこまで行きたいですか？

オープングループによる多くの仕様があります。ISO、IETF、ITUは、非常に競争の激しい企業が相互運用を成功させるのに十分なほど明確です。数百万ドルがかかっている契約または法律の基礎となる仕様は多数あります。

したがって、仕様は「完全」ではない可能性があります。しかし、それは人間が完璧ではないからです。たとえば、HTTPが「Referer」ヘッダーを使用する必要があることは明白です。正しいスペルは実際には「Referrer」です。

英語は曖昧さをなくすことができますが、人間は間違いを犯す可能性があります。

さらに、確定されていない詳細や将来更新が必要になる可能性がある詳細については、意図的にあいまいであることも役立ちます。たとえば、仕様では、md5、sha1、crc32などを具体的に指定するのではなく、「ハッシュ」を指定する場合があります。

正解は否定的だと思います。次の質問を区別する必要があります。

1. 曖昧さを含まない自然言語でソフトウェア仕様を書くことは可能ですか？
2. 曖昧さを含まない自然言語でソフトウェアを書くことは可能ですか？

最初の質問と2番目の質問の違いは、関連する詳細のレベル、必要な解釈の量、およびソフトウェアまたはソフトウェア仕様を作成する目的で自然言語での文の構築に課される規則に関係します。

2番目の質問への答えは肯定です。文の構成と意味について合意されたルールを備えた、自然言語の適切に制約されたサブセットが与えられれば、コードは文法的な英語の文で書くことができます。たとえば、次の言語では、割り当てステートメントを明確に記述できます。

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

つまり、各手続きを記述することにより、正式なプログラミング言語で記述されたコードを体系的に自然言語に変換できます。一方、ソフトウェア仕様はしばしば解釈を必要とします。したがって、ソフトウェア仕様を明確に指定できるかどうかは、仕様に含まれる詳細レベルに依存します。ただし、仕様範囲の選択されたドメインが与えられ、このドメインに対する特定の操作が選択されると、同様の変換プロセスを実行できます。例えば：

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

文はどこX、Y、Z仕様書の序文で述べた項目のみが含まれており、適切に正式に書かれており、合意された自然言語のサブセットです。あいまいさは、仕様の実装方法に関係しますが、これは予想されます。

番号

計算の明確な仕様はコンピュータプログラムです。