要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（3/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
何を、なぜ、解決したいのか
要求は、どこまで分析すれば足りるのであろうか。要求分析の目的は何であったか。要求分析の過程ではこれらの疑問が幾度となく必ず生じる。
これらの疑問に答えるプロセスは、第5回のテーマ「妥当性確認」である。逆にいえば、要求分析では分析に徹することが大切と考える。他方、要求分析の過程でも妥当性確認を行いながら、すなわち要求分析の結果に評価を加えながら進めてはどうか、との考え方もある。どちらも正しい。
では、「妥当性を確認する」とはどのような行為なのか。少なくとも3つを確認しなければならない。1つ目は、それぞれの要求が「要求の品質」をどの程度満たしているかである（図3の「要求の品質チェックリスト」を満足させる状態にしなければならない）。2つ目は、要求した（解決したい）ことが要求仕様書に記載されたかである。最後は、要求の発生した背景にある理由、例えば上位の要求を満足する（可能性がある）かである。
従って、「何を、なぜ、解決したいのか」を思い起こさなければならない。同時に、要求は、
ビジネス要求 ⊃ システム要求 ⊃ （ハードウェア要求＋ソフトウェア要求）
の包含関係にあることを思い出そう。
ソフトウェア要求に限れば、ソフトウェアの機能が満たすべき品質を定義するうえで、ISO14598「ソフトウェア製品の評価」、ISO9126「ソフトウェア製品の品質」、ISO25000シリーズ・SQuaRE（Software product Quality Requirements and Evaluation）「ソフトウェアの品質と評価」に関する国際規格が参考になる。
例として、図7-1から図7-3まではISO9126から引用したものである。図7-1上部の「実世界」の「必要性」が「利用時の品質」として実現されれば、「妥当性がある」と考えるのである。
そして、この「利用時の品質」を実現するために、さらにソフトウェアの外部品質、そして内部品質を詳細化して、備えるべき品質の特性を明確にしようとする。図7-1の利用時の品質は図7-2へ、そしてさらに図7-3へと詳細化される。これらのISOの品質ブレークダウンは一例にすぎない。自社のビジネス要求がもっと厳しいものであれば、これらの品質ももっと厳しく定義することになる。
要求リストだけでは足りない
要求リストの要求を分析すれば事足りるか。答えはノーである。要求リストの要求では足りないことがほとんどである。単なる要求漏れや検討不足ということもある。また、要求には、「倫理的にしてはならない」「法律に反する」「地域により理解が異なる」などの副次的な要求も混在している。だから、要求リストの要求を分析しただけでは不十分であることが多い。
このため、対象となっている問題領域の知識・スキル・経験を活用しなければならない。これを実行するには、問題領域の利害関係者の参加のもとで要求分析を実行することが欠かせない。
次回は、要求分析の結果を形で表す「要求仕様書」を取り上げる。
著者紹介
前田卓雄
匠システムアーキテクツ株式会社 代表取締役
外資系コンピュータベンダのシステムエンジニア、デロイトトーマツコンサルティングを経て独立。主に、ユーザー企業、行政機関、大手システムインテグレータ、ハイテク企業、大手組み込みソフトウェア開発ベンダにおいて、情報戦略の立案、ユーザーが自ら作成するRFP（提案依頼書）作成を支援、ソフトウェアビジネスのプロジェクトポートフォリオ、プログラムマネジメント、プロジェクト管理とプロセス改善、開発プロジェクト管理システムの開発、バグ削減・欠陥予防・ソフトウェア生産性や競争力向上コンサルティングに従事。
Copyright © ITmedia, Inc. All Rights Reserved.