mkoszk
行徳セレソ執行役員グローバル情報システム本部長が語った印象深いコメントを紹介しておきたい。

 「従来のディーラーマネジメントシステムはクルマの情報を中心としていたが、新システムではクルマではなく顧客の情報に焦点を当てる。顧客がどの販売店に訪れてもすぐにその顧客の情報を把握できるようにし、日本流の“おもてなし”の対応を実現していきたい」

要件定義学習メモ

要件定義のフェーズ
1.準備フェーズ
 a.営業担当や上司からプロジェクト情報の取得を行う
 b.プロジェクトの方向性の検討

 プロジェクトの作業を定義する、プロジェクトの方法について考える、
 キックオフミーティングを開く、プロジェクトの認識を合わせる

2.基盤整備フェーズ
 a.顧客の要求や要望を聞いて自分の理解を伝える

 問題を明確にする、システムの目的を明確にする、業務を理解する、
 既存のシステムを検証する、システム化の範囲を検討する、
 ユーザ情報を収集する、制約条件を明確にする、トレードオフ条件を明らかにする

3.要求獲得フェーズ
 a.要求獲得の準備
  ・前回ヒアリングの見直しと復習
  ・質問リストの作成とレビュー
  ・説明事項・説得事項の検討
  ・ヒアリングのシナリオ作成
  ・参加メンバーへの通知

 b.要求獲得作業
  ・ヒアリングの目的の説明
  ・新たな要求の獲得

 c.獲得した要求の整理
  ・要求の分類
  ・確認漏れのチェック
  ・要求のドキュメント化

 d.整理した要求のレビュー
  ・個人レビューと全体レビュー

 e.開発可否の判断
  ・システムの目的と整合性チェック
  ・費用対効果の検討
  ・疑問な要求、矛盾している要求の洗い出し

 f.新しい要求の創造
  ・要求に対してあらゆる角度から検討を重ねる
  ・新たな要求の考案

 機能要求を獲得する、非機能要求を獲得する、トレードオフ条件を明らかにする

4.引渡しフェーズ
 a.テストの可能性の検証と曖昧さの排除

 すべての要求を見直す、テストの可能性を検証する、要求の曖昧さを排除する、
 追加変更要求に対応する
点数を付けるために、同社はまず、「要件定義書に何を記載するべきか」を規定。同社の開発標準や国際標準のドキュメントを参考にし、全5章、18節からなる「要件定義ガイドライン」として昨年9月に作成し、さらに採点の仕方を「要件定義書スコアリング手順書」としてまとめた。
結論を言う
状況を言う
要点を言う
理由を言う
結論を言う
業務プロセスと業務ステータス

連続的変化から不連続に意味を切り出す操作を「分節化」といいます。

行為を軸に分節化するのが業務プロセスです。

状態を軸に分節化するのが業務ステータスです。