要求分析とは、ソフトウェア開発の初期段階で行われるもので、 何をソフトウェアで実現すべきかを明らかにする作業です。
ユーザに満足してもらえる実現可能な要求モデルを作り、 ソフトウェア設計者が正確に判断できる要求仕様書としてまとめます。
「どう作るか」ではなく「何を作るか」を決める工程です。 ここを間違えると、どんなに上手に作っても、間違ったものが出来上がります。
いちばん失敗が高くつく工程です。 第3回で見たとおり、上流の誤りは下流で見つかるほど修正費用が跳ね上がります。 要求の誤りをテスト段階で見つければ、要求・設計・実装・テストのすべてをやり直すことになります。
| 仕事 | 中身 |
|---|---|
| 獲得 | 問題に関連するすべての情報を収集すること |
| 表現 | 得られた情報を論理的な要求モデルに変換し、仕様として正確に記述すること |
| 検証 | 要求モデルや仕様に間違いがないことを確かめること |
この 3 つは次回（第5回）で詳しく扱います。本日はまず、 何を書き分けるべきかを押さえます。
機能仕様（機能要求）
「システムは……できる」という積み上げ式の仕様。
非機能仕様（非機能要求）
システムの機能が持つべき性能・信頼性・セキュリティ・環境条件・制約条件など。
| 要求の文 | どちらか |
|---|---|
| 利用者は学籍番号とパスワードでログインできる | 機能 |
| 成績を CSV 形式で出力できる | 機能 |
| 同時に 300 人が使っても応答は 3 秒以内である | 非機能（性能） |
| 年間の停止時間は 8 時間以内である | 非機能（信頼性） |
| 通信はすべて暗号化される | 非機能（セキュリティ） |
| スマートフォンのブラウザで動作する | 非機能（環境条件） |
| 既存の学務システムと連携できる | 非機能（制約条件） |
見分け方のこつ。
「システムは○○できる」と書けるなら機能仕様です。
「どのくらい速く／確実に／安全に」を言っているなら非機能仕様です。
非機能仕様は忘れられやすく、しかも後から足すのが非常に難しいという性質があります。
性能やセキュリティは、設計の骨格に関わるからです。
「あとで速くしよう」はたいてい失敗します。
要求仕様書とは、要求モデルによって記述された文書です。 標準的な機能仕様書は、次のような構成をとります。
| 章 | 内容 |
|---|---|
| 1. 目的と範囲 | 1.1 目的 1.2 範囲 1.3 用語定義 |
| 2. 用途と機能 | 2.1 用途 2.2 機能 2.3 利用者の特性 2.4 全般的な制約 |
| 3. 詳細要求 | 個々の機能要求、外部インタフェース、性能要求、設計制約 |
「用語定義」が置かれている理由。 同じことばを、ユーザと開発者が違う意味で使っていることが本当に多いからです。 「登録」「承認」「顧客」── どれも現場ごとに意味が違います。 用語をそろえないまま進めた要求分析は、必ずあとで破綻します。
「1.2 範囲」では、やらないことも書きます。 何が含まれないかを明示しておかないと、開発の途中で際限なく要求が増えていきます （スコープクリープ）。範囲の記述は、開発側を守るためでもあります。