第10章 問題領域モデル：概念の視覚化 続き(P136) ●なに？ 問題領域の概念の語彙を視覚化すること ●目標 概念クラスを抽出し、問題領域モデルを作成すること ●指針 多数の細かい概念クラスを過剰に記入することと、控えめな記述とを比べたら前者の方がよい …

本日オヤスミー。だるいー。

「理論上は,理論と実際に差異はない。しかし実際には確かに差異はある。---- Jan L. A. van de Snepscheut」 おっ。これなら実体験で知ってるぞ（笑 第9章 ユースケースモデル：システムシーケンス図の作成(P121) 「システム」シーケンス図は、ユースケース…

http://d.hatena.ne.jp/kuranuki/20041017#p1 http://d.hatena.ne.jp/amapyon/20041022みなさんの意見がとても参考になる。多分コレ！というのは決めずに、色んな条件で臨機応変にやりたいな。慣れとかあるからいい感じのとかあれば、そのメンツでは固定にし…

「強く強張ったものは折れる。しなやかなものは生き残る。---- Tao Te Ching」 私もしなやかでありたい。Tao Te Ching を調べたら、「老子の道徳真経」のことだった。 第8章 方向付けフェーズから推敲フェーズへ(P111) 推敲フェーズでは、「中核のアーキテク…

書かれた要件を絶対視しないこと。常にコードを書き、テストをし、フィードバックを受け、ユーザーとの協調を継続し、調整を重ねることが大切 成果物はオンラインが好ましい 方向付けフェーズではUMLはあまり使わない（必要なことは情報を集めること） 方向…

ようやく推敲フェーズに向かっての準備だ！なんか実際にやってるような気分になってきた（笑 っていうか、ユースケースを書き終わっての、この微妙な隙間を埋めてくれているのはとってもかゆいとこに手が届いてる感じで嬉しいかも！ 補助仕様書(P91) ユース…

推敲フェーズのステップに進むかどうかの意思決定。契約的にはどうなんだ？ 「Cockburnとslow burnは韻が同じですね」って書いてある(笑 表6.1(P80) スゴイ！こんな風にいかねーかなーーーー。ってそのために勉強してんのやった。 成果物一覧は後で作ってみ…

※P85 図6.5参照

フィードバックで得られるもの：ユーザーの評価,テスト,「自分たちが、何を知らないのかを知る」 方向付けフェーズの最初の方で書かれるユースケース1つあたりにかかる時間は2分！(casual） 推敲フェーズの完了までには、ユースケースの80〜90%が一段落。調…

ユースケースは、割りとどうでもいい細かい機能のリストに置き換えられる！ →機能仕様書と一緒に使うのはまずい(>_

ようやくユースケース図に来た！びっくり。図は大事ぢゃなかったんだ。扱いがとても低い（笑 ユースケース作業の中で大事なのは文章を書くこと！ 図を書く場合には、アクタと目標リストと関連させ、イメージを掴む

主要アクタ：SuDのサービスを使用することで達成されるユーザー目標を持つ。「主導するユーザー目標を見つける」 補助アクタ：SuDにサービスを提供する。「外部のI/Fとプロトコルを明確にする」 舞台裏アクタ：上記２つではないもの。（例）政府税務機関 ※Su…

(例） 【本質的スタイル】 管理者が自分の身元を明らかにする。 システムが管理者のIDを認証する ・・・ 【具体的スタイル】（早期の要求分析にはそぐわない） 管理者がダイアログにIDとPassを入力する（図XX参照） システムが管理者を認証する システムがユ…

「継続的で個人的なコミュニケーション」で常にユースケースをよいものにしていく。 目標（goal）と意図（intention）は同義語

システム境界の選定 ブレーンストーミングによる、目標とアクタの発見 ユースケースの定義 →EBP指針をパスしないときは目標のレベルをあげる →外部イベントを識別して、目標とアクタを発見する →ユーザー目標ごとに1つのEBPレベルユースケースを定義 →ユース…

ユースケースの個数と粒度は、 要件の[理解][保守][管理のしやすさ][時間]に影響する →下位機能の目標を記述する際には上記をふまえて検討が必要

指針：EBPユースケース ElementaryBusinessProcess：基本ビジネスプロセスビジネスイベントに反応して、1度に１つの場所で1人によって実行されるタスク。 観察可能なビジネスの価値をふかし、データの一貫性を維持する。 （=ユーザー目標レベル）※主要アクタ…

-

技術的に制約があったりする場合に記録する場所

非機能的要求，品質属性，制約がユースケースに明確に関係している場合には、一緒に記録。 ふつうは、補助仕様書にまとめた方がなにかと便利

拡張シナリオは、ハッピーシナリオと対峙してるので、3.に対しては3a，3bとふる ほとんどのステップで起こりうる拡張の条件の場合は、*a，*bのようなラベルをつける

前置き部分 正常シナリオの前に読むべき要素だけを書く 利害者関係と関心のリスト システムが何をしなければならないかを提案し、「境界」を示す 事前条件と事後条件(成功保証） 「必ず真でなければならないこと」を宣言する 多くの場合、すでに終了している…

Cockburnはブリーフ、ジーンズ、スーツって言ってた気がする [brief]簡素 [casual]略装 [fullyDressed]正装

ようやくユースケースにたどりついた。Cockburn様はやっぱりスゴイ システム要件を捕捉する方法 「単純でわかりやすいこと」⇒ 目標を定義したり評価したりしやすいし、リスクも小さくなる ユースケース＝要件 システムの使い方のストーリを記述することによ…

【FURPS＋】モデルの種類⇒要件が必要な範囲をカバーしているかどうかのチェックリスト F Functional(機能的)−機能,能力,セキュリティ U Usability(使いやすさ)−使い勝手,HELP,文書資料 R Reliability(信頼性)−障害の頻度,回復可能性,予見性 P Peformance(パ…