💬
ソフトウエア品質についてCopilotに聞いてみた
ソフトウエア品質についての簡単な概略とそれを実現するための指示であるソフトウエア仕様書についてCopilotに聞いてみました。
Copilotにソフトウエア品質特性について聞いてみた
ISO/IEC 25010 における品質特性と副特性一覧
| 品質特性 | 品質副特性(副次的観点) |
|---|---|
| 機能適合性 | 機能完全性、機能正確性、機能適切性 |
| 性能効率性 | 時間効率性、資源効率性、容量満足性 |
| 互換性 | 共存性、相互運用性 |
| 使用性 | 認識性、学習性、操作性、ユーザーエラー防止性、ユーザーインターフェースの美しさ、アクセシビリティ |
| 信頼性 | 成熟性、可用性、障害許容性、回復性 |
| セキュリティ | 機密性、整合性、否認防止性、責任追跡性、認証性 |
| 保守性 | 解析性、変更性、安定性、試験性 |
| 移植性 | 適応性、設置性、置換性 |
Copilotに仕様と要件について聞いてみた
機能仕様 vs 非機能仕様：要件分類一覧
| 要件カテゴリ | 要件例 | 仕様分類 | 関連する品質特性 |
|---|---|---|---|
| 機能要件 | 業務ロジック、データ処理、画面遷移、APIの動作 | 機能仕様 | 機能適合性 |
| 性能要件 | 応答時間、同時接続数、スループット | 非機能仕様 | 性能効率性 |
| 操作要件 | UIの使いやすさ、ナビゲーション、誤操作防止 | 非機能仕様 | 使用性 |
| セキュリティ要件 | 認証、アクセス制御、暗号化、ログ管理 | 非機能仕様 | セキュリティ |
| 信頼性要件 | 障害時の復旧、冗長構成、可用性 | 非機能仕様 | 信頼性 |
| 保守性要件 | ソースコードの変更容易性、テストのしやすさ | 非機能仕様 | 保守性 |
| 互換性要件 | 他システムとの連携、共存性 | 非機能仕様 | 互換性 |
| 移植性要件 | OS間の移行、クラウド対応、インストール容易性 | 非機能仕様 | 移植性 |
| アクセシビリティ要件 | 音声読み上げ対応、色覚補正、キーボード操作対応 | 非機能仕様 | 使用性（アクセシビリティ） |
| 国際化・ローカライズ要件 | 多言語対応、通貨・日付形式の切替 | 非機能仕様 | 使用性、互換性 |
補足：分類の考え方は、
- 機能仕様は、「何をするか」に関する要件。 例：ユーザーが商品を検索できる、注文を確定できる。
- 非機能仕様は、「どのようにするか」「どれくらいの質で行うか」に関する要件。 例：検索結果は1秒以内に表示される、誤操作を防ぐUI設計。
Copilotにソフトウエア仕様に書かれるべき必須要件について聞いてみた
以下は、一般的に記載すべき項目の一覧です
| 項目名 | 内容の概要 |
|---|---|
| 1. プロジェクトの概要 | 背景、目的、達成したい目標、開発のスコープ（含む・含まない） |
| 2. 現状の課題 | 現在の業務やシステムの問題点、改善したい点 |
| 3. 機能要件 | システムが提供すべき具体的な機能（例：ログイン、検索、決済など） |
| 4. 非機能要件 | 性能、セキュリティ、可用性、操作性、保守性などの品質に関する要件 |
| 5. ユーザーシナリオ／業務フロー | ユーザーの操作手順や業務の流れを図や文章で記述 |
| 6. 画面仕様 | UI構成、画面遷移、入力項目、エラーメッセージなど |
| 7. データモデル | データ構造、ER図、テーブル定義、項目の意味 |
| 8. API仕様（必要に応じて） | 外部連携や内部通信のインターフェース定義 |
| 9. 制約条件 | 技術的制約、予算、納期、使用技術、法的要件など |
| 10. 優先度・変更管理 | 要件の優先順位、変更時の対応方針や承認プロセス |
| 11. 開発体制・役割分担 | 関係者の役割、責任範囲、連絡体制 |
| 12. スケジュール | 開発・テスト・リリースまでの工程とマイルストーン |
| 13. 用語集／略語一覧 | ドキュメント内で使用される専門用語や略語の定義 |
| 14. バージョン履歴 | ドキュメントの更新履歴、変更点の記録 |
Copilotに外部委託する場合のソフトウエア仕様に書かれるべき必須要件について聞いてみた
| 項目 | 理由 |
|---|---|
| スコープ定義 | 委託範囲（開発・テスト・保守など）を明確にする必要がある |
| 機能・非機能要件 | 誤解を防ぐため、より具体的かつ網羅的に記述する必要がある |
| 制約条件 | 使用技術、納期、予算、法令遵守など契約に関わる制約が重要 |
| 成果物の定義 | 何を納品するか（コード、ドキュメント、テスト結果など）を明記 |
| 変更管理方針 | 要件変更時の対応方法や承認プロセスを明示する必要がある |
| 品質基準 | テスト合格条件、バグ許容率、レビュー基準などを明文化することが望ましい |
以下は省略または簡略化されることが多い項目
| 項目 | 理由 |
|---|---|
| 開発体制・役割分担 | 理委託先が独自に構築するため、発注側が詳細を書く必要はない |
| 内部スケジュール | 委託先が管理するため、発注側はマイルストーンや納期のみ記載することが多い |
| 実装詳細 | 要件定義段階では記載せず、委託先が設計に基づいて決定する |
外部委託ならではの配慮
- 契約文書との整合性：SRSは契約書の技術的裏付けになるため、曖昧な表現は避ける。
- 成果物の検収基準：納品物の品質をどう評価するかを明確にすることで、トラブルを防ぐ。
- コミュニケーション設計：連絡窓口やレビュー頻度など、プロジェクト運営に関する記述も有効。
つまり、外部委託では「仕様書が契約の一部になる」という意識が重要なんですね。
まとめ・感想
Copilotにソフトウエア品質や仕様書について質問したところ、よく整理された回答を得ることができました。学習した元記事が素晴らしかったのだろうと推測しています。
実際の製品開発では、上記に加えて法規への適合の検討も必要になりますね。
かなり昔になりますが、「安全性」という言葉があったのを思い出してCopilotやGoogle(Gemini?)に確認してみました。
[Copilot]
ISO/IEC 25010 では、「安全性（Safety）」という特性は直接的には登場しません。 代わりに、「信頼性・セキュリティ・使用性」に分散して含まれていると考えられます。「安全性」は、医療機器や自動車、航空などの物理的リスクを伴う分野では明確な品質特性として扱われます。 しかし、一般的なソフトウェアでは、安全性の定義が文脈によって異なるため、ISOではそれを複数の特性に分けて評価する方針を取っています。[Google/AI]
安全性が品質特性に含まれない理由は、製品品質と利用時品質の区別：品質特性は「製品品質」と「利用時品質」に分けられ、安全性は製品自体の特性というよりも、その製品が利用される「状況」におけるリスク回避（リスク回避性）という文脈で評価されるためです。
以下のサイトも勉強になりました。
ISO 25010 のソフトウエア品質特性の紹介
Discussion