見出し画像

【要求工学】なぜ人は誤解をするのか、そしてその対処 part.3【要求分析】

琥珀七海

前回の記事の続きです。

今回は要求分析に触れていきます。

要求分析

要求抽出で得た要求は、そのままだとただの情報です。しっかりと活用できる形にまとめていく必要があります。そのために要求分析というプロセスを踏みます
要求分析する際には以下の観点が重要となります。

要求分析で必要な観点

  • 必要な要求か不要な要求か
    要求抽出で抽出した内容について、その要求が必要なのか必要ないのかを分析する必要があります。大量に要求が抽出できた場合、いきなり必要なのか不必要なのかを分析する前に分類するとやりやすかったりします。
    例えばシステム化だとまず機能要求と非機能要求と言った形で分類することができます。機能要求とは機能、スペック、どういった入力項目を受けつけるかと言った、直接システムが「何ができるのか」という事にかかわってくる要求を指します。非機能要求とは「何ができるか」よりも「使い勝手」や「品質（どの程度のバグを許容するか）」と言ったことにかかわってくるものです。それ以外にもさまざまな分類方法はあるかと思いますが、どういった要求があるのかを理解するためには分類するという事は大切です。
    また誰にとって重要な要求なのか、ステークホルダーごとに分類するという事も要求を理解する上で役に立ちます。この要求は「部長クラスだと重要だけど、一般社員レベルでは不要」と言った事や、その逆もまた起こりえます。ステークホルダーごとの分類をしておくことで、「なんとなく必要そう」という抽象化されていた状態から「誰にとっては重要」と理解を進めることができます。

  • 類似した要求の削除
    要求は数を集めることが目的ではありません。類似する要求が大量にある場合、ノイズになることがあります。無理に統合する必要ありませんが、要求は少ない方が思考をクリアにする場合が多いです。類似した要求はしっかりとまとめ、何が要求なのかしっかりまとめることが大切です。

  • 一貫性・優先度の確認
    要求を集めていると相反する要求が出てくることがあります。すべてを同時に満たすような解決方法が見つかれば素晴らしいですが、常にそういったブレイクスルーができることは無いと思います。現実的には全ての要求を満たすことはできないので、要求同士が矛盾していないか、相反していないかを分析する必要があります。
    矛盾、相反した要求がある場合、優先度をつける必要が出てきます。
    例えば、絶対必須、可能な限り欲しい、欲しい、あれば良い、と言った形です。相反する要求を当てはめた時にどちらを優先するのか、この要求分析のタイミングでしっかり定義づけしておかないと、最終的にどっちつかずの中途半端なものが出来上がる可能性が高いです。
    また、折衷案にする場合もこの時点で、しっかりと言語化して折衷案を定義するのが良いでしょう。

  • 実現可能性確認
    いくら素晴らしい要求で優先度が高くても実現できないものはあります。「技術的には可能だが、現時点での予算では無理」「将来的には可能かと思うが現時点の技術では無理」などそういったものです。
    実現できない要求は拾い上げても意味がありません。そういった要求は削除する方が望ましいです。

要求に対して分析を行う

上記の観点で抽出した要求をまとめていくと「なんとなくの方向性」、作りたいものの形は見えてくると思います。しかしここで「なんとなくの方向性」だけで作り始めてしまうと、いざ完成した時に「こんなはずではなかった」という事態になりかねません。関係者全員が不幸になってしまいます。
そうならないために要求を実現可能な形に落とし込む必要があります。しっかりと分析をし、その要求の認識が正しいか関係者間で合意する必要があるでしょう。
合意化する際にはＵＭＬという図を使うと理解が進みやすいケースが多いです。

ＵＭＬとは

Unified Modeling Language、日本語では統一モデリング言語と訳されることが多いです。ＵＭＬは複数の図から成り立っています。まとめたい内容に応じて、図を使い分けていきます。よく使う図は以下になるかと思います。

  • クラス図

  • アクティビティ図

  • シーケンス図

  • ユースケース図
    ここではそれぞれの書き方については触れませんが、知っておくととても便利なモデルです。ここに挙げた以外にもＵＭＬは様々な図がありますので、興味がわいた方、何か図示して整理をしたい方は少し調べてみると良いかと思います。

要求分析で大切な事

せっかく要求抽出で得た情報なので、どれも必要そうに見えます。例えばアンケートで集まった要求であればだれかはその要求を欲しているという事でしょう。
しかし往々にして制約条件がある場合がほとんどですので、すべての要求を満たすことはできません(多くの場合は予算・納期・技術的制約でしょう)。
必ずこの要求分析のフェーズで関係者全員がどの要求を優先するのか、しっかり定義しましょう。優先順位を決めるという事は、やらない要求を決めるという事でもあります。大変な作業ですが、ここをさぼってしまうと後から「そんなつもりではなかった」という事が発生しやすいので、要求に優先順位をつけることをお勧めします。

参考：
・要求工学知識体系(REBOK)概説
　https://www.ipa.go.jp/files/000005375.pdf
・要求開発の基礎知識　要求プロセスと技法入門
　https://nextpublishing.jp/book/10544.html

この記事が気に入ったらサポートをしてみませんか？