無効になっている自動更新やスリープタイマーなどのオペレーティングシステム構成パラメーターをソフトウェア仕様の一部にする必要がありますか？
アプリケーションは、ロックダウンされたオペレーティングシステムで実行する必要があります。品質と規制の問題により、すべての更新は防止またはブロックされます。したがって、私たちの配備には、事前設定されたオペレーティングシステムが含まれています。 OSを変更するには、管理者の資格情報を使用する必要があります。
一部のチームメートは、「更新がブロックされました」という要件がアプリケーションと同じドメインにあると考えています。それらはアプリケーションの範囲外です。
システム構成設定には、仕様を割り当てる必要がありますか？どの文書に？これは、アプリケーションの他のソフトウェア仕様とともにSRSの一部にする必要がありますか、それとも別のドメインの仕様として記録する必要がありますか？
要件のテストは、それが文書化されている場所に関係なく行われるものとします。
よろしくお願いします。
私にとって、テストは必要な機能の検証に関するものであり、テストは要件の実装方法に関するものではありません。
更新を無効にすることは必要な機能であるため、テストする必要があります。それは他の要件と何の違いもありません。
実装が構成を通じて管理されるという事実は付随的なものであり、何をテストするかを決定するために使用すべきではありません。
システム要件が満たされているかどうかをチェックする別のプログラム[1]（またはスクリプト）が必要なようです。私はこれをテストのものとは思わないでしょう。ただし、プログラムに何らかの動作があり、要件が満たされない場合にプログラムがシャットダウンする場合は、それをテストできます。
[1] メインプログラムに組み込むこともできます。重要ではありません。重要な部分は、それが分離された部分であり、残りのプログラムから独立して実行できることです。
あなたは、アプリケーションが実行される環境が会社にとって非常に重要であり、アプリケーションと事前設定されたOSの組み合わせのみを展開することを述べています。さらに、これは少なくとも一部は規制上の要件によるものであると述べています。
規制要件は、顧客に提供するシステムが要件を満たし、要件をチェックする通知機関がシステムの関連部分を誰が作成したかを気にしないという何らかの証明を提供する必要があることを意味します。必要な証明を提供する責任はあなたにあります。
つまり、「更新がブロックされました」という要件がアプリケーションの範囲内にあるかどうかは問題ではありません。とにかくそれをテストする必要があります。
SRSドキュメントが1つしかないという仮定は正しくないと思います。複数のソフトウェア構成アイテム（SCI）が存在する場合、それらのシステム要件は、関連する各SCIにさらにマッピングされます。
OSの構成とアプリケーションは、ほぼ確実に互いに独立してバージョン管理されます。したがって、システムには少なくとも2つのSCIが含まれている必要があります。 OS要件はOSベースラインSCIにマッピングされ、アプリケーション要件はアプリケーションSCIにマッピングされます。
次に、各SCIを個別にテストして、マッピングされているソフトウェア要件を満たしていることを確認します。