要求定義・要求仕様書の作り方(山本修一郎)

IEEE830による要求仕様の構成
１．はじめに
１－１．目的
１－２．範囲
１－３．用語定義
１－４．参考文献
１－５．概要
２．要求仕様の一般的な説明
２－１．製品の背景
２－２．製品機能
２－３．ユーザ特性
２－４．制約
２－５．仮定および依存性
３．要求仕様の具体的な説明
３－１．外部インタフェース
３－２．機能
３－３．性能要求
３－４．論理データベース要求
３－５．設計の制約
３－６．ソフトウェアの属性
３－７．要求仕様の段落構成
４．付録
５．索引


ソフトウェア要求仕様=SRS(Software Requirements Specification)

１．はじめに
■目的
SRSの目的を記述し、SRSの対象読者を明らかにする
■範囲
・ソフトウェア製品の名称
・ソフトウェア製品が何を実行し、何を実行しないかについての説明
・利点、目的、目標などの適用性についての説明
■用語定義
用語が多い場合は、付録、別資料でまとめる
■概要
SRSの全体構成を説明する

２．要求仕様の一般的な説明
■製品の背景
ソフトウェア製品がシステムの一部である場合は、システムの要求項目とソフトウェアの機能を関連付け、相互関係をインタフェースとして規定する。
インタフェース
システムインタフェース
システム要求を実現するためのソフトウェア機能およびシステムに適合するインタフェースを定義
ユーザインタフェース
ハードウェアインタフェース
ハードウェア構成要素とのインタフェースを記述
ソフトウェアインタフェース
他のアプリケーションとのインタフェースを記述
通信インタフェース
LANプロトコル、ネットワーク環境とのインタフェースなどを記述
■製品機能
ソフトウェアが実行する主要機能の概要を明確に記述する。機能一覧や機能間の構成を説明する文章や図を用意する。
■ユーザ特性
製品が対象とするユーザの一般的特性として教育レベル、経験、専門知識などを記述する。
■制約

３．要求仕様の具体的な説明
ソフトウェア要求を具体的に記述する。
この要求記述に基づいて、システム設計者は要求するシステムを作成し、テスト実施者はシステムが要求を満たしていることを確認する。
■外部インタフェース
項目名、目的の説明、入力元と出力先
■機能
入力の受付と処理および出力の処理と、作成時に必要となる基本的な動作を定義する。
入力の有効性チェックなど
■性能要求
数値的に想定可能な用語を使って性能要求を記述する。
静的設備要求：サポートする端末数、同時ユーザ数、情報量
動的設備要求：トランザクション量、タスク数、処理データ量(平常時/ピーク時の指定時間)
■論理データベース要求
■設計の制約
準拠すべき標準や法制度など、設計上の制約を明記する。
■ソフトウェア属性
信頼性、可用性、セキュリティ、保守性、移植性などを検証のために明記する。
■要求仕様の段落構成

///////////////////////////////////////////////////////////////////////////////////////
要求仕様書の作成法
要求工学プロセス：①要求抽出、②要求分析、③要求の仕様化、④要求確認

4.1.4 要求抽出プロセス
・経営目標の確立
・組織構造の明確化
・関係者の明確化
・要求の明確化
4.1.5 要求抽出方法
①資料収集
②アンケート
③オープンインタビューと構造化インタビュー
※構造化インタビューとは、分析者があらかじめ想定した質問への回答を顧客から抽出する。
④現場観察
⑥事務手続き分析図を利用する
システムに求められる顧客の要求を業務フロー図や産能大式事務手続き分析図などを利用して抽出する。
⑦ユースケースやシナリオを利用する方法
⑧会議により要求を抽出する方法
議事録だけでは×。IncuiryCycleモデル(ICM)が提案されている。
議論の内容をQuestion(質問),Answer（質問に対する回答）,Reason(回答の理由)で記述し、効率的に要求を抽出し、議論の抜けを防いで会議を効率化する。
⑨ブレインストーミング

4.2要求分析
4.2.3　要求分析の確認項目
以下を確認することで、関係者が合意できる正しい要求を獲得することが目標。
・要求の必要性
システムが対象とする経営目標の実現に貢献しない要求や不必要な要求が混入していないことを確認する。要求に優先順位を割り当てることができる。
・要求間の類似性
要求が互いに重複していないことを確認する。重複する場合には、冗長な要求を削減することで最適化する。
・要求間の一貫性
要求が矛盾しないことを確認する。矛盾する要求間に優先順位を割り当てることで競合を解決できる場合がある。
・要求の完全性
必要な要求がすべて抽出されていることを確認する。完全性を確認するにはシステムの開発目標が具体的にちゅうしゅつされていることが必要。
・要求の実現可能性
技術的に開発可能であることと必要な経費や開発期間、開発要員が用意されていることが必要となる。要求の優先順位に応じて開発期間や経費を満足するように選択できる。

4.2.5　概念モデリング
①データフローモデル(ＤＦＤ)
⑤オブジェクト指向モデル
メッセージ交信関係をコラボレーション図、属性の継承や包含関係をクラス図でモデル化する。
⑩ビジネスプロセスモデル
表記法BPMNが提案されている。

///////////////////////////////////////////////////////////////////////////////////////
５．要求仕様書の確認法
　 要求分析の確認項目である一貫性、完全性、正確性、実現可能性を確認する。
要求が正しく記述できていることを関係者と合意して、設計工程を開始する前の最終的な要求仕様を確定することが目標となる。

要求仕様の確認項目
・要求の正確性
記述があいまいでないこと。
・記述の最小性
重複していないこと。
設計段階で解決するようなことまで詳細に記述しすぎていないこと。
逆に設計ができるようになるまでは詳細化されていること。
・外部環境との一貫性
・要求の完全性
必要な要求がすべて記述されていること。
経営課題や業務プロセスと要求仕様における性能要求との対応関係を確認する必要がある。
・要求の実現可能性

///////////////////////////////////////////////////////////////////////////////////////
６．要求管理
要求の変更管理手順
・要求変更依頼票の作成
識別番号、日付、変更理由、分析内容、依頼元、修正担当、要求仕様の版番号など
・要求変更の分析
影響範囲の分析、期間、工数を明確化する。利害関係者との調整。

要求の版管理
・要求変更依頼票にもどの版の要求仕様書で変更が反映されるかを記述しておく。
・複数の要求変更をまとめて「要求変更ベースライン」を構成し、この集合に対して製品を実装することが管理上望ましい。