「グローバル要件」をどのように含めますか？
「グローバル要件」を分割することがベストプラクティスであることは知っています。これは、Confluenceで文書化するときに行うことです。
ただし、開発チームと一緒にグルーミングを行うとき、これらをJiraのユーザーストーリーに最適に組み込む方法がわかりません。明らかなアプローチは、各ユーザーストーリーの受け入れ基準としてそれらを追加することだと思います。しかし、それはそもそもそれらをグローバル化する目的に反します。
例：チェックアウトプロジェクトの場合
グローバル：すべてのマークアップは、スタイルガイドで提供されるスタイルを使用する必要があります
必須：パスワードのリセット-パスワードを忘れたお客様として、購入を続行できるようにパスワードをリセットできるようにしたい
明らかに、機能を提供されたデザイン（html/css）に接続する場合、開発者は完全に応答性を維持する必要があります（詳細はhtml/cssにあります）。しかし、私は各ユーザーストーリーでそれを明記しないことを望みます。どうすればこれに対処できますか？
私の考えでは、グローバル要件は definition-of-done に属します。グローバル要件が変更されたときに、一致するすべてのユーザーストーリーを更新したくないからです。
まあ、ユーザーが別のマシンである場合は、ユーザーストーリーのUI標準に対処するつもりはありません。
「グローバル要件」を分割することが、すべてのユーザーストーリーに適用されないというリスクに見合うかどうかを判断する必要があります。各ストーリーにグローバル要件を実装して、それらのグローバル要件が満たされていることを証明するテストが必要な場合は、次の2つの選択肢のいずれかを選択すると思います。
各ユーザーストーリーに関連するグローバル要件をユーザーストーリー自体に含める、または
参照によりグローバル要件を組み込みます。つまり、「このユーザーストーリーはUI標準47に準拠し、その標準で指定されているすべての受け入れテストに合格する必要があります。」
要件について話すとき、複数のタイプの要件があります。多くの場合、ユーザーストーリーは、機能要件（入力、出力、動作）とユーザー特性（ソフトウェアのユーザーの目標、欲求、目的）の組み合わせをキャプチャします。しかし、要件を取り込む際に考慮すべき重要な他のものがいくつかあります-設計の制約と品質の属性が頭に浮かびます。
違いは、設計の制約や品質属性のようなものがシステムの設計と保守の全体にわたって存在することです。機能を使用すると、機能を1回実装すれば、それを使用できます（回帰を除く）。ただし、設計の制約内で常に機能するように注意し、システムに品質属性があることを確認する必要があります。
あなたの特定の例では、ソフトウェアシステムのユーザビリティの特定のスタイルガイド部分の使用を検討します。ユーザビリティは品質属性です。特定のスタイルガイドに準拠するための要件は 適切な要件 です。これは、まとまりがあり、完全で、一貫性があり、アトミックで、最新で、明確である、などです。
これを処理するための正しい方法はありません。
あなたがしなければならない最初のことはあなたのガイダンスを捕らえて管理することです。たとえば、スタイルガイドの場合は、チームが利用できることを確認してください。パフォーマンス要件については、機能とタイミングを関連付ける表を置いてください。可用性、フォールトトレランス、および障害復旧については、計画を立て、システムを低可用性モードまたは障害モードにして、目標が確実に満たされるように計画をテストします。適切な変更保護と変更履歴を備えたWikiで十分な場合もあれば、より厳密な構成管理システムが必要な場合もあります。
これらの他の要件を製品に結び付けるのは、文書化された標準に対して実行されるテスト計画の開発（JIRAテスト管理プラグイン- Zephyr 、 TestFLO がある）と同じくらい簡単かもしれません。ユーザーのストーリー、バグ、またはタスクの標準的なライフサイクルに従っていないため、設計の制約と品質属性を標準のJIRAチケットとして設定することはお勧めしません。それらは、検索可能、参照可能、および永続的な形式である必要があります。
最後のステップは教育です。開発チームが標準またはこれらの永続的な要件を認識し、それらに対する開発者テストを設計および実行する方法を確認してください。