アジャイル分析設計をする前に、ユースケースをひとつだけに絞り込もう - 今日の役に立たない一言 － Today’s Trifle! －
「アジャイル開発」に先行して「アジャイル分析設計」をというの記事で言っている「アジャイル分析設計」の要旨は、以下の部分にまとまっている。 ユーザーからの要望にもとづいて素早く『ユーザーが理解できるモデル』を描き広げ、それを用いて要望をより具体化しつつモデルに反映させる でもここでひとつ問題。「ユーザからの要望」というのが何なのか、ユーザ自身が分かっていないことが多いのも事実。 そしてそれを解決するには、ユースケース図をひとつだけに絞る方法がとても有効だ。ユーザはいろんなことを実現したいと思っている。でも、それらの要望の大半は、実はひとつの目的を達成するための部分集合であることが多い。たくさんの要望を俯瞰して、何を達成したいのかという目的を絞り込む。 たくさんでてきたいろんな要望は、それぞれが点として存在している。しかし、ユーザが達成したいひとつの目的がわかれば、大半の要望が線でつながる。
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
