第3章:開発計画と要求分析

第 3 章:開発計画と要求分析
宮川 拓也
2005.5.27
ソフトウェア開発のプロジェクトを始める前に，
「何を」作るかと「なぜ」作るのかを明らかにす
る必要があり，そのために要求分析を行い開発計画を策定する．
3.1 何を作るか
ソフトウェア開発を始めるには，何を作るかがまず決められなければならない．
「分析」とは通
常，
「要求分析」を意味するものと考えられる．ここで「要求」とは，構築すべきシステムに対して
その利用者や関係者が明示的にあるいは潜在的にもつものをいう．しかし，何を作るかを決める前
に，そもそも開発に着手すべきか，あるいは少なくとも開発の検討を開始すべきかについて，意志
決定がおこなわれなければならない．その意志決定をおこなうにはまた，どんなシステムであるか
が想定されていなければならない．
このような意味で，どのようなソフトウェアを開発すべきか (あるいはすべきでないか) を決定
するには，そのソフトウェアがどのような価値をもたらし，その開発にどれだけの費用がかかるか
を予測しなければならない．
ソフトウェア工学は何を作るかに大きな自由度があり，また利用者と開発者とのコミュニケー
ションが持続的に必要であるという特性があるので，要求分析というフェーズが特に重要である．
3.2 システム化計画
3.2.1 実際的な開発標準工程における初期フェーズ
企業で実際に使われている工程では，その最初のフェーズを要求分析ではなく，システム化計画
と呼ぶことが多い．ソフトウェア開発計画を進める際に考慮すべき要因としては，要求分析の結果
以外に，次のようなものが重要となる．
• 効果，利益
• コスト
• 期間，スケジュール
• 資源
• 経営，組織，市場，制度，社会などによる制約
1
したがって，システム開発の当初にすべきことは，これらの要因を総合的に判断したうえで，プ
ロジェクトを実施するか否かの意志決定を行うことである．
システム化計画の出力，たとえば「システム計画書」には，標準的に次のような項目が記述さ
れる．
• 背景
• 開発目的
• 対象領域
• 業務の現状
• すでにシステム化されている部分の現状
• 新たに開発すべきシステムの概要
• 効果
• 制約条件
• 開発・導入計画
• 開発費用の見積り
• 必要とする資源
計画に時間をかけ過ぎることは，とくに日本におけるソフトウェア開発プロジェクトに往々にし
てみられる傾向で，生産性を阻害している可能性がある．その他にも，つぎのような問題点があり
うる．
1. よいインストラクタの数は不足しており，その育成には手間がかかる．
2. 集団作業への不参加者に作業結果を伝達する必要があるが，決定のプロセスまで含めた微妙
な情報を伝えることには，困難が伴う．
3. 手間のかかるものなので，小規模システムの場合どうするかは，別の問題として残る．
4. 作業の結果，問題点の見事な整理ができたり理想的なシステムの姿が構成されても，以降の
開発や実現に直接つながりにくいケースが往々にしてある．
3.2.2 コスト見積り
通常取られている開発費用の見積りの方法は，
1. 開発するソフトウェアの規模を，なんらかの方法で見積もる．
2. ソフトウェアの規模から，なんらかの見積もり式で必要工数 (人月) を算出する．
3. 工数から，開発期間と投入要員数を決める．
というものである．
機能点 (function point) 数を数えるという方法が，ある程度実践されている．
2
3.3 要求分析
3.3.1 要求工学
構造的プログラミングが華やかであった 1970 年代半ばに，要求工学という名のもとで，いくつ
かの技法が提唱された．
これらはその後，構造化分析/設計技法に集約されていったが，1980 年代の後半に脚光を浴びた
CASE ツールによって，再注目されるようになった．さらに，1990 年代に入ってから要求工学に
関する国際会議 (International Conference on Requirements Engineering) が定期的に開かれるよ
うになり，研究分野としても改めて隆盛を迎えている．
3.3.2 要求分析の考え方
要求分析/定義の作業は，大きく 2 つの部分に分けて考えることができる．前半は，ソフトウェ
アの発注者が，そもそも何を意図し何を要求するのかを，明確にしていくプロセスである．後半は
その分析を基に，決まった仕様記述モデルあるいは仕様記述言語によって，仕様をきちんと記述す
る作業である．
この要求分析の考え方にはさまざまなものがあるが，3 種類の型に分類して考察する．
1. 要求抽出型 (図 3.3)
初めにユーザのニーズや意図があるものとし，それを要求として抽出する作業を要求分析の
中心に置く．ユーザへのインタビューが基本的な方法のひとつになるが，その際，シナリオ
を用いる手法がよく用いられる．それをより具体的に記述したものはユースケース (use case)
とも呼ばれ，システムの使用を定める基として使われる．
この方法は，ユーザへのきめの細かい対応が可能なことが特徴で，またシステムの利用イメー
ジも早い段階で明確になる．弱点は，要求を引き出す相手に依存することが大きい点で，人
が変わると要求が大きく変わる可能性がある．
2. 目標指向型 (図 3.4)
システムを開発するのはなんらかの目標 (goal) を達成するためであるはずだから，その目標
を構造的に明らかにすればシステムへの要求が明確になるという考え方である．目標を意識
的にもつのはユーザだから，ユーザへのインタビューは自然な方法であるが，目標の分解・
統合をかなり系統的，客観的におこなうこともできる．
この方法の特徴は，要求抽出型より全体的に整合性のとれた要求の集合が得られる点にある．
しかし弱点は，この方法にもとづいて作られたシステムが，定めた目標に特化した構造とな
りがちであり，少し問題が変わった場合の柔軟性に欠けることが起こりがちな点にある．
3. 領域モデル型 (図 3.5)
初めに対象とするドメイン，すなわち問題領域，適用分野，業務，対象世界，などの言葉で
呼ばれるものがあり，それをなんらかのモデルに写像するという立場をとる．モデル化の手
法としては，オブジェクト指向モデルなどが用いられる．
この方法は，一連の製品系列 (product line) 上の多くの少しずつ異なるシステムの要求分析
を一度におこなう際に有効である．また，要求の変化に柔軟に対応しやすいという特徴もも
3
つ．一方，この方法の弱点は，システムのイメージがなかなか明確にならず，問題領域内に
作られるべきシステムの内部と外部の境界がはっきりしない傾向がある点である．
これらの方法は，必ずしも独立に実施されるわけではなく，これらを組み合わせて用いるほうが
有効である場合が多い．
3.3.3 要求の種類
要求には機能要求と非機能要求があり，非機能要求には性能，使いやすさ，安全性 (security)，
保守性，可搬性 (portability) などがあるといわれる．
機能要求の中でも，要求どうしが衝突し相容れないことはしばしば起こり，それをいかに調整す
るかは要求分析の重要課題のひとつである．非機能要求はさらに，そのような衝突を起こしやす
く，トレードオフの関係を明確にしておくことは重要である．
3.4 仕様
要求を厳密に定義し記述したものが，要求仕様である．
3.4.1 仕様と要求の関係
仕様が要求を厳密に記述したものとすると，仕様と要求は実質的に同じものとみなされるが，こ
れをより明確に区別する考え方もある．
3.4.2 何を仕様として表わすか
要求に機能要求と非機能要求があるのに対応し，仕様にも
• 機能仕様
• 性能仕様
• 信頼性仕様
• インターフェース仕様
などが考えられる．
多くの場合，仕様記述は簡単ではない．その理由には次のようなものがある．
1. 対象とする問題領域が，数学の世界のように明確な論理性をもたない．
2. 「ユーザ」自身が，何をやってほしいか明確に意識していないか，意識していてもきちんと
表現できない．
3. ユーザの意図が変化する．あるいは，外部条件の変化により意図が変わらざるを得ない．
4. 対象となる問題が大きく複雑すぎて，どう記述したらよいかわからない．
4
3.4.3 仕様を誰が書き誰が使うか
要求を仕様として書く必要を感じる人間には，2 種類ある．ひとつはその要求を他人に伝えて，
ソフトウェアの製作を依頼する発注者である．もうひとつは，ソフトウェアを製作する人間であり，
発注者の意図を確認する目的や，市場型の製品の場合はその製品の機能と動作を明確に示すために
記述する．記述された仕様は，後の設計開発過程ではその出力 (設計書やプログラム) が満たすべ
き要求条件として働く．
仕様は発注者と受注者の間の契約としての性格もあり，これが往々にして仕様記述をさらに難し
くしている．
仕様を読む人間としては，ユーザ，設計開発者，検査者が考えられる．
3.4.4 よい仕様の条件
よい仕様は，以下のような条件を満たさなければならない．
• 正当性
内容に自己矛盾がないという整合性 (無矛盾性) と，もれなくすべてが記述されているという
完全性とを含む．
• 厳密性
曖昧なところがないこと．内容が一意に定まること．
• 読みやすさ
読んで理解しやすいこと．
• 検証可能性
整合性が検証できること．あるいは完全性をなんらかの方法でチェックできること．また，仕
様にもとづいて開発されたシステムが，その仕様を満たすかどうかの検証が可能であること．
• 実現性
具体的な実装が可能であること．
しかし，問題なのは，これらの条件の間に，往々にしてトレードオフ関係が存在することである．
5