要件定義

ねらい

システムに何を求めるかを決める段階について学びます。このレッスンを終えると、要件を2種類に分けて考えられるようになり、書き漏らすと後で何が起きるのかを説明できるようになります。

要件定義は、作る前の合意です

要件定義は、そのシステムが何をできなければならないかを決めて、関係者で合意する作業です。

ここで決めそこねると、後の工程で必ず跳ね返ります。作ってから「そうではなかった」と分かると、設計からやり直しになります。要件定義の誤りは、後の工程で見つかるほど直す費用が大きくなります。

2種類の要件

機能要件は、そのシステムが何をできるかです。「商品を検索できる」「注文を受け付ける」「請求書を発行する」など、動作として書けるものです。

非機能要件は、その機能がどのような品質で提供されるかです。

関係者の意見は、そろっていません

要件を出す人は1人ではありません。立場が違えば、欲しいものも違います。

• 現場の担当者は、入力の手間が減ることを望みます。
• 管理者は、状況が見えることを望みます。
• 経営者は、費用が抑えられることを望みます。
• 情報システム部門は、運用しやすいことを望みます。

システムに関わるこうした人々を利害関係者（ステークホルダ）といいます。要件定義の仕事の半分は、意見の食い違いを見つけて調整することです。

全部を叶えようとすると、費用も期間も膨らみます。だから優先順位を付けます。「無ければ成り立たないもの」と「あればうれしいもの」を分け、前者から確実に満たします。

決めたことは、文書に残す

合意した内容は要件定義書にまとめます。口頭の合意は、後で食い違います。

書いた要件が満たされたかどうかは、受入テストで確かめます。確かめられない書き方をした要件は、満たされたかどうかを判定できません。「使いやすいこと」ではなく「主要な操作を3画面以内で完了できること」と書くのは、このためです。

まとめ

要件定義は、作る前に何ができるシステムにするかを合意する作業です。要件には機能要件と非機能要件があり、前者は何ができるか、後者はどんな品質で動くかを決めます。非機能要件は数で書かなければ判定できません。利害関係者の望みは食い違うので、優先順位を付けて調整します。

理解の確認

要件定義の場で、利用部門から「操作しやすい画面にしてほしい」という要望が出ました。この要望を要件として扱うには、何が足りないでしょうか。

答え: 満たされたかどうかを判定できる形になっていないことが足りません。「操作しやすい」は人によって基準が異なり、開発側が作ったものに対して利用部門が「これは操作しやすくない」と言えば、合意は成立しません。受入テストでも合否を判定できません。「よく使う3つの操作を、3画面以内・2分以内で完了できる」のように、確かめられる形の数や条件に置き換える必要があります。非機能要件は、数で書いて初めて要件として機能します。