ユーザーストーリーへのビジネスルールの統合

Question

私には一連のユーザーストーリーがあり、一連のビジネスルールがあります（主に私の要件を拘束する法律を拘束する法律）。アジャイルSDLCでは、これらの「ルール」がユーザーストーリーにどこに添付されているのかわかりません。

たとえば、次のようなユーザーストーリー：

医師として、新しい患者ファイルを作成するために患者情報を追加したいと思います。

と次のようなルール：

次の情報は、各患者の記録に入力する必要があります。（a）患者：（i）名前と与えられた名前。 （ii）住所; （iii）生年月日。 （iv）性別。

これら2つは明らかに一緒になりますが、どうすればリンクできますか？私のユーザーストーリーのテスト受け入れの定義として？別のユーザーストーリー？

Answer 1

私がこれを扱っているのを見たいくつかの異なる方法があります：

1. アーティファクトはビジネスルールを保持するために作成され、すべてのルールの一部の中央リポジトリに保存されるため、これは開発チーム全体で知られており、知識の倉庫が維持されます。これは、アプリケーションを構築してからわずか数年以内に何百ものルールがある可能性があるため、醜くなる可能性があります。

2. ルールは、ユーザーストーリー内の個別のカードに配置される場合があります。したがって、ユーザーストーリーでは、1つのラインであるが、そのストーリーが完了するすべてのタスクを構成する6〜8枚のカードがあるかもしれません。たとえば、作成された新しい患者フォーム、フォームの検証などが必要です。したがって、この方法を追跡する方法として、これがカードのラインに登場するのを見るのは難しくありません。これは私の心にとって最も自然なことですが、これは、カードが「フォーム上の一部のフィールドが必須であることを確認する」可能性があるため、特定のリストが100％書き留められる場所ではありません。

3. 明示的なリンクはありませんが、ルールはQAまたはBAがユーザーがこのルールを施行していることを確認するために注意するものです。これは1つに似ていますが、問題はこれにおける開発者の責任は何ですか。この場合、それはQAが開発者ではなく追跡するものです。

ユーザーストーリーは、要件の包括的なリストではなく、議論を開始することを目的としています。このルールは、開発者がユーザーと私の心に新しい患者ファイルを作成するために何が必要かをユーザーと話し合うときに出てくるべきものです。

---

ストーリーが完成した後、いくつかのスプリントのためにカードにぶら下がるというアイデアが好きですが、カードが最終的に破壊されるという点がわかります。同時に、適切な領域のルールを実装する場所にコードがあるはずです。投稿した例を使用するには、フィールドを表示する必要があるUIレイヤーがあり、おそらくエラーメッセージがあるため、必要なフィールドのリストに気付くのは、いくつかの場所で、必要なフィールドのリストに気付くかもしれません。新しい患者ファイルを作成しようとする前に、一部のフィールドが特別に完了したことを確認するこのロジックがあります。構築されているシステムには、ルールも何らかの形で収容されます。

Answer 2

受け入れ基準として。これらすべてがテストとして実行できるルールです。間違いなく新しい物語ではありません。それは、成果物の目標がないので間違っているでしょう。