システム要件定義 | ぽち先生と学ぶ IT基礎ノート

要点

システム要件定義は、業務要件定義の次に行われる工程です。業務側で明らかになった目的・課題を受けて、システムが具体的に何をするかを定義していきます。

業務要件定義

システム要件定義

基本設計

業務要件が「何を実現したいか（目的）」であるのに対し、システム要件は「そのためにシステムが何をするか（手段）」を定めるものです。同じ課題でも、要件定義の段階によって解像度が変わってきます。

ぽち先生のヒントリフォームでいうと、「収納を増やしたい」という業務要件（暮らし方の希望）に対して、「壁面収納を2畳分設置する」「引き戸のクローゼットにする」という間取り図・仕様書のレベルまで具体化するのが、システム要件定義に相当します。

機能要件は、システムが「具体的に何をするか」という機能そのものの要件です。

例えば「注文を登録できる」「在庫数をリアルタイムで表示する」「注文完了後にメールで通知を送る」といった内容が機能要件にあたります。

非機能要件は、機能そのもの以外に満たすべき品質面の条件です。性能（応答速度）、可用性（止まらないこと）、セキュリティ、拡張性などが含まれます。

性能検索結果を1秒以内に返す

可用性年間99.9%以上稼働する

セキュリティ個人情報を暗号化して保存する

ぽち先生のヒント家でいえば、機能要件が「何ができる部屋か（キッチン、寝室など）」だとすれば、非機能要件は「耐震性」「断熱性」「防犯性」など、目には見えにくいけれど暮らしの質を左右する条件に例えられます。

実際の要件定義では、この2種類の要件を分けて整理し、それぞれ抜け漏れがないかをチェックします。

⚙️ 機能要件（Whatをするか）注文登録在庫表示通知送信

🛡️ 非機能要件（品質の条件）性能可用性セキュリティ拡張性

非機能要件が後回しにされがち機能要件ばかりに気を取られ、性能やセキュリティの検討が手薄になると、リリース直前に大きな手戻りが発生しやすい。

指標を活用してすり合わせるIPA（情報処理推進機構）が公開している「非機能要求グレード」のような指標を使うと、抜け漏れなく水準を関係者間ですり合わせやすい。

要件に優先順位をつけるすべてを満点にしようとすると予算・期間が膨らむため、必須（MUST）と希望（WANT）を分けて合意しておくことが重要。

システム要件定義は、業務要件を受けて「システムに何をさせるか」を機能要件・非機能要件の両面から具体化する工程です。ここで固めた内容が、次の基本設計のインプットになります。