ぼくのかんがえた要件定義のすすめかた

はじめに

次の案件が要件定義なので進め方を考えてみる。

要件定義ってよく聞くけど何するの？何が成果物になるの？というところから。
「とりあえずユースケース作ってみて～」 → プロジェクト後半で炎上みたいなパターンは避けたい。

ほぼほぼわからないので、以下の本のやり方をトレースする。
スキルレベルは自分に合わせてできるもので賄う。

私のスキル

  • 要求定義の工程経験は1回だけある
  • 要件定義はやったことない
  • 設計もあんまりやったことない
  • 詳細設計～実装までが主な経験フェーズ
  • PLは1回だけやったことがある（直前の案件）

今回の立ち位置（予測）

  • 実質PM（PMの名前は上司だが、他案件もあり殆どは入れない）
  • お客さんと話す
  • 部下は新人が1名
  • フェーズは要件定義
  • お客さんは余り情報を提示してくれないのでこちらから提案ベースで動く必要がある（らしい）

要件定義 is 何？

要件定義とは「どのようなシステムを構築するのか？」の部分。
「最終的に実現すべきことをまとめたものが成果物」となる。

進め方

RDRAをベースに考えてみる。
要件定義の成果物は後続の工程のインプットとして役に立つものになるようにする。
各成果物の整合性を保つことを意識する。
（そのうち編集する）

4つのステップで進める

以下の順番で進める。
各ステップでは対応したモデルを作成する。
システムステップまで作成したら、1.に戻る、または3.に戻り逆方向に定義を行っていく。

  1. システム価値
  2. システム外部環境
  3. システム境界
  4. システム

図1

f:id:aky100200:20201102095400p:plain
4つのステップの関係
※「モデルベース要件定義テクニック」より引用

各ステップでやること

以下のモデルを作成し、ブラッシュアップを行っていき整合性を保たせる状態にする。

  1. システム価値
    1. 関係者（外部システム）を把握する
      • コンテキストモデル
    2. 問題、課題を把握し要求、要件を明らかにする
      • 要求モデル
  2. システム外部環境
    1. 業務の流れもしくは作業を明らかにする
      • 業務モデル
      • 利用シーンモデル
    2. 業務で使われる概念を共有する
      • 概念モデル
  3. システム境界
    1. システムとの接点を明らかにする
    2. 上記接点での入出力情報を明らかにする
      • 画面・帳票モデル
    3. 外部システムとのやりとりと情報を明らかにする
      • イベントモデル
    4. 上記のやり取りをルール化する
  4. システム
    1. システムで扱う情報を明らかにする
    2. システムが提供する機能を明らかにする
      • 機能モデル

各ステップの成果物

私は前案件でPlantUMLを用いてUMLを作成していたのでそれをベースに行っていきたい。

PlantUMLの利点として、以下を考えている（私はパワポが苦手）。

  • Git管理しやすい
  • コードベースなので修正が容易である
  • 誰が書いても同じ図ができる（パワポ技術が不要）

PlantUMLでのRDRAモデル作成については以下を参考にする。

2つ目の記事は著者である神崎先生からもおススメをもらっているよう。

成果物＆準備するもの

進めていく中で編集予定。
まず必要なもの。システム境界までは作成していきたい。

  • プロジェクトのキックオフ資料（メンバーへの説明用）
  • RDRAの進め方についてまとめた資料（メンバーへの説明用）
  • WBS（メンバーと上司へタスクの説明用）
  • コンテキストモデル
    • 責務は別資料にまとめる？図とExcel？
  • 要求モデル
    • ここはまずはExcelベースでもいい気がする(要望、要求、要件)
  • 業務モデル
    • いわゆる業務フロー図を作成
  • 利用シーンモデル
    • これもExcelでいいかも
  • 概念モデル
  • ユースケースモデル
  • 画面・帳票モデル
  • イベントモデル
  • プロトコルモデル

おわりに

進めていく中で各ステップの詳細やモデルを調べたら追記していく。
自分の知見になるように進める。

参考