要件定義

一言でいうと

作るものが満たすべき条件を、関係者から引き出して文書にまとめる工程です。

提唱者と登場年

英語版 Wikipedia は、Winston W. Royce が1970年に発表した論文「Managing the Development of Large Software Systems」が、要求を開発の最初の工程として位置づけたと記述しています。その後、Rational Unified Process などの方法論が、要求の扱いを初期の一工程ではなくシステムの生涯を通じた活動として捉え直しました。要求工学の活動は、引き出し、分析と調整、モデル化、仕様化、妥当性確認、管理の6つに整理されています。

国内では、独立行政法人情報処理推進機構が2019年9月に『ユーザのための要件定義ガイド 第2版』を公開しています。発注する側の企業を対象に、48の問題と128の勘どころをまとめた資料です。

「要求定義」は、組織や標準によって要件定義と区別される場合があります。

何を解決するか

作り始めてから「思っていたものと違う」と分かる事態を減らします。関係者は自分の業務の言葉で要望を話し、開発者はシステムの言葉で受け取るため、確認しなければ両者の理解は一致しません。

もう一つ、決める人を決める役目があります。関係部署の要望が衝突したときに誰が判断するかを先に決めておかないと、実装の途中で仕様が揺れ続けます。

実際の進み方

業務要件、利用者の要件、システム要件の順に降ろします。業務要件は「何のために」を示し、システム要件は「何を満たすか」を示します。この順序を飛ばすと、機能の一覧はできても目的との対応が説明できません。

引き出した要求は、優先順位を付けて文書にします。業務上の重要度に加えて、実現可能性、費用、リスク、他の要求との依存関係を確認して並べ、後で削る判断ができる状態にします。

最後に妥当性を確認します。書かれた要求が業務の目的を満たすか、相互に矛盾していないか、検証できる書き方になっているかを関係者と確認します。

導入でよくある失敗

• 機能の一覧だけを作り、業務要件を文書に残さない。後から優先順位を判断できません
• 決裁者を決めないまま進め、部署ごとの要望をすべて仕様へ入れる
• 性能・可用性・運用といった非機能の条件を後回しにする

求人票にこの語がある場合に読み取れること

「要件定義から担当」と書かれている場合、実装だけでなく、関係者との調整と文書化まで任される範囲だと読み取れます。発注する側の企業か、受注する側の企業かによって仕事の中身が異なるため、どちらの立場で要件を決めるのかを確認してください。経歴を確認するときは、本人が決めた範囲と、決裁を仰いだ範囲を分けて聞きます。

隣接手法との違い