システム開発の最重要工程である要件定義。機能要件・非機能要件の違いと、要求分析手法を学びます。
要件定義って、お客さんの希望を聞くだけ?
いいえ、もっと深い活動よ。
要件定義は、業務分析 → 要件抽出 → 整理・優先度付け → 文書化、の一連のプロセスなの。
要件は2種類: 機能要件 (システムが何をするか) と非機能要件 (性能・可用性・セキュリティなど)。
非機能要件って具体例ありますかぁ?
「ピーク時1000リクエスト/秒に耐える」「99.9%の可用性」「3秒以内に応答」「モバイル対応」「OWASP Top 10対策」など。
これらが曖昧だと、後から大きな問題になるの。
要求分析の手法は、ヒアリング・ワークショップ・観察・プロトタイピング・ユースケース記述など色々あるわ。
近年はユーザストーリー (As a... I want... So that...) という形式で記述するアジャイル流もあるわ。
曖昧な希望を検証可能な要件へ変える
| 曖昧な要求 | 検証可能な要件例 | 分類 |
|---|---|---|
| 商品を探せるようにしたい | 商品名・カテゴリ・価格帯で検索し、詳細画面へ遷移できる | 機能要件 |
| すぐ表示してほしい | 通常負荷1,000同時利用時、検索結果の95%を2秒以内に返す | 性能要件 |
| 止まらないでほしい | 計画停止を除く月間稼働率を99.9%以上とする | 可用性要件 |
| 安全にしたい | 管理者は多要素認証を必須とし、操作履歴を1年間保存する | セキュリティ要件 |
「速い」「使いやすい」のような形容詞だけでは合否判定ができません。利用条件、対象処理、数値、測定方法まで決めると、受入テストで確認できる要件になります。
お客さんが『いい感じの検索画面』って言ったら、そのまま要件に書いちゃダメ?
その言葉の背景を聞くの。
誰が、どの場面で、何に困り、どの状態なら成功かを確認して、機能と品質条件へ分けるのよ。
要求元、要件ID、設計、テスト項目を対応付ける要求トレーサビリティも重要です。
変更が入ったときに影響範囲と検証漏れを追跡できます。
プロトタイプを見せれば、それだけで要件確定ですかぁ?
いいえ。
プロトタイプは認識合わせの手段で、性能や例外処理まで保証する完成品ではないわ。
確認結果を正式な要件と受入条件へ反映して、関係者の合意を取るところまでが大切よ。
確認クイズ
「システムは1秒以内に応答すること」という要件は、何要件に分類されるか。
- 機能要件
- 非機能要件
- 外部仕様
- 実装要件
こたえを見る
正解: 2. 非機能要件
応答時間や可用性、セキュリティ等は 非機能要件 に分類されます。機能要件は「ユーザ登録機能」「検索機能」のような何をするかを表すものです。