req-definer.com 上記の手順に従って要件定義をしたら、その要件通りに動作するのかどうかを確認する必要がある。この動作確認行為は、通常、受入テストと呼ばれる。実現されたシステムが、受け入れ可能なシステムかどうかをテストするというわけだ。本稿で…

要件とは何か 良い要件とはどのようなものか 良い要件①：文体が、命令形になっている 良い要件②：文の内容が、読み手にとって理解できるものになっている 良い要件③：具体的である(設計側との合意ができている場合は、抽象的な表現も許容される) 要件の種類 …

見積もり用語3点セット(RFI、RFP、RFQ) RFI RFP RFQ 見積もりの流れ 見積もりプロセス概要 見積もりにおけるポイント 1点目：要件を明確化する 2点目：複数の業者に見積もりを依頼する 見積もりにおいて注意すべきこと 要件の変更に備える ベンダの見積もり…

物理上のシステム構成物と論理上のシステム構成物 論理上のシステム構成物における設計成果物の全体像 物理上のシステム構成物と論理上のシステム構成物 システム開発における成果物について整理をしたい。 req-definer.com 上記の記事で、システムとは何か…

下記の記事(システムの全体像に関する説明)にて、システムの全体像について説明した。本節では、システムの全体像における、要件定義のスコープ、設計スコープについて説明する。また、2つのスコープを重ね合わせ、両者のスコープ間の関係性についても説明す…

システムの全体像 本節では、システムと何か？について説明したい。一枚の絵で説明すると上図となるのだが、順を追って説明していくことする。本説明の対象は、システムの中でも、情報を取り扱うシステムであり、初めに、情報そのものについて整理し、その情…

筆者が新人の頃、その用語を聞いて混乱した用語がある。「外部設計」と「内部設計」だ。ある人は「基本設計」と「詳細設計」のことだよと言うかもしれない。ある人は、「上流工程の設計」と「下流工程の設計」のことだよと言うかもしれない。システム開発業…

各工程の全体像 要件定義の位置づけ 設計の位置づけ 実装の位置づけ 設計動作の確認の位置づけ 要件動作の確認の位置づけ 各工程の全体像 システム開発における、各工程を簡単に説明しておきたい。システムとは何か？については、下記を参照されたい。 req-d…

やる気がなくても仕事を進めるルール なぜこのやり方がうまくいくのか うまくいく理由1：1日の始まりにやることがはっきりしている うまくいく理由2：最も重要なタスクを最初にこなせる うまくいく理由3：マルチタスク化を防ぐことができる アイビーリーメソ…

はじめに 会議とは何か 会議の種類は2つしかない ①認識合わせ ②意思決定 会議の進め方 会議前にやること アジェンダの用意 議事録の用意 資料の用意 会議中にやること 会議後にやること 会議後の作戦会議（社外との会議後の場合） 議事録の発行 宿題事項の刈…

炎上の定義 炎上を止めるために出来ること 納期を遅らせる 期待の品質を下げる 現状の品質を早く上げる まとめ 結論：粛々と火を消そう プロジェクトというのは、炎上しやすいものだ。あっちでも炎上し、こっちでも炎上する。火消し屋なんていう役割が、存在…

テキストボックスとは テキストボックスに対して決めるべき要件は入力に関する要件 ①：テキストボックスに入力可能な文字種類 ②：テキストボックスに入力可能な文字の最小数および最大数 テキストボックスの入力に対する要件の例 結論：テキストボックスに関…

はじめに 要求と要件の違い どのような資料が、要件定義書となりうるのか？ 結論：命令系の文章は要件定義書となりうることを意識しよう はじめに 仕事柄、要件定義書と書かれた資料を拝見することが多い。フォーマットは結構ばらついている。ある要件定義書…

部品名称一覧 各部品の使い分け 各部品に関する要件の定義方法 結論：部品の名称の認識を顧客側とベンダ側で合わせておこう 画面の要件を定義するときに、画面内に配置する部品の項目を理解しておくと要件定義がしやすい。以下に、項目の一覧を示しておく。…

要件定義書の書き方がわからない、要件定義って何やればいいの？という方もいると思うので、発注側としての要件定義書の作り方をまとめておく。 要件定義書に書くべき内容の図による表現 手順①：[作業]あるべき姿の確認 手順②：[作業]現状の把握 手順③：[作…

要件定義書に書くべき内容 要件を定義するとは？ 要件の段階的詳細化が重要 要件定義は、顧客とベンダでひざ詰めで行うもの 結論：要件定義書には、顧客とベンダですりあわせた要件を段階的詳細化して記載する 要件定義書に書くべき内容 要件定義書に書くべ…