→見積もり・発注
→開発プロセス
→ドキュメント作成
→詳細設計
→アルゴリズム
サブトピック†
要求開発†
- 観察力と推理力のプロ 2008.4.9
- 「企業の本社や管理部門は報告書やら何やらであまり役に立っていないものがどっさりありますが，物流センターのような現場には無駄な物なんてないんですよ。どんなに旧式のプリンタであっても業務に必要だからそこに置いてあるわけで，そういう意味では紙切れ1枚にも大概役割があるんですね」
- システム開発には広い視点で取り組め 2008.4.7
- 利用部門が主体ということと，利用部門の言うことをなんでも聞くことは全く異なる。利用部門は新システムに対しても従来通りの機能を要求したり，自分が困っていることを解決してほしいという観点だけで要件を出すことが多い。
- RoRで要求仕様を開発(RfS)
- 要件定義フェーズでRfSを行うときには，もらった設計書を単にプログラム化するだけの能力しかないプログラマでは荷が重い。
- 変化に強いスタイルで構築しなければならないため，オブジェクト指向をちゃんと理解したうえで，アジャイルの設計スキルと，きれいにコードを作成できる技術を身に付けた開発者である必要がある。そうでないと，要件定義の間に「仕様」のアプリケーションが変化に対応できなくなってしまう。また，開発しながら仕様を決めるので，要件定義のスキルも必要だ。
- つまり，このフェーズでプログラミングを行う開発者は高度なスキルを要求される。RfSとは，上流フェーズをプログラミングを使って行うということなのだ。
- 要求を洗い出す４つの工夫
- 模型を作って動かす
- 壊しては作る
- サンプル集で動きを確認
- UI仕様書と画面見本
- 要求分析ツリー
- 開発プロセスの本質・要求開発のフロントローディング開発
- 【現状の課題】
- 要求自体がどんどん複雑化し，とらえづらくなっています
- 既存の人の業務をコンピュータ化するという観点だけではなく，業務をIT化することで付加価値を創出しなければならないという課題を負うことが多くなります。
- このような要求については，要求提案当初は非常にあいまいな場合が多いのです。
- 様々なテクノロジを組み合わせて開発した結果，はたしてビジネス要求を実現できるかのかどうか，ちょっとやってみないとわからない
- 【対策】
- これらのリスクをできるだけ早期にヘッジするために，反復開発やアジャイル開発
- (1)要求を早期に検証する
- (2)技術的リスクを早期にヘッジする
- 【上記対策の問題点】
- システム開発よりも前段階で，つまり企業の将来ビジネスを構想する要求開発の段階にて，両リスクをヘッジするための対策を講じる必要が出てくる
- ビジネスとITが密接に関係するような問題領域では，ビジネス要求をITでどう表現するかによってIT化の価値が左右するため，試行錯誤しながらビジネス価値を創出するIT表現を洗練させることが重要となる。
- 要求定義の基本を知る
- あらゆる要求定義に共通する「4つの必須スキル」がある。それは，
- （1）ヒアリング技法
- （2）業種・業務知識
- （3）要求定義の方法論
- （4）要求をモデル化するための図法――の4つだ。
- 要求定義を成功させるためには，まずこの4つの必須スキルを身に付けて地道に実践するしかない。
業務知識†
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
