私はインターネットのどこにもこの質問を見つけることができませんでした、そして私は現在私の試験プロジェクトに取り組んでいるので、これが答えられることを望みます。
ボス/EBP/サイズテストに失敗した場合、ユースケースはどうなりますか？それを捨てて書き直しますか、それは非機能要件になりますか？
それとも、テストは、ユースケースがプロジェクトの残りの部分で高いビジネス/リスク/アーキテクチャの価値を持っているかどうかを単に証明しますか？そして、テストに失敗したユースケースの優先順位を下げる必要がありますか（テストが1つだけの場合）？
御時間ありがとうございます。クレイグ・ラーマンの本は、私が知る限り、これについてはあまり深く掘り下げていません。
http://www.craiglarman.com/wiki/downloads/applying_uml/larman-ch6-applying-evolutionary-use-cases.pdfを参照していると思います。
それは非機能要件になりますか？
ほとんどの場合、ユースケースは機能要件を表しているため、それらを非機能要件にリファクタリングすることはほとんどありません。
あなたがそれらを書き直すことができて、それらがテストに合格する可能性が高いなら、おそらくあなたはそうすべきです。書き直しができない場合は、実際の値を見つけてください。この情報は、後続のモデリング手順で役立つ場合があります。それが起こっていない場合は、ゴミ箱に入れてください...
そして、テストに失敗したユースケースの優先順位を下げる必要がありますか（テストが1つだけの場合）？
サイズテストに失敗したゲームボード上のMovePieceの例に固執する場合は、それをアクティビティ図に入れるか、このステップが実際に属する対応するユースケースのドキュメントに含める方がよいでしょう。
ラーマンが言及したボステストを参照すると、「ログイン」は他のユースケースの前提条件になる可能性があります。また、より測定可能な価値を持つユースケースにいくつかを参加させることもできます。著者が述べているように、テストは失敗する可能性がありますが、ユースケースは依然として価値がある可能性があります（合理的な違反を参照）。
したがって、少なくともこれは常識が示唆していることです。RUPには別のことを示唆するルールがあるかもしれません（=それを知らない）。
検討中のユースケースがボステストに失敗した場合（このユースケースはボスにとって価値がないことを意味します）
次に、それは共通のサブ関数として立つ可能性があります（他のすべての主要なユースケースのサブ関数であるため）
あなたが私に尋ねた場合、適切なテストのためにそれらを考慮するために、ユースケースに優先順位を割り当てるための名前を形式化しないでください。
これらは、優先度レベルに割り当てられた名前にすぎません。