ユースケースからテスト駆動開発へ「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチYoshiki Hayama
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、ソフトウェアシステムの構造や処理の流れを絵で描くのが大好きです。 つうと、「UML図か」とか思われそうですが、UML図には気力が湧きません。 理由1：ナントカ図、カントカ図といっぱいありすぎる。 理由2：オブジェクト指向設計の影響が強すぎる。 UMLから派生したSysMLだと、図の種類も少ないし、オブジェクト指向風味も薄まっているようです。それでも僕には面倒な感じです。「フローチャートをめぐる迷信と妄言と愚昧」にも書きましたが、箱と矢印だけくらいの、少数の要素からなる絵がいいのです。 内容： ロバストネス図 手書きにサイコー バウンダリーとインターフェイス まとめ ロバストネス図 絵にするのは好きだがモノグサである僕にピッタリだと思えるのがロバストネス図です。ロバストネス図の要素は3つしかありません。ユースケース図の要素を入れても5つです。「ロバストネス図の概要」（http://ww
UXのためのUIデザイン
5. UXとUIの境界 UX = ユーザー体験 語られる言葉は、体験です。 UI = ユーザーインターフェイス 語られる言葉は、インタラクションであり、ビジュアルであり、アーキテクチャです。 UX UI UX=UIではありません。ユーザーがUIを通して体験することがUXです。 UIで語られる言葉がどんなに素晴らしくても、それがすなわちUXを実現しているとは言えません。 UIデザインの理由 デザインには理由が必要です。 UXの実現をUIの目的とした場合、『デザインの理由=UXを実現していること』です。 しかし、体験をUIの言葉で語るには限界があります。そのため、UXとUIをつなぐ言葉が必要になります。 5
UMLを描こう - Vol.4 ユースケース記述 - アシアルブログ
■要件定義の2つの柱 ユースケース駆動開発の要件定義では、2つのモデルを柱として要件を分析・定義します。 1つが振る舞いモデル、もう1つがドメインモデルです。 振る舞いモデルは、ユースケースモデルにあたります。 ユースケースとは、システムの利用例、つまりはユーザが利用できる具体的なサービスのことです。 例えば通販サイトでは、「商品をカートに追加する」「注文する」「配送状況を確認する」などがユースケースです。 それぞれのユースケースに対して、ユーザが何をしてシステムがどう振る舞うかをシナリオとして記述する必要があります。この記述をユースケース記述といいます。 なお、ユースケースモデルはあくまで「振る舞いに関する要件」ですので、 その他のパフォーマンス要件やセキュリティ要件などは、ユースケースにひも付けておく必要があります。 ドメインモデルについては、前回説明しました。 ドメインモデル図（以下
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
