システム要件定義・ソフトウェア要件定義

ねらい

開発の出発点である要件定義を学びます。このレッスンを終えると、システム要件定義とソフトウェア要件定義のタスク、機能要件と非機能要件の区別、業務分析に使う代表的な手法を説明できるようになります。

システム要件定義

システム要件定義では、システムの境界の定義、システム要件の定義、システム要件の評価、共同レビューを行います。利用の状況と運用シナリオに基づいて、APIやGUI、インタフェースファイル、サービスといった機能的な境界を定め、システム化の目標と対象範囲（対象業務、対象部署）をまとめます。

定義する要件は多岐にわたります。

1. 機能の要件として、システム機能仕様を定めます。
2. 能力の要件として、レスポンスタイムやスループットなどの性能要件を定めます。
3. 業務・組織・利用者の要件として、業務処理手順や入出力情報要件、操作要件に加え、データベース要件、セキュリティ要件、移行要件、テスト要件、運用要件、保守要件、障害対応、教育・訓練、費用まで定めます。
4. その他の要件として、実行環境要件や周辺インタフェース要件、品質要件、UXデザインを考慮した要件、利用可能な品質かを確かめる適格性確認要件を定めます。

「何をするか」を定める機能要件と、性能・信頼性・セキュリティのような「どの水準で動くか」を定める非機能要件の区別は、試験でも実務でも基本です。

ソフトウェア要件定義

システム要件を受けて、システムを構成する個々のソフトウェア（ソフトウェア構成品目）に求められる機能、能力、インタフェースを定めるのがソフトウェア要件定義です。業務モデルと論理データモデルを作り、業務モデリングとデータモデリング、画面設計、帳票設計、伝票設計、インタフェース設計、セキュリティ実現方式などを決めます。利用者の要求は、ユースケース、ユーザーストーリー、シナリオといった形で捉えます。

要件の評価とレビュー

定義した要件は、実現可能か、上位の要件と合致しているかを評価し、取得者（発注側）と供給者（開発側）が共同でレビューします。要件と成果物の対応を両方向にたどれる性質を双方向の追跡可能性（双方向のトレーサビリティ）といい、対応表はトレーサビリティマトリクスで管理します。「この要件はどの設計に反映されたか」「この機能はどの要件から来たか」をいつでも確かめられる状態に保ちます。この双方向の確認は、要件と設計の間だけでなく、設計と実装の間でも同じように行います。

業務分析や要件定義に用いられる手法

DFDが「データの流れ」、E-R図が「データの構造」、UMLのユースケース図が「利用者とのやり取り」というように、それぞれ映すものが違います。目的に合わせて選ぶことが分析の要点です。

例題

次の問いに答えてください。

問1 「注文の一覧を検索できること」のような、システムが何をするかを定める要件を何といいますか。

問2 業務プロセスをデータの流れに着目して図に表す手法は何ですか。

解答と解説

問1の答えは機能要件です。これに対して、レスポンスタイムやセキュリティの水準のような「どの水準で動くか」を定めるものが非機能要件です。

問2の答えはDFDです。プロセス、データフロー、データストア、源泉の要素でデータの流れを描きます。データの構造を表すE-R図と使い分けます。

応用

本試験を意識した問題を解いてみましょう。

問 要件とその実現物との対応関係について、要件から成果物へ、成果物から要件へと両方向にたどれる性質を表す用語はどれでしょうか。次の中から選んでください。

1. 双方向の追跡可能性
2. 適格性確認要件
3. ユースケース
4. プロトタイプ

解答と解説

答えは1の双方向の追跡可能性（双方向のトレーサビリティ）です。要件の抜け漏れや、どの要件にも対応しない無駄な成果物を発見でき、変更の影響範囲の調査にも役立ちます。対応表はトレーサビリティマトリクスで管理します。2の適格性確認要件は、開発するシステムが利用可能な品質であることを確認する基準のことです。3のユースケースは利用者とシステムのやり取りを定義する手法、4のプロトタイプは試作品で仕様を早期に確かめる手法であり、どちらも対応関係をたどる性質を表す用語ではありません。