問題タブ [use-case]

システムの一部であるスケジューラーが、毎週の電子メールをユーザーに送信する責任があるとしましょう。「スケジューラー」はアクターとして扱われるべきですか、それともユースケースとしてモデル化されるべきですか?

アクターを選択するためのガイドラインには次のように書かれています。「はい」の場合はアクターです。それ以外の場合: システム内で変更できるものですか。「いいえ」の場合は俳優

スケジューラーは人ではありません。また、その機能を変更することもできます。しかし、私の直感では、これは俳優になれると言っています。少しの助けは素晴らしいでしょう。

ユースケースの作成に使用するツールとその理由は何ですか?

一般的なワード プロセッサ (Word/OpenOffice)、Wiki、特殊なツール (fe Visual Use Case ) などを使用していますか?

UML クラス図とオブジェクト図、およびそれらの関係に精通していることは間違いありません。オブジェクト図は、システム内のオブジェクトとそれらの関係をモデル化するために使用されます。これは、クラス ベースのオブジェクト指向プログラミング言語の場合、さまざまなクラスの具体的なオブジェクトをモデル化することを意味します。

プロジェクトに取り組んでいるとき、ユース ケース (図) とペルソナ (ユーザー エクスペリエンス デザインなど) を作成する必要がありましたが、それらはクラスやオブジェクト、つまりインスタンス (インスタンス) と同じ関係にあると思います。また、Unified Process (UML とある程度結合されている) で理解されるユース ケースは、1 つのメイン シナリオ (フロー) を持つ一連のシナリオです。たとえば、ビヘイビア駆動開発のような具体的なシナリオは、ユースケースのインスタンスです。

これは理にかなっていると思いますか？BDD のようなユーザー受け入れテストの生成などに使用できる、ペルソナとユーザー シナリオをモデル化するための UML のユーザー シナリオ図を評価していただけますか?

製品要件仕様を作成しています。このドキュメントでは、ユーザーがシステムと対話する方法を非常に高いレベルで説明する必要があります。これらの操作のいくつかは、オブジェクトによっては「作成-読み取り-更新-削除」です。

問題は、これらの操作のユース ケースを作成する場合、どのように行うのが正しいのかということです。「オブジェクト x の管理」というユース ケースを 1 つだけ作成して、これらの操作をユース ケースに含めることはできますか? それとも、操作ごと、オブジェクトごとに 1 つのユース ケースを作成する必要がありますか? 最後のアプローチで私が目にする問題は、問題の理解に実際には貢献しないと感じるかなりの数のページを書くことになるということです。

ベストプラクティスは何ですか?

私は新しいプロジェクトを懇願しています（ああ、私は新しいプロジェクトの新鮮な味が大好きです！）そして私たちはちょうどそれを設計し始めています。つまり、このアプリケーションは、ユーザーが実行フローをモデル化できるようにするUIです（Visioのようなドラッグアンドドロップインターフェイス）。したがって、私たちの最大の関心事は、ユーザーが実行フローを迅速かつ明確にモデル化するのに役立つ使いやすさと機能です。

私たちの確立された方法論は、プログラマーとユーザーの間でアプリケーションの調和のとれたビューを作成するために、ユースケースを広範に利用します。これは実際にはビジネス上の懸念事項です。ユーザーケースではなくユーザーストーリーでアジャイル手法を使用したいのですが、クライアントに製品を販売するための明確な範囲を定義する必要があります。

ただし、ユースケースにはいくつかの欠陥があり、そのほとんどは、ここに表示されているように、UIなどの技術的な詳細が含まれているという事実に関連しています。ただし、ユーザーストーリーと完全にインタラクティブなデザインを使用できないため、妥協することにしました。これらの詳細を非表示にするために、エッセンシャルユースケースを使用します。

今、私は別の問題を抱えています：UIの相互作用の明確な説明を持っていることが不可欠です（しゃれは意図されていません）、それで、それをどのように文書化する必要がありますか？言い換えると、UIの相互作用が不可欠な必須のユースケースを使用してアプリケーションを指定するにはどうすればよいですか？

私はいくつかの選択肢を見ることができます：

• 問題を正しく表していないため、ユースケースの使用を中止します
• ユースケースにインターフェースの説明を含めないでください。ただし、別のドキュメント（ストーリーボード）を作成してから、基本的なユースケースにリンクしてください。
• ユーザーとアプリケーション自体の観点から見たビジネスルールの一部であるため、UIインタラクションの説明をエッセンシャルユースケースに含めます

プログラムを設計したい

代替テキスト http://img405.imageshack.us/img405/331/helpq.jpg

ユースケース間の関係はどうですか？

これは私のユースケースですそれは正しいですか??

ユーザー要件を収集するためのツールとしてユースケース図を使用するというアイデアを追求することに興味があります。ただし、システムをゼロから開発するのではなく、新しい機能のためのものです。また、このシステムでは、ユーザーとの対話はごくわずかです。ほとんどのアクターは外部システムになります。

この要件を収集する方法を使用して、人々がどのような経験をしてきたかを知りたいです。顧客はこの変化にどのように反応し、ポジティブでしたか? 誰にとってもうまくいかなかったのですか？

ありがとう、

新しいシステムのユース ケース図を作成しています。システムをユースケース図のアクターとして含める必要があるのはいつですか?

ありがとう。

ユースケースと SRS の違いは何ですか?

アクターが一般化されたユース ケースに参加している場合、アクターは特殊化されたユース ケースに参加しますか? 親オブジェクトのポインターが子オブジェクトを指すことができるが、その逆はできないというポリモーフィズムの類推を考えると、私はノーだと思います。

私はその逆が正しいことを知っています (アクターが特殊なユース ケースに参加している場合、彼は一般化されたユース ケースにも参加しています)。