|
|
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。  表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS全体を説明する。このため目的、範囲、用語定義、参考文献、概要などを記述する。以下では、これらの内容について説明する。ただしSRSを記述する上でこれら以外に必要となる内容がもしあれば、「はじめに」で参考文献の前などに追加して説明しておくことになる。 ◆目的 SRSの目的を説明しSRSの対象読者を明らかにする。 ◆範囲 SRSの範囲では、以下の内容を記述する。 ・ソフトウェア製品の名称 ・ソフトウェア製品が何を実行し、何を実行しないのかについての説明 ・ソフトウェア製品の利点、目的、目標などの適用性についての説明 ここで、SRSの範囲の記述が、SRSを包含するシステム要求仕様書SyRSと整合性を持つ必要がある。 ◆用語定義 用語定義では、SRSを正しく理解するために必要となるすべての用語、省略形などを定義する。用語定義情報が多い場合には、「はじめに」で記述するのではなく、SRSの付録にまとめるか、別資料として参考文献で参照することも考えられる。 ◆参考文献 参考文献では、SRSの中で参照されるすべての文書を列挙する。すべての参考文献には、SRS内で引用するための識別番号を付与し、題名、著者名、発行機関、発行日付などを記述する。 ◆概要 概要では、「はじめに」の最後にSRSの全体構成を説明しておく。 SRS 第2章「一般的な説明」 この章では、製品および製品要求に影響を与える製品要求の背景や環境について説明する。このような一般的要素としては、製品の背景、製品機能、ユーザー特性、制約、仮定および依存性、要求の配分がある。具体的な要求の詳細はSRS第３章で記述する。 ◆製品の背景 ソフトウェア製品は、独立した製品である場合と、より大きなシステムの構成要素となる場合の２つがある。この節では、ソフトウェア製品がシステムの一部である場合は、システムの要求項目とソフトウェアの機能とを関連づけ、両者の相互関係をインタフェースとして規定する。 ソフトウェアが動作するための制約にはインタフェース制約と、メモリ、オペレーション、サイト適応条件などの環境制約がある（表２）。インタフェース制約には、システム・インタフェース、ユーザ・インタフェース、ハードウェア・インタフェース、ソフトウェア・インタフェース、通信インタフェースがある。 また、システムの主要構成要素、相互接続、外部インタフェースをブロック図などにより説明する。 ◆製品機能 この節では、ソフトウェアが実行する主要機能の概要を明確に記述する。機能の記述では、だれでも容易に理解できるように整理した機能一覧や機能間の関係を説明する文章や図を用意しておくことが重要である。 ◆ユーザー特性 この節では、製品が対象とするユーザーの一般的特性として教育レベル、経験、専門知識などを記述する。 ◆制約 この節では、開発者の選択肢を制約する次のような項目について説明する。 ・制度的なポリシー ・ハードウェアの制約（シグナル・タイミング要求など） ・他のアプリケーションとのインタフェース ・並列処理 ・監査機能 ・制御機能 ・高位言語要求 ・シグナル・ハンドシェ−ク・プロトコル（ X O N - X O F F 、A C K -NACKなど） ・信頼性要求 ・アプリケーションの重要性 ・安全性とセキュリティの検討項目 ◆要求項目の仮定と依存関係 この節では、SRSの要求項目に影響を及ぼすような要因を列挙する。また、これらの要因と個々の要求項目との依存関係を明確にしておく。 たとえば、ソフトウェア製品が指定するハードウェア上にあるOSが動作するという仮定があるかもしれない。もしこのOSがそのハードウェアで動作しない場合、SRSを変更する必要がある。したがって、OSが指定したハードウェアで動作するという仮定を明らかにするとともに、この仮定の変更で影響をうける要求項目も明記しておくことが重要である。 ◆延期要求 この節では、システムの次期バージョンまで延期される可能性のある要求項目を特定しておく。  表2 SRS 一般特性の記述  表3 ソフトウェアの動作条件 論SRS 第3章 「具体的な要求の説明」 ここの章では、すべてのソフトウェア要求を具体的に記述する。この要求記述に基づいて、システム設計者が要求を満足するシステムを作成し、システムが要求を満たしていることを試験者が確認する。この章で記述される要求は、ユーザー、オペレータ、外部システムによって理解できる必要がある。具体的な要求の記述では、システムからの入力（刺激）と出力（応答）、そしてこれらの入力によって実行され指定された出力を生成する機能について最低限でも必ず説明しておくことが重要である。 要求を具体的に記述するために、次のような留意点を推奨している。 ・表4 に挙げた要求仕様のよい性質を満足するように記述する ・要求項目を関連文書と相互参照できるように索引を付ける ・要求項目を一意に識別できるように番号付ける ・読みやすくなるように、要求記述に関する段落構成を工夫する ◆外部インタフェース ソフトウェア・システムの入出力について具体的に説明する。ただし、インタフェースの説明を補足するものであるため、同じ情報は繰り返さないほうがいい。 ◆機能 入力の受付と処理および出力の処理と作成時に必要となる基本的な動作を定義する。機能要求を下位機能や下位プロセスに分けることが適切な場合もある。ただしソフトウェア設計でも要求の機能階層と同じ階層構造で下位機能に分解されるとは限らないので注意しておく。 ◆性能要求 ソフトウェアまたはソフトウェア全体と人間との対話処理の性能に対する、静的ならびに動的な性能要求を数値的に明記する。ここでは定性的な性能要求ではなく、数値的に測定可能な用語を使って性能要求を記述することが重要である。また個々の機能ごとに適用される性能上の許容範囲などの値は、それぞれの機能の説明の中に明記する。 ◆論理データベース要求 データベースに格納する情報に関する論理的な要求を明記する。 ◆設計の制約 準拠すべき標準や法制度などによって影響を受ける設計上の制約を明記する。これにより、処理活動を追跡するためのソフトウェア要求を明確にできる。アプリケーションによっては法律上の基準をソフトウェアが満たすことを確認するために、このような標準に関する準拠性を追跡することが重要になるだろう。 ◆ソフトウェア属性 要求としてソフトウェアが持つべき性質や制約などの属性は数多くある。ソフトウェアの要求属性を明記しておかないと、実現されたソフトウェアがそれらの属性を持っていることを客観的に検証することはできない。このような属性には、信頼性、可用性、セキュリティ、保守性、移植性がある。 ◆要求を記述する上での段落構成 システムの運用状態、ユーザー種別、オブジェクト、サービス種別、刺激、応答、機能階層という７つの視点に基づいて要求を記述することができる。 どの視点に着目して要求を記述するかで、要求記述の段落構成が変わるので、ソフトウェアの特徴に応じた理解しやすい段落構成で機能を記述することが重要である。 IEEE830では、次のような８個のテンプレートを用意している。 A1 ：外部インタフェースを記述してから、運用状態ごとに機能要求を記述する A2 ：運用状態ごとに、外部インタフェースと機能要求を記述する A3 ：外部インタフェースを記述してから、ユーザー種別ごとに機能要求を記述する A4 ：外部インタフェースを記述してから、オブジェクトごとに、属性と機能要求、メッセージを記述する A5 ：外部インタフェースを記述してから、サービス種別ごとに、目的、刺激と応答、機能要求を記述する A6 ：外部インタフェースを記述してから、刺激ごとに機能要求を記述する A7 ：外部インタフェースを記述してから、データフロー図を用いて機能要求を階層的に記述する A8 ：外部インタフェースを記述してから、複数の視点の組み合わせごとに機能要求を記述する。 例：ユーザー種別とサービス種別の組み合わせごとに機能要求を記述する ここで、A.1-A.8 における各「機能要求」の節では、「はじめに、入力、処理、出力」と題する4つの下位の節を用意して、具体的に機能を説明する。機能の説明では、日本語、擬似コード、システム定義言語などを用いることができる。  表4 要求仕様が満たすべき性質  表5 要求仕様の具体的な記述項目 目次、索引、付録の位置付け 目次と索引は要求仕様を理解する上で重要であるため、一般的な構成に従って正確に記述する必要がある。 これに対して付録は、必ずしも要求仕様の一部とは考えられていないので必ずしも記述する必要はない。もし付録を要求仕様に入れる場合は、付録が要求項目の一部とみなされているかどうかについて明記しておく必要がある。たとえば、IEEE830 では、次のような内容を付録の例として示している。 a) 入出力フォーマットの例、費用分析調査の説明、ユーザー調査の結果 b) 要求仕様の読者に役立つ支援情報や背景情報 c) 要求仕様を実装するソフトウェアによって解決される問題の記述 d) 要求項目を満たすためのコードおよびメディアに関する特殊な構成の指示 まとめ 本稿ではIEEE830に従って表４に示した性質を持つ要求仕様の一般的な構成について紹介した。要求仕様を記述するときの段落構成のテンプレートがあるように、できるだけわかりやすく要求仕様書を構成しようとしている。 重要な点は、図１に示したようにソフトウェアが環境やシステムの一部であり、それらとの接点としてのインタフェースを要求仕様で明確に規定することと、要求項目を明確に説明するために、要求仕様が持つべき性質を決めておくことである。この２つの点でIEEE830は参考になると思われるのである。  図1 システム、環境とソフトウェアの関係 参考文献 [１] IEEE, ソフトウェア要求仕様に対する推奨プラクティス-IEEE Std 830-1998 [２] 大西淳、郷健太郎「要求工学」、共立出版、2002 [３] IEEE, システム要求仕様開発のためのガイド-IEEE Std 1223-1998
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
