前に書いた
の続き、まずは、開発の一番初めの要求分析から。
■開発全体の位置づけ
要求分析は一番初めに行う作業。ユーザー側の場合、一番初めの作業としてはRFPを作り、ソフト開発会社候補を呼んでオリエンテーションするっていうのがあるけど、そこまでも含めてしまえば、要求分析が最初ということでいい。
■このプロセスの内容
開発の目的から初めて、開発するシステムに関係する人々（ステークホルダーという）の要求をまとめ、システムの要件に落とし込んでいく。
システムが満たすべき要件で記述される内容は、大きく２種類分けられる。
１つはそのシステムが行うべき各業務の定義。各業務は入力と出力で定義され、その入力から出力への変換を「プロセス」と呼ぶ。「ある入力がそろったとき、プロセスが実現すると、こんな出力が得られる」というのを機能とみなすと、入力→プロセス→出力で定義された、このシステムは、機能の塊といえるので、この入力→プロセス→出力での要件の定義を「機能要件」という
機能要件以外の要件を非機能要件という。入力→プロセス→出力は同じなのだが、それを１時間でやればいいのか、１分でやってほしいのかでは、大きく違う。このような時間、容量、負荷、またセキュリティなどが、非機能要件にあたっている
ぶっちゃけまとめると、
機能要件：入出力で定義される要件
非機能要件：それ以外
と思ってくれちゃっていい。
■方法論
トップの目的から、次工程の外部設計工程までを導く方法論として、ゴール指向要求分析のKAOSがある。ただ、これは日本の実務ではあまり言われない。
昔は、機能要件定義として、昔は構造化手法分析を行った。DFDとER図を使って行う手法。今はオブジェクト指向分析でUMLを使うほうが多いのかな？
システムは、入力データ、出力データ等のある一瞬のデータ構造を表現する構造図と、入力から出力への状態遷移（＝プロセス）を表現する振る舞い図がある。（ちなみに、構造化手法において、振る舞い図はDFD、構造図はER図になる）。
UMLでは、振る舞い図として、ユースケース図が使われ、これを詳細化してアクティビティ図が作られる。構造図としては、クラス図があり、クラス図の値部分を具体的に示したオブジェクト図も場合によっては使われる。
また、派生開発ではUSDMが使われる。
ゴール指向、構造化分析、オブジェクト指向分析は別エントリで説明する。USDMはあんまり知らない。たしか、この本の清水氏が第一人者だったはず・・・
■規格
要求分析の国際規格として、IEEE830がある。
国内では、機能要件は、「機能要件の合意形成ガイド」がある
これは要求分析より一歩進んだ、外部設計レベルまで書いてあるけど、とにかく機能要件についてまとめたもの
非機能要件に関しては、「非機能要求グレード」
がある。
■この工程の成果物
要件定義書
具体的な項目とかは、前のシリーズ
で書いた。
その中で、富士通のCompornentAAは、今は公開していない（業界標準の「機能要件の合意形成ガイド」を一時公開していた。ただしSDEMの中では生きているかも？）
■アカデミック的には
アカデミックの人と実務の人があわせてつくったのがREBoK
 | 要求工学知識体系 第1版 情報サービス産業協会REBOK企画WG 近代科学社 |
 | 要求工学実践ガイド: REBOKシリーズ2 情報サービス産業協会REBOK企画WG 近代科学社 |
要求分析の人の教科書としては、確かこれだった気が・・・
 | 要求工学―プロセスと環境トラック (ソフトウェアテクノロジー) 淳, 大西 共立出版 |
あと、この本、なんか有名らしい（読んだことない）
 | ソフトウェア要求 第3版 カール ウィーガーズ；ジョイ ビーティ 日経BP |
山本先生、本だしてたんだ！
 | 要求開発の基礎知識 要求プロセスと技法入門 山本 修一郎 近代科学社Digital |
具体的なやり方については、「ゴール指向」「構造化手法」「オブジェクト指向」で詳しく書く予定。今日はここまで。
アクセス
トータル
ランキング
