ユーザーストーリーに非機能要件を文書化する方法は？
私はソフトウェア開発会社でビジネスアナリストとして働いています。私の以前の組織では、ウォーターフォールを使用して開発が行われ、「ビジネス要件ドキュメント」（BRD）と書きました。
私の現在の役割では、チームはアジャイルスクラムとJIRAを使用して、機能要件などをキャプチャするユーザーストーリーを作成しています。
私の質問は、JIRAの非機能要件をストーリーとしてどのようにキャプチャするのが最善かということです。
BRDではこれは非常に簡単です。非機能要件を独自のセクションに追加し、各要件の横に一意のIDがあることを確認します。
ID： 001 要件： Webアプリは、IE11、Firework 50などのブラウザーと互換性があります。
しかし、アジャイルスクラム、特にJIRAでは、これらをどのように文書化する必要がありますか？
非機能要件にはさまざまな形式がありますが、それらには1つの共通点があります。はシステムの機能動作を記述せず、ユーザーが行える設計の選択に制約を課します。
非機能要件は、ユーザーストーリーとして表現するには不適切です。ユーザーストーリーは、短い期間（プロジェクト全体の長さと比較して）に一度実装して、完了と見なすと最も効果的に機能します。ストーリーが完了したら、定期的にストーリーを再訪する必要はありません。機能以外の要件の場合、プロジェクト全体で要件を遵守する必要があるため、機能しません。プロジェクト中にブラウザの互換性を1回だけ確認し、残りの時間は無視するということはできません。
ほぼすべての（機能的な）ユーザーストーリーに影響する非機能的な要件の場合、それらを文書化するのに最適な場所は、完了の定義の一部としてです。
機能の比較的小さなサブセットに影響する非機能要件の場合、それらを関連するユーザーストーリーの承認基準の一部にすることができます。このサブセットがまだ好みに応じてかなり大きい場合（または将来的に大きくなる可能性があり、将来のストーリーで一部の非機能要件を見逃す可能性があることを恐れている場合）、一部のドキュメントに非機能要件を含めることができます。関連するストーリーの受け入れ基準からそれを分類して参照します。
要件自体の形式と、それらを組み込むための可能なドキュメントについては、あなたとあなたのチームに最適なものを使用してください。
「機能以外の要件」はややあいまいで、解釈の自由があります。あなたの具体的な例を挙げれば、これらの要件は他のストーリーの受け入れ基準として使用されるべきだと私は言うでしょう。
同じ非機能要件を次々に繰り返すことに不安がある場合は、これらの要件をすべて文書にまとめて（例：「アプリケーション標準」）、「アプリケーション標準に準拠する必要がある」部分を作成することもできます。あなたの定義の完了。
これらをDODの「完了の定義」に組み込むことができます。
非機能はアジャイルで問題がありますが、それらが変更された場合、どのストーリーがどの基準に対して行われたかを追跡する方法がありません。
だから私はそれらを各ストーリーに対するテストとしてリストしてみます。それは多くのコピーアンドペーストを意味したとしても。
彼の本 "Essential Scrum" で、ケネスS.ルビンは言います（93ページを参照）：
私は頻繁に非機能的な要件をユーザーストーリーとして記述しますが[…]、特に異なる形式でそれらを記述するのが厄介またはより便利であると思われる場合は、そうする義務を感じません[i.e. 「ユーザーとして…」のパターンに従っていない]。
つまり、JIRAでユーザーストーリーを作成して、機能しない要件を文書化することができます。
ただし、ケネスはまた Ewan および Bart van Ingen Schena — [[]]によってすでに指摘されているように、チームが定義に非機能要件をできるだけ多く含めるように推奨する彼らができる限りのことをした」これは、非機能要件が他の多くの（機能）ユーザーストーリーに影響を与えることが多いためであり、それらが対処されない場合、ストーリーは実行されません。したがって、doneの定義はかなり頻繁に適しています。