私には一連のユーザーストーリーがあり、一連のビジネスルールがあります（主に、準拠するための要件を拘束する法律）。アジャイルSDLCでは、これらの「ルール」がユーザーストーリーのどこに添付されているのかわかりません。
たとえば、次のようなユーザーストーリー。
医師として、新しい患者ファイルを作成するために患者情報を追加したいと思います。
そして、次のようなルール：
各患者の記録には、次の情報を入力する必要があります。（a）患者：（i）名前と名。（ii）住所; （iii）生年月日; （iv）性別;
これら2つは明らかに一緒になりますが、どうすればそれらをリンクできますか？私のユーザーストーリーのテスト受け入れ定義として？別のユーザーストーリー？
私がこれを処理するのを見たいくつかの異なる方法があります：
アーティファクトはビジネスルールを保持するために作成され、すべてのルールの中央リポジトリに保存されるため、これは開発チーム全体に認識され、知識の保管場所が維持されます。アプリケーションを構築してからわずか数年以内に何百ものルールが存在する可能性があるため、これは醜いものになる可能性があります。
ルールは、ユーザーストーリー内の別々のカードに配置される場合があります。したがって、ユーザーストーリーはその1行ですが、そのストーリーを完了するためのすべてのタスクを構成する6〜8枚のカードが存在する場合があります。たとえば、新しい患者フォームを作成したり、フォームの検証を行ったりする必要があります。したがって、この方法で要件を追跡する方法として、これがカードの行に表示されるのを確認するのは難しくありません。これは私の考えでは最も自然なことですが、カードが「フォームの一部のフィールドが必須であることを確認する」可能性があるため、特定のリストが100％書き留められる場所でもありません。
明示的なリンクはありませんが、ルールは、フォームがこのルールを適用していることをユーザーが確認するためにQAまたはBAが注意するものです。これは1つに似ていますが、問題はこれにおける開発者の責任は何かということです。この場合、開発者ではなく、QAが追跡するものである可能性があります。
ユーザーストーリーは、要件の包括的なリストではなく、ディスカッションを開始することを目的としています。このルールは、開発者がユーザーと、新しい患者ファイルを作成するために何が必要かを話し合うときに思い浮かぶべきものです。
ストーリーが終わった後、数スプリントの間カードにぶら下がるというアイデアは好きですが、カードが最終的に破壊されるという点は確かです。同時に、適切な領域にルールを実装するコードがどこかにあるはずです。投稿した例を使用すると、フィールドを表示する必要のあるUIレイヤーとおそらくエラーメッセージがあるため、いくつかの場所で必須フィールドのリストに気付く可能性がありますが、ビジネスロジックレイヤーもあるはずです。このロジックを使用して、新しい患者ファイルを作成する前に、一部のフィールドが具体的に入力されていることを確認します。構築中のシステムには、何らかの形でルールも格納されます。
合格基準として。結局のところ、これらはテストとして実行できるルールです。確かに新しい話ではありません。成果物の目標がないため、それは間違いです。