要件の作成中にShallとMustを使用するためのベストプラクティス

先ほどメールを送信しましたが、派生要件で「Shall」という言葉を使用しても機能要件に続かないことを開発者に思い出させました。機能要件を記述するとき、「必須」という言葉を使用して、派生要件が行う必要のある機能を説明します。
派生=システムは要件である
機能=システムは要求を行わなければならない

それは私たちの先輩の一人によって送り返されましたが、それは間違っていて、すべての要件で使用されるべきです。

私はここで間違っていますか、すべての要件で使用する必要があります。それをバックアップするものを見つけることができませんでした。

RFC 2119「RFCで要件レベルを示すために使用するキーワード」では、要件に関するさまざまな単語の意味を詳しく説明しています。

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」はRFC 2119で説明されているように解釈されます。

このドキュメントから：

• MUSTは、定義が絶対要件であることと同等であり、REQUIREDそれをSHALL示します。
• MUST NOTと同等SHALL NOTであり、仕様の絶対的な禁止であることを示します。
• SHOULDはRECOMMENDED、特定の要件を無視する正当な理由があることを意味しますが、その意味を検討する必要があります。
• SHOULD NOTまたNOT RECOMMENDED、特定の動作が許容可能または有用である可能性があることを意味しますが、これも含意を検討する必要があります。
• MAYOPTIONALとは、要件が本当にオプションであることを意味します。オプションの要件を実装する場合としない場合がある異なるシステムとの相互運用性を実行する必要があります。

このRFCに従って、SHOULD内部ドキュメントと標準世界全体との間の通信の一貫性を確保するために行われます。

どこでドキュメントの別のレベルに属するshallと結論付けたのかわからないmust。これは、私が知っている情報源に裏打ちされていない、非常にarbitrary意的な区別です。

Shallそしてmust、字句的に同等です。必要なアクションです。

使用するshallかmust本当に使用するかは、ドキュメントの残りの部分と、その特定の文の文法的な意味に依存します。

そうです、あなたは間違っています。ただし、のshall代わりに常に使用することも間違っていますmust。それらは同程度の義務を表しています。

DO-178ガイドラインまたはDO-254ガイドラインのフレームワーク内で作業する場合、これらには一般的な要件と派生要件に関する独自の定義があります。ただし、これらのガイドラインでは、要件を指定するために使用する単語（shall、should、mustなど）を指定していません。

要件管理ツールが派生要件を自動的に指摘しない場合、 たとえば派生要件の検証目標も満たされていることを示すために、mustではなくmustを使用してこれらを機能要件と区別することは有益です。これは、一見arbitrary意的なドキュメント要件の理由である可能性があります。

DO-178およびDO-254 派生要件では、実際には、より高いレベルの要件から派生していない要件を意味することに注意してください。したがって、派生要件は、本質的に新しいトレーサビリティチェーンを開始します。

DO-178とDO-254はどちらも、アビオニクスソフトウェアと電子機器の開発に使用される商用ガイドラインドキュメントであり、www.rtca.orgから有料でのみ入手できます。