システム要件の仕様と機能の仕様-別のドキュメント？
多くのソース（Wikipediaなど）では、システム要件仕様と機能仕様が2つの別個のエンティティーとして言及されています。しかし、ウィーガーズは彼の本の中でこう書いている：
ソフトウェア要件仕様は、機能仕様、製品仕様と呼ばれることもあります...
FSはSRSのシステム全体の機能だけを説明していると思ったので、これは私にとって非常に混乱します。この観点からすると、FSには、非機能要件と機能要件の両方、およびその他すべてが含まれます。
物事を構造化するにはさまざまな方法がありますが、これはその1つです。
システム要件仕様（SyRS）：これは、 system がどのように機能するかについての要件を列挙した高レベルのエンジニアリングドキュメントです。 notソフトウェアのみのドキュメントです。システムにハードウェアまたは複数のソフトウェアコンポーネントが含まれる場合は、それらも説明します。
ソフトウェア要件仕様（SwRS）：これは、単一のソフトウェアコンポーネントの要件の完全な説明です。
これら2つのドキュメントのどちらも「機能仕様」と呼ぶことができます。それはあなたが話していることの範囲に依存します。
[〜＃〜] update [〜＃〜]：通常、SyRSには、システム全体に適用される要件/機能仕様のみを含める必要があります。グリーンフィールドSyRSはシステムアーキテクチャを決定しません。それは設計ドキュメント用です。
設計ドキュメント（システムアーキテクチャドキュメント、SyADと呼びます）は、必要なソフトウェアコンポーネントとそれらが相互にどのようにインターフェースするかを決定します。
定義された各コンポーネントのSwRSは、個々のコンポーネントがどのように機能するかについてのより詳細な機能仕様になります。
たとえば、UIの一貫性を確保するために、一般的な要件をSyRSにバンドルすることは理にかなっています。
これは混乱する可能性がありますが、各ソフトウェアコンポーネントのテスト計画とテストケースは、適切な場所から適切な仕様を取得する必要があります。
DOORSなどの要件管理ツールを使用すると、要件ドキュメント間の相互リンク（および製品コンセプトから最終的な配信までのトレーサビリティ）が可能になります。
機能要件仕様はシステム設計について話しますか？
いいえ、それは設計ドキュメントで処理する必要があります。
すべてのアプリケーションに対して単一のシステム要件ドキュメントと個別のSRSが必要ですか？
はい、それは続行するための良い方法のように思えます。
また、機能要件は厳密に要件のみを扱い、設計は扱っていないことも前提としています
はい、2つは区別されますが、人々はしばしばそれらを混同します。
疑似コードの各行を機能要件として定義できますか？例：システムBは、システムAからの要求の受信時にemp idと名前をシステムCに渡す必要があります.
あなたが引用した例は確かにシステムレベルの機能要件のように聞こえます。 しないに注意してください。SyRSに「emp IDはGUIDの形式である必要があります」のようなものを含めてください。 SyRSにそのような技術的な詳細を含める唯一の理由は、システムに何らかの制約がある場合です（すべての着信または既存のemp IDがGUIDであるなど）。
これは、「設計V」（時には設計W）と呼ばれるシステムエンジニアリングへのアプローチから得られます。 詳細はWikipediaを参照 。ただし、「アジャイル」の世界では、この一部が忘れられます。
SRSとFSは確かに2つの別個のエンティティです。ソフトウェア要件仕様書は、システムの予想される動作を説明し、システムのさまざまな機能ユニットの概要を示す詳細な要件仕様を含む主要なドキュメントです一方、機能仕様は、システムの動作のより詳細な理解であり、ソフトウェア要件仕様文書からの入力を受け取る場合があります。機能仕様は、基本的なビルディングブロック、これらのビルド方法、動作を詳しく説明したものですそして、それはシステムからの必要な期待にどのように応えるか。