はてなブックマーク - 画面設計とか外部設計とか、もうやめようよ

画面設計とか外部設計とか、もうやめようよ - masayangの日記（ピスト通勤他

d:id:masayang

タグ : システム開発 agile development 開発要件定義プログラミング design business 設計 programming

コンピュータ・IT 274 users

昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。よくよく見ると、FeatureとFunctionとがごっちゃになっていた。つまり、要件分析の段階で実装のことを考えていたのである。なぜ、そうなったのだろう？画面から要件分析をすると、こうなるどうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらし... > このページを見る

最終更新時間: 2009年01月29日14時08分

▼ブログで紹介する

みんなのブックマーク人気（0）新着

monochromekk プログラミング, システム開発, 要件定義
アジャイルにおけるフェーズ分けとも絡みそう。要件定義と設計を混同させないようにする方法が必要。 2012/02/28
aratafuji agile, development
自分の理解ではイテレーション計画時に画面設計するべきだと思うけど、その段階で必要な素材(アイコンとか)を洗い出すと、デザインが外注の場合はイテレーション開始時に間に合わせるのが難しい…。 2012/01/18
hiro_y agile, devprocess
画面設計ではなくストーリーで 2011/12/27
sugimori agile, *アジャイル
やめよう 2011/07/27
katzchang
ほりおこし。 2010/09/21
northlight
Agileねえ…。 2010/07/05
kaorun55 scrum, 要件定義
画面設計からはいると肝心なとろこに眼が届かなくなる可能性が高い 2009/11/08
language_and_engineering 開発, 設計, UI
　先に画面を決めるとあとで変えづらい。要件の段階ではモックは見本であり，設計ではない。/要件と実装をごっちゃにしない。　極論では，要件は　【紙と鉛筆と電話があれば実現できる】　もの。 2009/03/27
matsutakegohan1 programming, business, design, development, agile
要件定義の段階で下記にあるようなことを分析していたら、それはなんか変だと思ってよい。 2009/02/14
kamataro requirement, design
画面は機能設計なので、工程を逆転するなら弊害を意識するべきという話。／"彼らの解決方法を問題の定義と取り違えるな" 2009/02/03
SiroKuro システム開発
客の頭ん中が『どうやって使えばいいの？』でいっぱいだから、画面設計から入っちゃうんじゃないかな。『その前に一歩戻って肝心なところが何なのか決めちゃおうよ』という話だと理解した。 2009/02/03
Nagise
エンドユーザが理解できる部分ってのが画面しかないからなぁ…。逆に顧客は意味不明な仕様を訴えてくるSEに対して問題点を指摘できないし。専門的な事象の妥当性の評価ってのは難問だよな 2009/02/02
Idios 開発
プロジェクト反省会参考資料#x 2009/01/31
dosequis development, あとで
面白そう 2009/01/31
nakag0711
顧客は機能の実現にのみ関心を持ち実装レベルには関心を持たないというのは単なる都市伝説なので、契約書である要件にある程度実装の話が入るのはやむを得ない。ただ変更には柔軟な体制であってほしいけど。 2009/01/31
kuniku システム開発, 要件定義
コツ　　こつ　テクニック　　要件に実装を書くな 2009/01/31
clayfish
functionとfeature、storyとscenario をもうちょっとくわしく。MECE で解説期待。 2009/01/31
hush_puppy programming, development
画面って変更しやすい部分だしな。使いやすいようにどんどん変えていけばいい。 2009/01/30
lli programming, work
納得する部分も多い。 2009/01/30
overleo
抽象論でよくわからん。具体例が欲しい。 2009/01/30