要求と要件を整理する「USDM」のススメ
こんにちは。egatti (エガッティ)です。IT女子ブログやってます。
★USDMのやり方を追記しました 2019/2/26★
情報処理技術者試験(春期)の受験申込み受付中です。
2/18(月)20:00 までです。受験される方、お忘れなく。
IPA 独立行政法人 情報処理推進機構:試験実施案内:平成31年度春期試験について
どーしよーかなー。ちょっと迷い中。
もう一個、余談。
冬になると、よく黒タイツを履くんですけど、結構、毛玉がついて困るんですよね。毛玉を予防するには、洗濯する時に裏返しておくのがいいそうです。ほうほう、なるほど。でも、もうすでに毛玉だらけになってるよー!どうしてくれるんだよー!そういう時は、T字カミソリで取れるそうです。どうぞ、参考に。
さて。
今日は、SEさんのための記事です。
要求と要件を整理するUSDMとは
皆さんは「要求」と「要件」の違いがわかりますか?
こんな問いかけから始まりました。出向先で要件定義の整理の仕方について教えていただいたのですが、とてもわかりやすかったです。
ただ、じゃあ実際にやってみましょう、となると、いろいろと難しい。
参考文献です。「USDM 要件」とかでググりました。
要求仕様記述手法「USDM」ってどんなの?
http://swquality.jp/temp/nagasakiqdg15_usdm.pdf
【USDM】による「要件定義」と「要求仕様化」
https://www.exmotion.co.jp/solution/yokyu.html
前提として、まずは言葉の定義をおさらい。
ユーザーがやりたい事が「要求」。
その「要求」を実現するためにシステムがやるべき事、それが「要件」。
わたし自身、探りながら実体験中なので、うまく説明できてない部分があるかもしれませんが、思うところをまとめてみます。雰囲気はつかめると思うので、読んでみてください。
USDMのやり方
さっそく、やり方から。
要求と要件を階層構造で整理する
顧客の要求を抽出して、その要求を実現するための要件を対応づけながら、整理していきます。何を実現するための仕様かを明確にすることができます。1つの要求に対して複数の要件がぶら下がるはず。
↓イメージはこんな感じ
https://www.exmotion.co.jp/solution/yokyu-3.html
同じ要件が、複数の要求に存在してもOK。その場合、「XXX参照」のように記載するのも良いですね。
要求の理由を分析する
その要求の本質的な目的は何だろう、なぜ実現したいのだろう、どんな背景があるのだろう、という分析をします。
要求の理由を深く分析していない場合、出来上がったときに「思ってたんと違う!」となる可能性が高まります。
例えば「カメラボタンを押下するとカメラ撮影画面を起動したい」の理由は、「写真を撮るため」だけど、もっと深く分析して「スマホを持ち歩いている中で写真を撮りたい瞬間に出会った時、素早くカメラを起動して写真を撮るため」という背景が見えた場合、要件として「ショートカットカメラボタンを押下すると、1秒以内にカメラ撮影画面を表示して撮影可能な状態にすること」という具体的な仕様が見えてきます。
要件がそのまま検証項目になるレベルまで具体化する(V字開発)
要件は、システムが実現すべき動作なので、そのまま試験項目として利用できるはず、というのが USDM の特長です。V字開発の基本的な考え方ですね。要件が曖昧だと評価ができません。
誰が何をしたら何がどうなる、など、トリガーとなるものや対象の範囲などをしっかり定義しておくことで、試験手順が明確になります。そして、何をもってOKとするかという評価基準が明確になります。誰でも理解できて、試験ができることが理想です。
USDMのポイント
ユースケース(人の動き)を意識する
モノに対して人が何をしたいのか、を意識して要求を抽出します。要求なので「〜したい」とすると、ブレにくくて良いです。例えば「音楽再生機能を提供する」よりも「曲を選択して音楽再生ボタンを押下したら、音楽再生用に設定された音量で、選択中の曲を再生したい。」とした方が、求められていることが伝わりやすいです。
誰が、何を、どうする、を明確にする
要件を試験項目にできるレベルまで、誰が何をどうしたら何がどうなる、を明確にする必要があります。例えば「社員一覧を表示したい」は、「人事課職員が検索条件を入力して検索ボタンを押下すると、全社員の情報のうちの検索条件に該当する社員情報を3秒以内に一覧表示したい。検索条件と表示項目は別紙参照」という感じ。
否定「~しないこと」や曖昧表現「~してもよい」などは使用しない
否定表現、例えば「キャンセルボタンを押下したら、検索処理は行わないこと」という要件では、「じゃあ、キャンセルボタンが押された時って、何したらいいの?」という部分が不明ですし、試験項目としても、何をもってOKとすればよいかわかりません。「検索処理中にキャンセルボタンを押下したら、検索処理を中断し、検索中めっせーじを消去すること。」と書けば、やることがはっきりしますね。とにかく、具体的に、明確に書くことが、正しい要件を整理するコツ。
★★やり方追記 2019/2/26 ★★
- 要求仕様をすべて書き出す
⇒漏れをなくす、dropは理由を添えてエビデンスとして残す - 要求をグルーピングする
⇒同じ要求をまとめる、同じ目的のものは階層化する - 要求を要件化する
⇒不明点を残さない - 要件と機能を紐づける
⇒トレーサビリティマトリクスを作成、必ず何かの機能で実現される
USDMの利点
最後に、USDM で要求分析、要件定義を行うとどんな良いことがあるのかみてみましょう。
要求の抜け漏れ、矛盾が見つかる
要件定義の問題といえば、要求分析が十分でないまま仕様を固めて工程を進めていくうちに、実現したいことに対してヌケ・モレ・ズレがあることが判明して、多大な工数と共に大変な手戻りが発生してしまうパターン。
前の記事でシステム開発の手法を紹介しましたが、その中でもメジャーなウォーターフォールでは、ひとつの工程を確実にfixさせます。逆に言えば工程完了が承認されなければ、次に進めません。顧客要求を分析して仕様を決めて見積もりして… 分野も様々で初めて耳にするような難しい専門用語が並ぶ中、限られた時間内でしっかり分析しなければなりません。要求分析が不十分だと、仕様と見積もりに大きなヌケモレズレが発生して、プロジェクト全体に影響してしまうわけですね。
USDM は、そのヌケモレズレを出来る限り早い段階で炙り出してプロジェクト全体をハッピーにする、というわけです。
もれなく非機能要件も定義
システムで実現して実際にユーザが利用する機能の要件を、機能要件と言います。社員一覧検索機能とかアラーム機能とか。それ以外が非機能要件。
それ以外って?例えば、社員一覧は3秒以内に表示して!みたいな性能要件とか、不正アクセスされないように対策して!みたいなセキュリティの要件など、様々です。
顧客にもよると思いますが、顧客があまり意識していないことである場合も多いため、非機能要件もきちんと定義しておかないといけません。要件になかったから、と言って、バックアップしてなかった!とか、現行システムからの移行ができない!みたいなシステムを作っちゃうSEさんは、残念としか言えませんね。
変更管理に強い
システム開発では、仕様変更が発生するとコストや納期などに大きく影響します。また、特に組み込み開発では、いったん開発したものから、バージョンアップしたり、違う国や地域向けに作り替えたりすることが、多々あると思います。そんな時、USDM で要求・要件を整理しておくと、差分を明確にすることができ、どこに影響があるかを調査しやすいという利点があります。
なので、とっても大変だけど、最初にしっかり時間をかけて、USDM で要求分析、要件定義を行うことで、トータルで見ると良いシステムへの近道になるわけです。
考察
USDM のポイントや考え方など、ここに挙げた以外にも大事な事がたくさんあると思うので、いろいろ調べてみてください。
要求分析・要件定義をやる時だけじゃなく、そこから作成された仕様書を見る時にも、USDM の考え方を意識すると、いろいろなことが見えてくるかもしれません。
システムを使うのは人。システムを作るのも人。コーディングや単体試験など可能なものは自動化して、いわゆる「力作業」と言われるような工数はどんどん削減して、その分、しっかり頭を使って分析して、顧客もSEも、お互いの認識を合わせながら、確実なシステム開発を行うことが、とっても大切なんですね。
今日の らくがき も、本文にまるで関係ないですね。JKを描いてみた、ただそれだけです。
では、また。