A collection of notes and resources
システムアーキテクト試験対策資料
| 項目 | 内容 |
|---|---|
| 正式名称 | JIS X 25010:2013(ISO/IEC 25010:2011 に対応) |
| 位置付け | SQuaRE(Systems and software Quality Requirements and Evaluation)シリーズの一部。品質モデルを規定する中核規格 |
| 構成モデル | 製品品質モデル(Product Quality Model)と利用時品質モデル(Quality in Use Model)の2モデル |
| 前身規格 | ISO/IEC 9126(JIS X 0129)を改訂・拡張。特性数が6→8に増加 |
| 試験での重要度 | システムアーキテクト・システム監査技術者・プロジェクトマネージャ試験で頻出。非機能要件定義の根拠として論述で活用 |
製品品質モデルはソフトウェア自体が持つべき品質の軸を表す。利用時品質モデルは「ユーザの実際の使用文脈における品質」を扱う別モデルであり、高度試験ではどちらを問われているかを区別する必要がある(利用時品質モデルの5特性は5章を参照)。
| 品質特性 | 英語名 | 主な副特性 | 非機能要件例 |
|---|---|---|---|
| 機能適合性(機能要件) | Functional Suitability | 機能完全性、機能正確性、機能適切性 | ユーザが必要とする機能をどの程度提供するか |
| 性能効率性 | Performance Efficiency | 時間効率性、資源効率性、容量満足性 | 応答時間、スループット、CPU/メモリ使用率、接続数上限 |
| 互換性 | Compatibility | 共存性、相互運用性 | 他システムとのAPI連携、データ形式互換、サービス共存 |
| 使いやすさ | Usability | 適切度認識性、習得性、運用操作性、ユーザエラー防止性、UIの快美性、アクセシビリティ | 操作習熟時間、エラー発生率、バリアフリー対応レベル |
| 信頼性 | Reliability | 成熟性、可用性、障害許容性、回復性 | 稼働率(例:99.9%)、MTBF、RTO/RPO、フェイルオーバー要件 |
| セキュリティ | Security | 機密性、インテグリティ、否認防止性、責任追跡性、真正性 | 認証方式、暗号化レベル、ログ保全期間、アクセス制御ポリシー |
| 保守性 | Maintainability | モジュール性、再利用性、解析性、修正性、試験性 | 変更影響範囲、テストカバレッジ、コード複雑度、ドキュメント整備 |
| 移植性 | Portability | 適応性、設置性、置換性 | 対応OS・クラウド環境、インストール手順、旧システム置換条件 |
※ 「機能適合性」のみが機能要件に対応し、残り7特性は非機能要件として扱われる。定量的指標の設定まで落とし込むことで、アーキテクチャ設計の判断根拠となる。
| No. | 観点 | 説明 |
|---|---|---|
| (1) | 網羅性(見落とし防止のチェックリスト) | 8特性を順にレビューすることで「セキュリティを考慮していなかった」等の見落としを体系的に防げる |
| (2) | 共通言語化(顧客・開発者間の認識統一) | 「速い」「安全」等の曖昧な要求を標準用語に対応させ、解釈の齟齬をなくす |
| (3) | 要件分解(副特性による具体化) | 「信頼性」→「可用性(稼働率99.9%)」「回復性(RTO 4時間)」のように測定可能な指標へ分解できる |
| (4) | 定量化容易性(受入基準・テスト指標への転用) | 各副特性は定量的指標と紐付けやすく、後工程のテスト設計・受入検査の基準として転用できる |
| (5) | トレードオフ明示(設計判断の根拠提示) | 特性間の競合(例:セキュリティ強化 vs 使いやすさ低下)を意識した上でアーキテクチャ判断を文書化できる |
| (6) | 設計との接続(品質特性→タクティクス→パターン) | 非機能要件を設計タクティクス(冗長化・キャッシュ等)→アーキテクチャパターンへ体系的に展開できる |
品質特性・副特性の特定
→ 定量的指標の設定(非機能要件)
→ 設計タクティクスの選択
→ アーキテクチャパターンの決定
例)信頼性 → 可用性99.9%・RTO 4h → フェイルオーバー設計 → Active-Standby構成
| 特性A(向上) | 特性B(低下傾向) | トレードオフの内容と対処 |
|---|---|---|
| セキュリティ(高) | 使いやすさ(低) | 多要素認証・アクセス制限を強化すると操作の手間が増える。重要度に応じて許容レベルを決定 |
| 性能効率性(高) | 保守性(低) | キャッシュや最適化で速度を上げると、コードが複雑化して修正コストが上昇する |
| 信頼性(高) | 移植性(低) | 特定クラウドの高可用性機能に依存すると、他環境への移行コストが増大する |
| セキュリティ(高) | 性能効率性(低) | 全通信の暗号化・詳細ログ取得はCPU・ストレージコストを増加させる |
非機能要件は相互に競合する場合がある。論述では、複数特性の競合を認識した上で判断根拠を示すことが評価のポイントとなる。
POINT 論述式試験では、「なぜJIS X 25010を適用したか」という根拠を明記すること。チェックリスト機能による「用語の標準化」と「洗い出しの網羅性」を強調すると高評価を得る。