ソフトウェア・シンポジウム2016 in 米子

非機能に関する要求仕様書作成の課題～開発現場における問題と USDM を用いた解決方法～
水藤 倫彰
株式会社デンソー
TOMOAKI_SUITOU@denso.co.jp

古畑 慶次
株式会社デンソー技研センター
KEIJI_KOBATA@denso.co,jp

要旨

上記の方法を通して得られる指摘事項に対応することにより品質を確保する．しかし，現実には非機能要求について大きな手戻りが発生し，開発プロジェクトが遅れる主要因となっていた．
本稿では，開発現場における非機能要求の課題を整理し，USDM を用いた非機能要求の仕様化手法を提案する．

我々は LED 駆動モジュールのミドルウェアを開発している．プロジェクトは既存のソースコードに対して新規の要求を実現し，同時にリファクタリングを進める派生開発である．開発では，非機能要求についての手戻りが大きな問題となっていた．
非機能要求は，ソフトウェアの作り方に影響するため，設計の再検討も必要となる場合もある．しかし，開発現場では，機能要求の実現を優先し，非機能に関する要求仕様書の作成に時間を確保することは簡単ではない．また，その方法やプロセスも確立されていない．
本稿ではソフトウェアの作り方に対するレビュー指摘から，USDM と抽象化の概念，ISO25010 の品質特性を利用して非機能の要求仕様書を作成する方法を提案する．

2. 非機能要求の課題
非機能要求は，ソフトウェアの作り方やアーキテクチャに大きく影響するため，手戻りが発生するたびにソフトウェアを作り直す必要が出てくる．特にテストフェーズで非機能要求のモレが発覚した場合は，開発期間内にアーキテクチャの変更が困難な場合もある．
我々の開発のように要求仕様書に非機能要求が記述されていなければ，設計レビュー，チェックシート等で問題をチェックする必要がある．しかし，レビューではレビューアの知見や技術力に依存し，成果物が作成された後のチェックとなる．また，チェックシートでは，対象となる製品ソフトウェアに対して一般的な記述となっているため，プロジェクトの特性に起因する要求に対応できない．
開発プロジェクトへの影響を考えれば，非機能要求の文書化は必要不可欠である．しかし，ソフトウェア開発の現場では，機能要求の実現を優先し，非機能に関する要求仕様書の作成に時間を確保することは簡単ではない．また，機能要求からソースコードを記述できるため，納期を優先する組織では非機能要求の必要性を感じないという組織文化の問題もある．
開発現場では，要件定義の段階で，容易に，時間をかけずプロジェクトの特性に合った非機能要求を仕様化する方法が必要である．

1. はじめに
我々は車載メータに組み込むソフトウェアの LED 駆動モジュールのミドルウェアを開発している．車載メータは製品のバリエーションが多く，各バリエーションに対するソフトウェア要求も異なる．ミドルウェア開発は，既存のソースコードに対して新規の要求を実現し，同時にリファクタリングを進める派生開発である．
ミドルウェア開発は，上位アプリケーションからの要求や実装するハードウェアに基づいて開発を進める．しかし，これらの要求は機能要求が中心で，ソフトウェアの作り方対する要求や品質要求などの非機能要求は，要件定義の段階では文書化されていない．実際の開発では，非機能要求に対して下記で対応している．
(1) チェックシート(2) 設計レビュー(1)のチェックシートは，過去に発生した問題から作成した確認項目集である．(2)の設計レビューでは，有識者が成果物をチェックする．

3. 現場における非機能要求の仕様化
現場における非機能要求の仕様化手法として，150SEA

ソフトウェア・シンポジウム2016 in 米子

要求の視点から検討することで，実現すべき“仕様”を抽出する．
(2) “要求”の抽出実現すべき“仕様” に対して抽象化を行い，その“仕様”を含む，実現したい範囲を持った“要求”を抽出する．この時，複数の“仕様”を包含する“要求”を求めるため，一般的な品質特性である ISO25010[3]に対応付け，より広い実現範囲を持つ“要求”を導出する．
適切な特性がない場合は，図 2 に示す非機能要求の分類［2］より，法令遵守または制約に対応づける．
(3) 理由の導出

図１．非機能の要求仕様の作成方法
USDM を用いた要求仕様作成方法を提案する．
現状の開発では，非機能の要求仕様書をプロジェクトごとに新規に作成する時間は確保できない．非機能要求は，機能要求を満たす上での特性であるため，同様の特性を有するプロジェクトの非機能要求を活用可能である．そこで，非機能の要求仕様書を新規に作成するのではなく，過去のプロジェクトから要求仕様を作成し，新規プロジェクトに活用する．
要求仕様の作成には USDM[1]を利用する．USDM では，“要求”を「実現したいことを抽象的に表現したもの」と定義し，実現範囲を示す．“仕様”は「“要求”に含まれる具体的な処理や振舞いを表現したもの」と定義している．
これらは一般的な定義[2]とは異なるが，USDM では上記の定義により要求仕様を階層的に表現することができる．
階層構造で表現することにより，要求仕様をまとめやすく，新規プロジェクトでの活用も容易となる．

4. USDM を用いた仕様化手法
USDM を用いた非機能の要求仕様の作成方法を以下に説明する（図 1 参照）．
本手法では，実現方法としてレビュー指摘から，USDM の書式に基づいて非機能要求の“仕様”，“要求”，理由の順に作成する．

抽 出 し た非 機 能 要 求 が必 要 な理 由を，USDM に従って導出する．
(4) 影響分析
レビュー指摘について，他の非機能要求への影響を分析する．
本方法で作成した非機能の“要求”と“仕様”と共に，具体的な設計，ソースコードの実現方法も活用できる可能性があるため，実現方法を USDM の書式に追加する．

5. 実施結果
実際のプロジェクトにおける，非機能要求に関するレビューの指摘事項 25 件から，本手法を用いて非機能の要求仕様を USDM の形式で作成した．作成した要求仕様では，“仕様”25 件，“要求”19 件となった．
事前に作成された非機能の要求仕様から，要求仕様を選択するだけで，プロジェクトに合った非機能の要求仕様書を作成することが可能となった．また，“仕様”6 件が他と同一の“要求”に含まれたことから，要求仕様の選(1) “仕様”の抽出
レビュー指摘への対応方法は，具体的な設計，ソースコードの実現方法（どのように実現するか？）である．こうした実現方法のゴール（何を実現するのか？）を非機能

図 2. 非機能要求の分類

151

SEA

ソフトウェア・シンポジウム2016 in 米子

択時に，より少ない時間で判断をすることが可能である．
しかし，レビュー指摘から要求仕様を作成しているため，レビュー指摘として出されなかった項目については要求仕様を作成できない．これは，本手法を多くのプロジェクトに適用し，要求仕様を増やすことで解決できる．

6. まとめ
現場において非機能要求を仕様化する時間の確保は難しい．要件定義の段階で，容易に，時間をかけずプロジェクトの特性に合った非機能要求を仕様化する方法が必要である．
本稿では，USDM の枠組みを使用し，ISO25010 の品質特性と抽象化の考え方を利用することで，レビュー指摘への対応方法から，非機能の要求仕様を作成する方法を提案した．

参考文献[1] 清水吉男, 要求を仕様化する技術・表現する技術~仕様が書けていますか？, 技術評論社, 2005
[2] 情報サービス産業協会 REBOK 企画 WG 編集, 要
求工学知識体系 第 1 版,
[3] IPA SEC 監修, つながる世界のソフトウェア品質ガ
イド, IPA, 2015

152

SEA