要件定義の進め方 — 機能要件と非機能要件を整理する
設計のスタート地点は「何を作るか」を明確にすることです。 これが曖昧なまま設計に入ると、テーブル設計もAPI設計も「たぶんこうだろう」という推測の上に成り立つことになり、後から覆ります。
この章では、要件定義で整理すべき項目と、実務でよくある抜け漏れパターンを紹介します。
学習者要件定義って偉い人がやるイメージ…。エンジニアもちゃんと考える必要があるの?
機能要件と非機能要件
要件は大きく2種類に分かれます。
| 種類 | 説明 | 例 |
|---|---|---|
| 機能要件 | システムが「何をするか」 | ユーザー登録ができる、商品を検索できる |
| 非機能要件 | システムが「どう動くか」 | レスポンス3秒以内、99.9%稼働、同時1000ユーザー |
駆け出しのうちは機能要件ばかりに目が行きがちですが、非機能要件の抜け漏れが本番障害に直結することは珍しくありません。
要件の洗い出し方
このセクションは現在執筆中です。
- ユースケースから逆算する(「ユーザーが〇〇するとき」の列挙)
- 画面モックがあるなら画面単位で洗い出す
- 管理者側・バッチ処理・通知など、ユーザーから見えない要件を忘れない
よくある抜け漏れパターン
このセクションは現在執筆中です。
- 削除の仕様(論理削除?物理削除?関連データはどうする?)
- 権限(誰が何をできるか、ロールは何種類か)
- エラー時の振る舞い(決済失敗したらどうなるか)
- メール・通知の要件(いつ、誰に、何を送るか)
ちゃんと使うためのポイント
- 機能要件だけでなく非機能要件(性能・可用性・セキュリティ)を必ず確認する
- 「正常系」だけでなく「異常系」「境界値」の振る舞いも要件として定義する
- 要件が曖昧なまま設計に進むと、設計の手戻りではなく実装の手戻りになる
次の章では、要件をもとに行う基本設計と詳細設計の2つのフェーズを整理します。