1. HOME
  2. コラム
  3. コラム
  4. 非機能要求の導出~USDMによる要求の定義と仕様化

非機能要求の導出~USDMによる要求の定義と仕様化

  • LINEで送る
  • このエントリーをはてなブックマークに追加
非機能要求の導出~USDMによる要求の定義と仕様化

製品の使い方が分かりにくいというクレームや、派生開発において機能が追加・変更しにくかったりといった、製品のリリース後に発覚する様々な問題は、非機能要求が上手く定義できていないことが原因です。何故、開発現場において非機能要求が上手く導出できないのか、一緒に考えてみましょう。

1、非機能要求とは

機能要求がシステムに「何を」して欲しいのかを示しているのに対し、非機能要求は機能が「どのように」働いてほしいのかを示しています。そのため、機能要求が要求記述の「動詞」に対応するのに対し、非機能要求は「形容詞」や「副詞」に対応します。

さらに非機能要求は、「制約」と「品質要求」に分かれます。「制約」はシステムが遵守しなければならない決まりであり、「品質要求」はシステムが仕事を遂行する時に求められる属性です。

これらの「制約」「品質要求」も、対象システム毎に異なった様々な特性として求められます。「どの特性に焦点を当てて非機能要求を導出するか」について、この記事では以降「観点」と呼びます。

非機能要求をうまく導出できない原因として、開発現場では「手順が分からない」「全て導出できたか分からない」といった声をお聞きします。そこで、次に非機能要求導出の「手順」と「網羅性」についてご説明します。

2、非機能要求の導出に必要となる様々な観点

非機能要求の導出手順として、まずは製品戦略、企画書などの資料から、非機能要求の元となる情報を獲得します。そこにはシステムを対象とした要求につながる情報だけでなく、もっと抽象的なビジネスレベルの要求、あるいはもっと具体的なソフトウェアレベルの要求などが含まれています。そういった様々な種類、階層の情報を分析するとシステムに必要な非機能要求の観点が見えて来ます。既存の情報などから、そのシステムに合った観点があれば(例えば、ドライバビリティなど)、それを使用するのも良いでしょう。

再度、その観点を用いて要求の元となる情報を集めることで、ハッキリと意識出来ていなかった要求も導出できる様になります。

USDMによる要求の定義と仕様化~USDMにおける非機能要求の導出~USDMにおける非機能要求の導出に必要となる様々な観点|製品戦略企画書など→要求の元となる情報の獲得→観点に基づく要求の分析→ビジネス非機能要求・システム非機能要求・ソフトウェア非機能要求・非機能要求の観点→非機能要求の観点を用いてモレていた情報の再獲得

しかし、一言に観点と言っても、どういった観点を用いるのが良いか分かり難いと思います。そういった場合には、世の中で提案されている品質特性、例えばISO/IEC25010で定義されている品質モデル、あるいは自動車ドメインならばEAST-ADL仕様書に定義されている品質要求と制約の項目をまずは参照されてはいかがでしょうか。

USDMによる要求の定義と仕様化~USDMにおける非機能要求の導出~USDMにおける非機能要求の導出に必要となる様々な観点|ISO/IEC25010:2011 システム/ソフトウェア製品品質|機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性

3、ヌケモレなく非機能要求を導出するためには

これまでご説明した観点を用いれば、モレなく非機能要求を導出できるでしょう。しかし、観点そのものがヌケ落ちていれば、そこに関係する非機能要求も同時にごっそりとヌケ落ちてしまいます。

非機能要求の観点をヌケなく導出するためには、要求の所在について全体を把握する必要があります。そこで下図の様な、要求の所有者である「ステークホルダ(利害関係者)」とシステムの「ライフライクル」による表を用います。あるステークホルダが、ライフサイクルのどの段階において、どのような観点の要求を必要とするのか、この表を用いて一つずつ確認することにより、非機能要求の観点についてヌケを防止することが出来るのです。

こうして得られた様々な非機能要求を用いて、設計における具体的な実現手段の決定を行うことが、最終的に製品のリリース後に発覚する問題の低減へとつながります。

USDMによる要求の定義と仕様化~USDMにおける非機能要求の導出~ヌケモレなく非機能要求を導出するためには|各ステークホルダがライフサイクルのステージ毎に持つ非機能要求の観点

サービスに関するご相談は
こちらからお願いします

コンサルタントが教える成功の秘訣

コンサルタント 矢頭 伸介

エンジニアの方は、ご自身が実装を進めている制御において、どうあるべきか要求がはっきりしないな、と悩みながら自分の分かる範囲で仕様を決めた経験が一度ならずあるかと思います。このように決められた仕様は、部分最適には成り得ても全体最適とは成り得ないでしょう。全体最適を目指すには、トップダウンの手法が必要なのです。

また、開発中あるいは開発済みのシステム要求を明らかにしたい場合は、トップダウンによる非機能要求の導出だけでなく、設計仕様から要求を導出するボトムアップも同時に行うことで、それぞれの方法で導出された要求を突き合わせ、より精度の高い要求仕様の定義が出来るでしょう。

エクスモーションでは、お客様の現場状況に合わせ、全体最適なシステムを実現するための具体的な方法をご提案いたします。ぜひ、私たちにご相談ください。

矢頭伸介
  • LINEで送る
  • このエントリーをはてなブックマークに追加