システムにアクターがない場合の使用例に代わる優れた方法は何ですか？
私は、その活動において完全に自律的であるソフトウェアおよびハードウェアシステムに取り組んでいます。ユーザーは関与せず、データが送信される1つの外部システムがあります。システムの内部ではさまざまなアクティビティとプロセスが行われていますが、ユースケースは それらはうまくモデル化できません これらはすべて内部のものであるためです。ただし、1つの使用例があり、それはデータを外部システムに送信していますが、それはシステムをあまり代表していません。
私はSCRUMを使用してこのプロジェクトを開発しており、スプリントのベースにしたり、バックログの一部を構築したりするためのいくつかのユースケースまたはユーザーストーリーを用意したいと考えていました。私たちのチームでは、これを行うためにこれらを伝統的に使用してきました。これらのアクティビティにプロセスモデルのようなものを使用することを考えていましたが、標準的ではなく、マネージャーやクライアントに説明するのが遅いか難しいようです。
ビジネスとITの利害関係者にとって明確であり、それほど重要ではないが、ユースケースやユーザーストーリーのようにアジャイルスプリントの基礎として使用できるような方法で、ユーザーレスシステムを表す代替手段は何ですか？
「アクター」は、伝えようとしている情報を伝えるためにアクターになりたいものなら何でもかまいません。 「俳優」が人であったり、具体的なものであったりすることを要求するものは何もありません。 「俳優」は、それが情報を効果的に伝える場合、単に概念になり得ます。
アクターを識別するための最も重要な基準は、ユースケースを定義したい抽象化のレベルでアクションをトリガーするものです。 「トリガー-er」が識別できる場合、それは「俳優」である正当な候補者です。 「トリガー-er」は人であり得、それはセンサーであり得、それはほとんど何でもあり得、それは時間でさえあり得る。あなたが知らないかもしれないし、あなたが選択するための多くのオプションを持っているかもしれないので、ユースケースのためのアクターを特定することにおいて非常に特定したくない場合さえある場合さえあります。
ほとんどの人は、「俳優」はシステムの外部にある必要があるという誤解を持っています。それは間違いです。システムと対話する必要がある場合、何かがシステムの「外部」にあるようなものはありません。私がこれまでに設計して実装したすべてのユースケースのすべての「アクター」には、「アクター」を表すインターフェース実装が必要でした。アクターがユースケース図の外部にあると表示されるからといって、そのユーザーへのインターフェースを実装するコード/ビルドハードウェアを記述する必要がないという意味ではありません。つまり、アクターがシステムの外部にあるとしてモデル化されているからといって、それらがシステムの一部ではないという意味ではありません。実際、ユースケースを小説に変える傾向があるので、ほとんどの場合、ユースケースによってアクターへのインターフェースが記述されることを望まないでしょう。
要約すると、俳優がいないというあなたの主張は正しくないと私は主張します。代わりに、ユースケースのコンテキストでのアクターの目的を誤解しているために表示されます。システムでアクションをトリガーするものを特定し、それらに意味のある代表的な名前を付けます。オクターズが俳優になるのに十分な選択をする確率はかなり良いです。
システムがその活動を自律的に実行しているかもしれませんが、それらの活動が誰かに利益をもたらす目的を達成するために実行されることは依然として事実です。
あなたのシステムが何の利点も提供しないなら、誰もそれを使用/購入しないでしょう（おそらく好奇心として）。それらのメリットとそのメリットを明確に説明できれば、ユーザーストーリーを作成することができます。ユースケースはユーザーインタラクションに重点が置かれるため、ユースケースは自律システムにはあまり適していません。
たとえば、家を暖房するシステムがある場合、考えられるユーザーストーリーは次のようになります。
居住者として、実際の温度が希望の温度よりも1度以上下がると、暖房システムが私の家の暖房を開始して、家で快適になるようにしたいと考えています。
ここにはユーザー（快適な家）に明確な利点があり、システムはユーザーが明示的なアクションを実行する必要なくその利点を提供することも期待されています。
ユースケースとユーザーストーリーは、要件を取り込む1つの方法です。 「shall」スタイルのステートメントから、さまざまな表形式またはグラフィカルモデルまで、要件を取得する他の方法があります。要件を導き出し、取得し、分析し、管理する方法のすべてのオプションを理解することは、ここでの単一の回答の範囲を超えているので、 requirements に関する他のいくつかの質問をチェックするか、または詳細については、 Karl Wiegers and Joy Beatty's Software Requirements（3rd Edition） および Joy Beatty and Anthony Chen's Visual Models for software Requirements をお勧めします。
スクラムに関する限り、 スクラムガイド では、要件を取得するために特定の方法を使用する必要はありません。要件は、維持する必要があります 製品バックログ これは、実行する必要がある作業の優先順位順リストです。このバックログを調整し、作業項目間の依存関係を追加して、作業を見積もります。 The Sprint Backlog は、現在のイテレーションで作業しているProduct Backlogからのアイテムのサブセットです。多くの人がバックログのアイテムとしてユーザーストーリーを使用していることは事実ですが、スクラムのルールとしてそれが呼び出されることはありません。