各種システム開発・WEBコンテンツ制作・WEBデザイン・ホームページ制作・インフラ設計・構築・レンタルサーバー・ソフトウェア技術者のアウトソーシング事業を行っております。

3 月
30

非機能要件を組み込む

技術スタッフ


非機能要件とは

非機能要件を説明する前に、機能要件の意味を説明します。
機能要件は、そのシステムやソフトウェアで何ができるのかを纏めたもので、
扱うデータの種類や構造、処理内容、画面表示や操作の方法、帳票などの
出力の形式が相当します。
一方、非機能要件は、機能面以外のもの全般(性能や信頼性など)です。
機能要件は製品に求められるもの、非機能要件はソフトウェアに求められる
ものです。

 

非機能要件の種類

非機能要件は、機能性、信頼性、使用性、効率性、保守性、移植性、障害抑制性、
効果性、運用性、技術要件の10種類に分類して定義しています(※)。
※日本情報システム・ユーザー協会(JUAS)発行「非機能要求仕様定義ガイド
ライン」より。

ここからは自分の開発経験の話になりますので、開発するプロジェクトにより
違うかもしれないです。

 

非機能要件の組み込み

ソフトウェアを構築するにあたり、非機能要件を組み込むことは必要です。
何故なら、ソフトウェアは作ったら終わりでなく、この先も使い続けるからです。
電化製品のソフトウェアであれば、購入したユーザーが使い続けます。
そして、そのソフトウェアに異常が見つかったら、修正して再リリースしなければ
なりません。
また、開発する側にとっては、次期モデルのベースのソフトウェアになります。
その一方で、ソフトウェアに全ての非機能要件を組み込むことは、それだけの
工数を必要とするので難しいのが現状です。
そのため、ソフトウェア設計の時に、どの非機能要件を組み込み込むかを話し合い
決めるのが通例です。
自分が携わった開発では、1年毎にモデルチェンジして、同時にスペックを変えて
数ヵ国に販売をしていたので、保守性はもちろん移植性を組み込んでいました。

 

保守性と移植性

保守性は、維持・管理のし易さの度合いの事です。
ソフトウェアを作れば、まず不具合が全く無い事はありません。
不具合の原因を早く見つけ、効率よく修正して、かつ修正による波及範囲を最小限に
することが重要です。
そのため、モジュールをできる限り細かく分割し、独立性を高めることで修正の
波及範囲を狭くして、また不具合の場所を特定し易いよう随所にデバッグ用のログを
仕込みました。
もう一つの移植性は、別の環境へ移した際そのまま動作する度合いの事です。
自分が担当した開発では少し違う意味で、容易に他のソフトウェアの機能を移す
ことを言っていました。
モデルチェンジをする時は、営業側から機能の追加や改善や削除が求められます。
そのため、機能毎にブロック分割して、ブロック同士をインターフェイスで繋げる
仕組みにして、インターフェイスを変えることで簡単にブロックの追加や削除が
容易にできるようにしました。

 

最後に、非機能要件はソフトウェア設計の時に決めると言いましたが、保守性と
移植性は進んで組み込むべきだと思います。
自分は、保守性と移植性を組み込むようになってから、ソフトウェアの品質が
向上したのを感じました。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

月別アーカイブ

カテゴリ