要件定義 の履歴(No.2)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 要件定義 へ行く。
  • 1 (2022-12-08 (木) 22:02:35)
  • 2 (2023-03-19 (日) 14:25:36)
  • 3 (2023-04-29 (土) 12:51:36)
  • 4 (2023-07-24 (月) 12:08:09)
  • 5 (2023-08-21 (月) 14:49:35)
  • 6 (2023-08-27 (日) 21:37:19)
  • 7 (2023-10-10 (火) 11:24:12)

---

→上流工程一般

→基本設計

サブトピック†

• 要件定義書の一般的な項目

一般†

• ChatGPTに要件定義をお願いしたらハンパなかった | DevelopersIO 2023.3

• 要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経 2022.12
  • 要件定義だけを切り離して専門化するのは難しい、という話

• IPA資料・超上流から攻めるIT化の原理原則 17カ条 2022.12
  • 原理原則［１］ユーザとベンダの想いは相反する
  • 原理原則［２］取り決めは合意と承認によって成り立つ
  • 原理原則［３］プロジェクトの成否を左右する要件確定の先送りは厳禁である
  • 原理原則［４］ステークホルダ間の合意を得ないまま、次工程に入らない
  • 原理原則［５］多段階の見積りは双方のリスクを低減する
  • 原理原則［６］システム化実現の費用はソフトウェア開発だけではない
  • 原理原則［７］ライフサイクルコストを重視する
  • 原理原則［８］システム化方針・狙いの周知徹底が成功の鍵となる
  • 原理原則［９］要件定義は発注者の責任である
  • 原理原則［１０］要件定義書はバイブルであり、事あらばここへ立ち返るもの
  • 原理原則［１１］優れた要件定義書とはシステム開発を精緻にあらわしたもの
  • 原理原則［１２］表現されない要件はシステムとして実現されない
  • 原理原則［１３］数値化されない要件は人によって基準が異なる
  • 原理原則［１４］「今と同じ」という要件定義はありえない
  • 原理原則［１５］要件定義は「使える」業務システムを定義すること
  • 原理原則［１６］機能要求は膨張する。コスト、納期が抑制する
  • 原理原則［１７］要件定義は説明責任を伴う

• 要件定義〜システム設計ができる人材になれる記事 - Qiita 2020

• 要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita 2022.8

• 過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】 2021.10

• ITエンジニアが要件定義がより上手に出来るようになるためには何を意識すると良いですか？ 2021.7

• 非機能要件の定義 2020.7

• 要件定義〜システム設計ができる人材になれる記事 2020.1

• こんな時代だからこそ要件定義の重要性を思い出せ！ 2019.6

• 私が本当に業務で行った要件定義の作成手順 2017.7.31

• 「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する 2014.1.29
  • システムの要件定義のキモは
    • 必要なこと
    • やりたいこと
    • やらないこと
  • をうまく選別することにあります。
  • Excel云々の話は、おそらく「やりたいこと」に分類できる

• 仕様変更に強い開発をするための、ヒアリングモデル 2012.3.27
  • ヒアリング時には「システム開発の目的」と「具体的なシステム要件」、両方を聞く必要があります。

• いわゆる仕様と業務例外について 2012.2.19

• ユーザーニーズを基にシステムを作るな 2010.11.21
  • ユーザーニーズは偶然により決定される
  • ユーザーニーズはシステム要件に変換する段階で矮小化される
  • ユーザーニーズはユーザーすら分からない
  • ユーザーニーズ半減・半増の法則
  • ユーザーニーズはシステムを納入したときに明確になる

• 業務機能の洗い出しと業務フローの作成を同時に実施してはいけない 2010.8.31
  • ユーザーは業務機能のレベルやサイズを意識せずに回答するので、ITエンジニアにとって業務の理解や整理が難しくなるからである。
  • ユーザーに業務フローをヒアリングしながら、業務機能のレベルやサイズをそろえるのは難しい。そこでユーザーへのヒアリングは、業務機能を洗い出すためと、業務機能間の関連やフローを確認するためという目的別に分けて行う。

• 失敗しない要件定義、3つのポイント 2010.5.18
  • 要件定義がうまくいかないパターンとして、
    • なかなか要件定義が終わらない
    • 後工程で要件の抜けが見つかる
    • 何でも要件に盛り込んでしまい、プロジェクトの工数などに無理が生じる
  • という3つのケースを挙げる
  • 要件定義プロセスに、一般的なプロジェクトマネジメント手法は通用しないと理解しておくこと。要件定義は「管理対象と作業内容そのものを決める」プロセス。ゆえに一般的なマネジメント手法のような定量的な管理だけでは、内容的に不十分なまま作業を終えることになりかねない。

• 要件定義書レビューの一般的観点
  • 項目に漏れがないか
  • 機能要件、非機能要件の過不足
  • 役割、責任の分担（例：データ移行は誰がやるか）
  • しないと決めたことを明記しているか
  • 文体、用語の統一

• 検討項目管理票
  • 意外と作らないことがあるが、要件定義作業中に検討した各要件ごとに、どういう議論を経てどういう結論になったかを記録しておくため、検討項目管理票は重要。最終的な要件定義書に検討中の経緯や、要件から外された項目については文書に書かれていないことが多いが、何らかのかたちとして残すべき

• 要件定義の勘どころ 2010.2.7
  • 要件定義は詳細なシステムの機能を決めるための入力情報となります。そのためにはWhatとWhyが記述されていること
  • このシステムの目的（価値）は？
  • どのような責務を持つ人に使われるのか？
  • どのような外部システムとかかわるのか？
  • システムはどのような使われ方をするのか？　
  • システムとの接点は？
  • その時の入出力情報は？
  • システムに必要な機能は？
  • その機能が使用するデータは？

• みんなが悩む要求管理 いまさら聞けない要求管理の基本 2009.11.14

• 要件定義をロジカルシンキングで解析する 2009.5.2
  • 要望を単なる箇条書きの仕様と見なすのではなく、構造化された一つのモデルとして提示する能力が必要になってくる。
  • 今までUML、DOAなど色んなモデリング手法を学習してきたが、要件定義では、結局、ロジカルシンキングを中心として論理で整理するのがBetterな気がしている。
  • 仕様とは一つの仮説であり、一つの論理的なモデル。
  • 要望をロジックツリーで整理して、問題と解決策へ昇華できれば、解決策を仕様に落としてしまえばいい。

• 画面設計とか外部設計とか、もうやめようよ 2009.1.30
  • 「画面をどう実現するかを考えて要件分析する」というのは本末転倒。だけど、最初に画面を固めるとそうなりやすいし、結果として工数増加につながるよ、と

• 顧客の膨らむ要望にいかに対処すべきか 2008.9.4
  • 要件定義とは以下を実行することである。

      1. 顧客のあいまいな要求を把握
      2. 本プロジェクトでやれることを決定
      3. システムの機能要件・非機能要件への落とし込み
      4. 要件定義書（仕様書）の作成と合意

  • 追加要求は、顧客の要求の絞り込みを十分に行っていないために発生する
  • 追加要求をできるだけ減らすには、要件定義プロセスの最初の段階において「やる」「やらない」「後でやる」をしっかりと決めなければならない
  • 「やる」ことが決まれば、次は「顧客に機能を捨てさせる」ことを考えさせる。たいていの顧客は「機能はあればあるほどよい」と思うことが多く、システムは「結果として役に立たない機能が満載」になる可能性が高い
  • 「このサブシステムにはこの帳票が本当に必要か」と、問題を一段高いところから眺めることで、「実は、ほかの帳票で代用可能だ」「ほかの帳票と比べて、優先度が低いので後回しにしよう」など、顧客に冷静に判断してもらうことが可能になります。
    • 【疑問】そもそも最初の段階で上がってきてない要件は捨てさせることもできないが？
  • いま議論している対象の重要度はどのくらいか」を判断するための枠組みとして、1・5・10ルールというものがある。10以上なら必要になる
  • 変更管理で最も大切なのは、「変更要求の評価」と「変更要求の認可」です。すなわち「この変更は重大な変更なのか」「この変更は誰が許可するのか」を判断できるようにしっかりと手順にしておくことです

• 要件定義の遅れ 2008.9.2
  • 前回の反省を生かして「利用部門の要件確定を待っていても仕方がない」と，システム利用部門の担当者から積極的に要件を引き出すことにした。
  • この際に大きな武器になったのが，Excelの表だ。あらかじめ「業務要件とシステムとの関係」を示した表を作っておき，利用部門との打ち合わせで決まったことやこれから検討すべきことを書いておくことにした
  • さらに「なぜその機能を採用しないのか」といった，要件の背景や経緯も，利用部門の担当者に聞き，書き留めておくことにした

• .NETアーキテクトの実用プラクティス 2008.8.27

• 業務フロー図の書き方 2008.7.14
• 過剰な要求を絞りこむ知恵 2008.7.3
  • 業務内容分析シートで業務にかかる標準時間や難易度を整理し，最終的には「労力」と「効果」を評価する
  • 要求を業務フロー図とヒモ付けて眺めてみる→浮いた要求がないかと考えてみる。
  • 洗い出した要求を「内部統制に関連するもの」「効率化に寄与するもの」「情報系システムに関係するもの」「業務改革に寄与するもの」――などのテーマに分けてみる。一つの要求が複数のテーマに重複していても構わない。そのテーマ単位で優先度を考える
  • 処理の発生頻度を聞く。処理の頻度が高ければ通常処理と判断し，その要求はシステム化した方がよい。逆に低ければ運用でカバーしてもらう
  • 要求をシステム仕様に取り入れるデメリットを問いかける。システムに実装する要求が増えると，一般にスケジュールは長くなり，コストはかさむ。できればシステム企画の段階で，スケジュール遅延の許容範囲を合意しておきたい。2次開発や3次開発に先送りするなどの交渉があり得る。

• 見積りマニュアル策定、要件定義書の標準化 2008.5.15
  • 精度向上のための施策には大きく分けて「標準化」「個人の知識・経験の向上」「経験者のレビュー」の3つがある。どの施策が最も効果的かは、その組織が現在直面している課題によって異なる。自社の状況に応じて、上記3つの施策のバランスを調整して実行すること重要である。

• 今日から始める設計ムダ取り健康診断のポイント 2008.4.21

• 仕様はどうして決まらないのか？ 2008.3.27
  • （1）業務オーナーを決めろ
  • （2）ステークホルダーの整理
  • （3）whatとhowの分離
    • 本当に＜何をすべきか＞というwhatにフォーカスすることが重要

• オフショアのERPコンサルタントvs．日本人プロジェクトメンバー 2008.2.22
  • 「欧米ではERPの標準機能を使うのが常識」「日本ではアドオンを多く実現することが常識」といえましょう。
  • ERP がパッケージソフトであることを考えると、テスト済みのERP標準機能を使った方が低コスト、高品質を実現できるという意味で、欧米の常識の方が技術的な視点からは優れているといえるかもしれません。ただ、日本のお客さまが欲しているのはアドオンによる高機能のシステムであるわけですから、このような、いわゆる「べき論」を日本において論じても意味がないことが多いのです。
  • 良しあしの議論は置いておくとして、「欧米と日本とでは常識が異なる」と私は理解しています。

• キミの設計にトレーサビリティはあるか 2008.2.14
• IT戦略は情シスが立案するもの 2008.2.12
• 性能要件はユーザーが決めると思ってはいけない 2008.2.6
  • 性能要件はアプリケーション処理方式が固まらない限り，定義できない。最初からユーザーが「はい，これが要件です」とポンと出せるものではないのである。業務パターンや処理方式が現行システムと全く同じシステムを構築する場合は性能要件を早々に決めてしまうことも可能だが，実際の案件でそんなことは滅多にない。前提とするミドルウエアなどのアーキテクチャが変われば，現行システムではいくつかに分かれている処理が一つになったり，その逆になるケースが必ずある。要件定義フェーズでのヒアリングはあくまで「現行システムにおける参考値」もしくは「ユーザーの要望」以外の何者でもない。

• 課題山積みの要求仕様確定 2007.12.3
  • 顧客との仕様確定過程で、見積もりや契約の前提条件が崩れそうになったら、すぐ実態を上申しなければならない。特に仕様が増えても納期の変更ができず、予算の追加も認められず、そのまま進めば大赤字、大事件につながることが懸念されたら、契約自体の見直しも必要になるので、すぐ幹部に知らせ今後の対策をどうするか一緒に議論すべきである。顧客との交渉のレベルを上げることも必要になろう。要は手遅れにならぬことである。

• 定まらない要件、ユーザーからの無茶な要求
• ヒアリングの実践ノウハウ
  • ヒアリングは司会と書記でペアを組んで行う
  • キーパーソンを把握しシステム化の目的を明確にする
  • 経営トップから各現場の社員に周知徹底してもらう
  • 「現状の業務の大まかな流れ」や「現状の業務で感じている問題」などの基本的な質問を書いたアンケート用紙を回答例付きで作成し，事前にユーザー企業に配って回答してもらうのも，問題点や要求の分析に役立つ。この方法は，会議の議論をスムーズにする利点もある。アンケートに回答することで，ユーザー企業の担当者が自分の考えを整理でき，問題意識を持って会議に臨めるからだ。
  • 聞くべき項目をリスト化しておくこと
  • FURPS＋
    • Functionarity:機能要求
    • Usability:使いやすさ
    • Reliability:信頼性
    • Perfomance:性能
    • Supportability:保守性
    • Plus:その他（開発環境、コンポーネント、ネットワーク、ハード、法律etcの制約)
  • キーパーソンが参加する全体会議は，ユーザー企業内ではなく，なるべく研修所やホテルの会議室などに場所を移して実施する。
  • ユーザー企業の現場担当者との個別ミーティングでは，上司と部下は別々にヒアリングする
  • だらだらを防ぐ
    • ヒアリングの場では，冒頭で「この会議は何のために行うのか」，「何を決めるのか」を明確に宣言する。
    • 終了時間までにまとまらなければ，再び集まってもらうことになると警告を発しておく。
    • 出席者もなるべく少人数に絞り込む。
  • ER図やDFD，UML図，業務フロー図を作ってユーザに確認してもらう
    • なるべくユーザーと議論しながらその場で図を作成すること
    • できる限り詳しく図の意味をユーザーに説明すること。
    • ミーティングで図の意味を説明したり，図をユーザーに確認してもらう際に分かりやすい説明用の文章を付ける，など

• DOA

• UMLモデリングの基礎 2006.12.11

• 仕様という言葉の罠を回避する 2006.9.27

• 三要素分析法の解説@IT
  • ここでいう三要素とは「業務」「機能」「データ」

• MDA（モデル駆動型アーキテクチャ)解説

• マインド・マップとUML

• Concept Map