タグ

要求定義に関するmiguchiのブックマーク (3)

  • いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道

    最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 (なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

    いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
    miguchi
    miguchi 2012/02/20
    実際難しいよねー
  • はじめてのRFP――発注時に意思疎通をスムーズにする提案依頼書の作り方 | 安く!早く!を実現するサイト制作の発注マニュアル

    発注の基はRFP作りから 発注をマスターしてベストな提案を引き出す いちから覚える提案依頼書の作り方 制作会社など外部の業者に対して、具体的になにをしてもらいたいかの提案要求を伝える際に必要となるのが提案依頼書(RFP:Request for Proposal)だ。場合によっては、口頭の打ち合わせベースで仕事を進めることもあるかもしれないが、RFPを作ると作らないでは仕事の進め方に大きな差が出る。ここでは、RFPを作るときに必要な基の要素を紹介しよう。 取材・文:編集部 協力:高橋 宏祐(富士通株式会社 コーポレートブランド室 担当部長) 富士通エンジニア職を経験した後、1998年より富士通のウェブマスターとしてウェブ戦略を企画実行。2002年6月に富士通ウェブ・アクセシビリティ指針を公開し、日のアクセシビリティ普及をリードする。2003年にFUJITSUウェブ・ユニバーサルデザイ

    はじめてのRFP――発注時に意思疎通をスムーズにする提案依頼書の作り方 | 安く!早く!を実現するサイト制作の発注マニュアル
  • 要求定義の方法論を知る【後編】:日本IBMの標準的な作業手順とは?

    次にこの決定に基づいて,要件定義の作業計画や要員計画を作成し,作業チームを編成するとともに,成果物を作成するための作業手順やガイドを作成する。すぐに作業に取り掛かれるように,記述ルールやサンプル,記述フォームも用意しておく。さらに,システム化目標や作業項目,品質管理方針や守るべきルール,作業に必要となる技法をメンバーに徹底させるための説明会も実施する。 現業務を現物理モデルで表す 現行業務・システムをベースに新システムを開発する場合は,計画と基準の作成後,「DFD現物理モデル」の作成に取り掛かる(図4のP 2)。DFD現物理モデルとは,現行業務におけるデータの流れと変換プロセスをDFDで表現したものである(図6の(1))。現行業務の内容や意味,役割,業務上の問題点を洗い出すのが目的だ。なお,新システムの対象となる既存業務がない場合は,このステップを省略して,後述するユーザーへの調査から作業

    要求定義の方法論を知る【後編】:日本IBMの標準的な作業手順とは?
  • 1