Systems analysis in IT — ITにおけるシステム分析

From Systems analysis wiki
Jump to navigation Jump to search

ITにおけるシステム分析（Systems Analysis and Design）とは、構想から運用までの情報システムの設計・開発に対するアプローチであり、ニーズの特定、要求の形式化、対象領域とプロセスのモデリング、代替案とリスクの評価を含みます。言い換えれば、ITにおけるシステム分析とは、専門家が課題を調査し、システムが何をすべきかを定義し、その構築のためのソリューションを開発する、開発の一段階です。

古典的なシステム分析は、ソフトウェア開発だけでなく、組織改革、戦略、その他の側面など、幅広い応用分野を対象としています。[1] [2]

ITにおけるシステム分析の対象とタスク

ITにおけるシステム分析の対象は、構想・正当化から実装・運用に至るまでのライフサイクル全体にわたる情報システム（ソフトウェア製品および／またはサービス）です。

システム分析のタスクは、ビジネスニーズを、整合性が取れ検証可能な要求とアーキテクチャ設計のセットに変換することです。具体的には、ステークホルダーの目標と制約を特定・文書化し、要求を形式化し、対象領域とプロセスをモデル化し、代替案の実現可能性とリスクを評価し、選択したアーキテクチャを正当化します。その結果、合意された文書が作成され、要求、設計、テスト間の追跡可能なリンクが確立されます。これにより、開発プロセスの管理性と統制が確保されます。

システム分析のタスクには以下が含まれます。

  • ステークホルダーのニーズと目標の特定。アナリストは、顧客、ユーザー、その他の利害関係者の期待を収集・明確化します。インタビュー、アンケート、観察、現行プロセスの分析などが用いられます。成果物として、機能要件（「システムが何をすべきか」）と非機能要件（信頼性、パフォーマンス、セキュリティなど）に分けられた初期の要求仕様書が作成されます。[1][2]
  • 要求の形式化と文書化。要望は検証可能な要求に変換されます。適切に記述された要求は、明確かつ一義的で、完全、無矛盾、検証可能、そして上位の目標に対して追跡可能でなければなりません。要求のセットは、整合性が取れ、一貫している必要があります。[3][4] 実務では、ISO/IEC/IEEE 29148に準拠したSRS（Software Requirements Specification）や、特定の業界ではURS（User Requirements Specification）や機能仕様書などの標準化された文書が使用されます。[5][6][7]
  • システムの分析とモデリング。システムがどのように動作し、外部とやり取りするかを理解するためにモデルが構築されます。ユースケースシナリオのためのユースケース図（Use Case）、データフローとビジネスプロセスのためのDFD、クラス図やコンポーネント図などです。モデルは、代替ソリューションやアーキテクチャを比較検討するための基礎となります。[8][9][10]
  • 実現可能性の評価とソリューションの選択。feasibility study（技術的、組織的、経済的、スケジュール的な実現可能性調査）とアーキテクチャの代替案の比較（trade-off）が行われます。アーキテクチャの品質属性（パフォーマンス、スケーラビリティ、変更容易性など）を評価するために、ATAM（Architecture Tradeoff Analysis Method）などの手法が用いられます。[11][12] 例えば、モノリシックアーキテクチャとマイクロサービスアーキテクチャ[3]の選択は、業界ガイドラインの推奨に基づき、明確なトレードオフ（運用複雑性 vs. 独立したスケーラビリティとデリバリー速度）に依存します。[13][14]
  • 設計成果物の準備。分析の結果、以下のものが作成されます：
    • 承認された要求仕様書（重要度を明記）、
    • システムの概念モデル（図/記述）、
    • アーキテクチャおよび設計（データスキーマ、外部システムインターフェース）、
    • 実装計画（フェーズ/モジュール）。
    • 要求から設計要素、テストへのトレーサビリティ（bidirectional traceability）を確保することが重要です。[15][4]

ITプロジェクトの成功は、要求とアーキテクチャに関する成熟した実践に大きく依存します。McKinseyとOxfordが実施した調査によると、大規模なITプロジェクトは予算やスケジュールを超過することが多いことが示されています。この調査はまた、戦略の適切な管理、ステークホルダーとの連携、要求の的確な収集がいかに重要であるかを強調しており、これらがプロジェクトの成否に大きく影響する可能性があることを示しています。[16]

ITシステム分析におけるアプローチと方法論

ITにおけるシステム分析は、システム思考の原則と、ソフトウェア開発に適合させた手法に基づいています。実務では、「ハード」アプローチと「ソフト」アプローチ、構造化方法論、オブジェクト指向記法、プロセスや要求のモデリング言語が組み合わせて使用されます。

  • ハードアプローチとソフトアプローチ。ITプロジェクトにおけるハードアプローチ（hard systems）は、事前に形式化された目標と要求、トップダウンの分解と設計を前提とします。ソフトアプローチ（soft systems）は、目標が不明確で複数の視点が存在する場合に適用されます。ソフトシステムズ方法論 (SSM)の要素（例：rich picture、ルート定義、CATWOE）を用いて問題の理解と望ましい変更について合意を形成し、その結果を形式的な要求に変換します。[17][18]
  • SSM（ソフトシステムズ方法論）。もともと組織変革のためにピーター・チェックランドによって開発されたSSMは、ITのプロジェクト前段階で有用です。問題状況の調査、ルート定義の策定（CATWOEを含む）、概念モデルと現実との比較、ステークホルダー間の合意形成（accommodation）に至るまで活用されます。[19][20]
  • 構造化方法論：SADT/IDEF0。SADTはシステムを機能の階層としてモデル化します。標準記法であるIDEF0（IEEE 1320.1）は、機能とそのI-C-O-Mインターフェース（Inputs, Controls, Outputs, Mechanisms）を定義します。この手法は、アルゴリズムに依存しない機能分割とシステム境界の合意形成に便利です。[21][22]
  • オブジェクト指向分析： UMLとSysML（MBSE）。UMLは要求と設計のための基本言語（ユースケース図、クラス図、シーケンス図など）となり、ユーザーとのシナリオ検証を容易にします。SysMLはUMLをシステム工学向けに拡張（要求図、パラメトリック図）し、要求からテストまでの各段階でモデルを中心的成果物とするMBSEアプローチに基づいています。[23][24][25]
  • ビジネスプロセスモデリング： BPMN。BPMN標準は、プロセス（プール、ワークフロー、イベント、ゲートウェイ）をグラフィカルに記述するために使用され、要求仕様書や統合におけるas-is/to-beの比較にも用いられます。[26][27]
  • 要求工学との関連。プロセスには、elicitation–analysis–specification–validation–change managementの各段階が含まれます。「良い要求」の基準とSRSの構造はISO/IEC/IEEE 29148で規定されています。優先順位付けにはMoSCoW（Must/Should/Could/Won’t）技法や、AHPなどの多基準意思決定法が適用されます。アジャイルプロセスでは、システム分析の活動はバックログリファインメントと要求のトレーサビリティに反映されます。[28][29][30][31]
  • システム工学との関連。複雑な（サイバーフィジカル）システムにはV字モデルが適用されます。「左側」のブランチではシステム分析とアーキテクチャ設計を行い、「右側」のブランチでは左側の成果物と連携させながら統合、ベリフィケーション、バリデーションを行います。品質属性に基づくアーキテクチャ評価手法にはATAM（トレードオフ分析）が含まれます。[32][33]

ITにおけるシステム分析は、ビジョンを調整するためのソフトな手法から、形式的な記法や標準まで、実績のあるアプローチを組み合わせています。ツールの選択はタスクの明確さの度合いによって決まります。不確実性が高い場合はSSMとファシリテーションの役割が強まり、境界が明確な場合は形式的なモデル（UML/SysML, IDEF0, BPMN）と標準が用いられます。

ITアーキテクチャおよびエンタープライズアーキテクチャとの関連

ITプロジェクトにおけるシステム分析は、アーキテクチャ設計と密接に関連しています。アナリストとアーキテクトの役割は重複しており、アナリストが要求と論理モデルを策定し、アーキテクトがソリューションの目標構造と技術的なトレードオフを決定します。作業は共同で行われます。

  • ITシステムアーキテクチャ。狭義には、ソフトウェアアーキテクチャとは、コンポーネントの構成、それらの関係、およびソリューション設計を導く原則のことです。非機能要件（信頼性、スケーラビリティ、変更容易性）がアーキテクチャ上の決定とそのトレードオフをしばしば決定するため、アナリストはアーキテクチャスタイル（階層型、クライアント・サーバー型、マイクロサービス型、イベント駆動型など）を考慮することが重要です。[34][35] 分析の初期段階では、アーキテクチャビジョン（high-level vision）を形成し、要求の実現可能性を検証するためにソリューションの草案を作成します（イテレーションの長さと詳細度は方法論に依存します）。[36]
  • パターンと事前ソリューション。非機能要件を満たすために、アーキテクチャパターンが適用されます。例えば、非同期通信と疎結合のためには、イベント駆動型アーキテクチャにおいてメッセージブローカーを介したpublish–subscribeパターンが用いられます。[37]
  • TOGAF (The Open Group Architecture Framework)。最も普及しているエンタープライズアーキテクチャフレームワークの一つであり、ADM（Architecture Development Method）とアーキテクチャ管理のための成果物（リポジトリ、カタログ/マトリクス、原則）を含みます。TOGAFでは、要求管理はADMの全フェーズに統合された横断的なプロセスです。[36] 要求とトレーサビリティをサポートするために、カタログとマトリクス（例：要求 ↔ サービス、機能 ↔ コンポーネント）が使用され、Architecture Building BlocksとSolution Building Blocksが区別されます。[38][39] 企業の原則と標準は、対応するカタログに記録され、プロジェクトチームにとって外部の非機能要求として機能します。[40] ソリューションが目標アーキテクチャに準拠しているかは、アーキテクチャコンプライアンスレビュー（Architecture Compliance Review）の手続きによって確認されます。[41] TOGAFのアプローチは、事前のArchitecture Visionと、その後の詳細化（データ/アプリケーション/テクノロジー）、移行計画、要求変更管理を前提としています。[42][43]
  • Zachman Framework。エンタープライズアーキテクチャの成果物に関する初期の影響力のあるオントロジーで、6×6のマトリクス（視点 × 側面「何/どうやって/どこで/誰が/いつ/なぜ」）として提示されます。「設計者」の行はシステム分析と設計に対応し、列はデータ、機能/プロセス、役割、場所、動機の網羅性を規定します。このフレームワークは（方法論ではなく）分類として機能し、企業ランドスケープにおけるソリューション記述の完全性を確保するのに役立ちます。[44]
  • エンタープライズアーキテクチャ（Enterprise Architecture, EA）との関連。システムアナリストはEAのコンテキスト内で作業します。新しい要求はビジネス能力と運用モデルに追跡され、企業の標準と原則的な制約（セキュリティ、互換性など）が適用されます。[45][36] 開始段階でArchitecture Vision（目標/制約、大まかな要求）が形成され、その後アナリストはビジョンと企業標準へのトレーサビリティを維持しながら詳細化します。標準に準拠しない場合はアーキテクチャレビューで特定され、ソリューションの修正につながる可能性があります。[36][46]

結論として、システム分析とアーキテクチャ設計は「要求 → アーキテクチャ上の決定 → 品質属性に関するトレードオフ」という連携を形成します。手法（スタイル/パターン、TOGAFの成果物、Zachmanの分類）の選択は、プロジェクトの性質とエンタープライズアーキテクチャの枠組みによって決まります。

プロセスと実践

システム分析は、ソフトウェアの開発・運用のライフサイクル全体に統合され、ビジネス目標、アーキテクチャ、デリバリーを結びつけます。これには、プロジェクト前の調査、アプローチの選択、検証可能な成果物の作成、信頼性、パフォーマンス、セキュリティ、保守に関する要求が含まれます。ウォーターフォールモデルでは、分析は設計と実装の前に行われますが、アジャイル手法ではイテレーションを通じて継続的に行われ、DevOpsでは運用目標に重点が置かれます。アプローチに関わらず、分析はトレーサビリティ、変更とリスクの管理、アーキテクチャ上のトレードオフの文書化、規制遵守を保証し、開発を予測可能で管理可能なものにします。

  • クラシックSDLC（ウォーターフォール）。システム分析と要求定義のフェーズは、設計と実装に先行します。要求は詳細なSRSに固定され、計画と契約の基盤となります。安定的で規制の厳しいドメインで効果的です。要求が「凍結」されるリスクは、SRR/レビューとCCBによる変更管理によって低減されます。[47][48][49]
  • アジャイル方法論。分析は継続的です。最終的なSRSの代わりに、受け入れ基準付きのユーザーストーリーからなるプロダクトバックログを管理し、バックログリファインメントで詳細化します。BDD（Given–When–Then）が適用されます。全体的なアーキテクチャを見失うリスクは、早期のアーキテクチャ検討と、要求 ↔ 実装/テスト間の透明なトレーサビリティによって補われます。[50][51][52]
  • DevOpsとSRE。頻繁なリリースには、自動化、可観測性、ロールバックといった運用上の要求が「デフォルトで」求められます。非機能要件はSLO/SLIとして策定され、エラーバジェットが管理されます。バックログにはログ/メトリクス/トレース/アラートに関するタスクが追加されます。ダウンタイムなしのリリースには、blue/greenなどのパターンが用いられます。[53][54][55]
  • 要求とリスクの管理。ALMにおける要求は、ステータスを持ち、タスク/リリース/不具合と関連付けられます。バージョン管理、変更影響分析、定期的な再優先順位付けが必須です。[56][57]
  • 品質保証（QA）。品質は要求段階で作り込まれます。レビュー、「Three Amigos」、Acceptance Test Planの策定、受け入れ基準の自動テスト（BDD/ATDD）が行われます。[58][59]
  • 可観測性と信頼性。要求にはSLA/SLO、MTTR、MTBFが、測定可能な目標と管理方法とともに含まれます。これらのパラメータはビジネス/運用部門から提供され、アーキテクチャと信頼性テストに組み込まれます。[60][61]

メトリクスと成果物の品質

システムアナリストの仕事とその成果の質を評価するために、一般的に受け入れられている基準が適用されます。質の高い要求とモデルはプロジェクト成功の基盤であるため、ライフサイクル全体（elicitation → specification → verification/validation → change management）で管理されます。要求品質の基本属性は、ISO/IEC/IEEE 29148や（歴史的には）IEEE 830などの標準で定められています。[3][62][1]

  • 正確性 (Correctness) — 要求が真のニーズを反映し、対象領域の専門家と合意されていること。バリデーション（レビュー/インスペクション、プロトタイプ、シナリオ）によって確認されます。[1][4]
  • 完全性 (Completeness) — 重要な側面や条件が考慮されていること。
    • 個々の要求の完全性: 必要な詳細が記載されていること（例：「インジケーターは障害時に赤色になる」であり、単に「赤くなる」ではない）。
    • 仕様書の完全性: シナリオ/役割が網羅され、NFRが定義されていること。チェックリストやビジネス目標へのトレーサビリティによって達成されます。独立した完全性監査（QA/レビュー）が有効です。[3][63]
  • 明確性 (Unambiguity) — 表現が唯一の方法で解釈されること。用語集、«システムはCの場合、BのときにAをすべき» のようなテンプレート、具体例が役立ちます。図には凡例を添えます。検証には「フォーアイズ」原則（ダブルチェック）が用いられます。[3][1]
  • 一貫性 (Consistency) — 要求が互いに、また外部の制約と矛盾しないこと。構造化、属性の集計表、チームレビューが適用されます。規制/標準との照合が行われます。[3][63]
  • 検証可能性 (Verifiability) — 達成がテスト/デモ/分析によって確認できること。検証不可能な表現は測定可能な基準に置き換えられます。NFRにはメトリクスを設定し、受け入れ基準を事前に定めます。[3][63]
  • 変更可能性とトレーサビリティ (Modifiability & Traceability) — 一意のID、論理的な構造（「一段落一主題」）、重複の排除。«要求 ↔ ソース/目標/設計/テスト» の関連が維持され、トレーサビリティマトリクス (RTM)が管理されます。[64][3]
  • ランク付けと優先順位付け — 要求セットの品質。MoSCoWやMCDM（例：AHP）などの技法が使用されます。ビジネスとの共同での優先順位付けは、計画とリスクに影響します。[65][66]

要求品質のメトリクス（例）：[63][1]

  • 要求の不具合密度（100要求あたりの指摘数）。
  • ベースライン確定後の変更数。
  • カバレッジメトリクス：テストを持つ要求の割合、ビジネス目標に追跡可能な要求の割合。
  • 要求の安定性（期間内の追加/削除された要求と総数との比率）。
  • 仕様書のサイズ/複雑性（ユースケースあたりの平均要求数、分解の深さ）。
  • ステークホルダーの満足度（アンケート）。

成熟したプロセス（例：CMMIレベル3以上）では、要求品質に関する規定が設けられています。形式的なレビュー、テンプレートへの準拠監査、メトリクスの収集/分析などです。[67] クリティカルなドメイン（航空電子、宇宙など）では、信頼性を高めるために形式手法が適用されます。[68]

よくある間違い

ITプロジェクトでは、システム分析における間違いが頻繁に発生します。要求の不完全性や曖昧さ、矛盾、スコープの曖昧さ、非機能要件の無視、統合の見落とし、セキュリティ対策の遅れなどです。これらは手戻り、遅延、コスト増、不具合につながります。

典型的な問題、その結果、および防止策を以下に示します。

  • 不完全性と要求の見落とし。特別な権限を持つ役割、境界ケース、NFRが見落とされます。結果：アーキテクチャの再設計やリリースの延期。回避策：チェックリスト、«もし〜だったら» というブレインストーミング、テスターの早期関与、ビジネス目標へのトレーサビリティ。[1][69]
  • 不明確で曖昧な表現。結果：開発者が「違うもの」を実装し、顧客が不満を抱く。回避策：測定可能な基準、用語集、«AはBのとき、Cの場合に» というテンプレート、ピアレビュー。[3][69]
  • 矛盾した要求。結果：明確化のための遅延、統合時の手戻り。回避策：構造化、ビジネスルール/規制の確認、対立解決セッション、レビューでの一貫性チェック。[3][1]
  • 「金メッキ」症候群 (gold‑plating)。結果：スコープの肥大化、複雑化、新たな障害点の発生。回避策：各要求を目標/メトリクスに結びつける。アジャイルでは、不要なものをバックログに含めない。スコープを固定する。参照：YAGNI。
  • 不要な箇所での過剰な詳細化。回避策：何/なぜ（要求）とどうやって（設計/実装）を分離する。適切な場合にはdesign‑free requirements（設計に依存しない要求）を適用する。[3]
  • 要求管理の不備。結果：バージョンの混乱、「違うもの」の実装。回避策：ALMでの単一の情報源、履歴管理とステータス、RTMと変更影響分析、CCBによる変更管理。[64][1]
  • ユーザーの関与不足。回避策：インタビュー、観察、プロトタイプ、定期的なデモ。ステークホルダーとの明確なバリデーション。[3][1]
  • 長すぎる「分析麻痺」。回避策：十分性の範囲設定、イテレーションとタイムボクシング。MVP/インクリメントのリリースとフィードバックに基づく修正。[1]
  • 非機能要件の無視。回避策：NFR（例：FURPS+）を特定し、測定可能な基準を設定し、テスト計画とアーキテクチャ設計に含める。[1][3]
  • コミュニケーションエラーと「人的要因」。解決策：インタビューとファシリテーションスキルを向上させ、中立性を保ち、決定事項と要求の源泉を記録する（目標へのトレーサビリティ）。[1]

ほとんどの問題は、表現の質、完全性、要求の管理性に起因します。ISO/IEC/IEEE 29148標準やSWEBOKの実践（検証可能性、トレーサビリティ、イテレーション）を適用することで、スケジュールの遅延や手戻りのリスクを大幅に低減できます。[3][1]

限界

システム分析は不確実性を低減する上で効果的ですが、いくつかの限界があります。

  • 現実は変化し、複雑である。特に長期プロジェクトでは、すべての要因を考慮することは不可能です。一部の要求は、システム稼働後に初めて明らかになることが避けられません。予期せぬ事態を最小限に抑える努力は重要ですが、変化に備える必要もあります。
  • 要求は人に依存する。ビジネスの優先順位、法律、市場は変化する可能性があります。システム分析は現状を記録するものであり、すべての外部変化を予測することはできません。適応するためには、要求を定期的に更新し、イテレーティブに作業する必要があります。
  • ユーザーは、見るまで自分が何を望んでいるかを知らないことがある。これはよく知られた制約です。プロトタイピングやアジャイルなどの柔軟な方法論は、この問題を克服するのに役立ちます。机上での分析には限界があり、正確なデータを得るには実装からのフィードバックが必要です。
  • 時間と品質のバランス。過度に詳細な分析は時代遅れになる可能性があります。革新的な分野では、最小実行可能製品（MVP）を迅速に作成し、実際のデータを収集する方が良い場合があります。システム分析は安定した分野で効果的ですが、研究開発（R&D）プロジェクトではその役割は限定的です。
  • 人的要因。最高の方法論であっても、アナリストの能力不足や顧客の非協力的態度を補うことはできません。プロセスのすべての参加者が関与し、意欲的であることが重要です。

現代技術がITシステム分析に与える影響

ITにおけるシステム分析は、技術革新の影響を受けて絶えず進化しています。21世紀のアナリストは、データの爆発的増加、AIの広範な導入、迅速な開発サイクル、セキュリティへの関心の高まりといった環境で働いています。成功するシステム分析の実践には、新しい知識（データサイエンス、サイバーセキュリティ、クラウド技術）の習得と、手法の柔軟な適用が求められます。

  • データとAI/ML：分析に追加されるもの。AIを搭載したシステムでは、初期段階で適用の目的とコンテキスト、データソースと品質に関する要件、モデルの決定に対する信頼性メトリクス（信頼性、安全性、説明可能性、機密性、公平性）を定義します。TEVV（testing, evaluation, verification, validation）の計画、運用中のモニタリング、モデルの安全な停止/廃止が計画されます。これらのステップは、NISTのAIリスク管理フレームワークにおけるGOVERN–MAP–MEASURE–MANAGEの機能に対応しており、SRS、アーキテクチャ、検証/運用計画に反映されます。[70]
  • DevSecOps：セキュリティの「シフトレフト」とデフォルト化。CI/CDの各段階にセキュリティを組み込むことが標準となりつつあります。自動化された検査（SAST/DAST）、依存関係やコンテナのスキャン、デプロイポリシー、基本的な可観測性などです。信頼できるアーティファクトレジストリや標準化された「強化済み（hardened）」イメージが使用され、ゼロトラストの原則が適用されます。システム分析では、パイプラインのチェックポイント（各ステージの通過条件）、要求とセキュリティ管理策の関連付け、環境間（dev/test/stage/prod）の移行ルールを事前に記述します。[71]
  • ドキュメント（成果物）の変化点。ビッグデータやAI/MLが存在し、DevSecOpsで作業する場合、主要なドキュメントでどのセクションが追加または明確化されるか：
    • SRS / 要求仕様書：AIの利用目的とコンテキスト。データ要件（出所、品質、倫理的・法的制約）。モデルのメトリクス（精度、信頼性、応答時間）。TEVV（testing, evaluation, verification, validation）計画。透明性/説明可能性とプライバシーに関する要件。モデルの運用停止/廃止基準。[70]
    • アーキテクチャと設計（Architecture, ADR）：脅威モデリングの結果。「デフォルトでのセキュリティ」対策（暗号化、アクセス制御、シークレット管理、最小権限の原則）。データ/モデルの利用に関する制約。リスク評価とトレードオフを記録したADR。[71][70]
    • 検証・妥当性確認計画（V&V / TEVV）：モデルとデータのテストシナリオ。品質メトリクスの受け入れ閾値。データ/モデルのドリフト監視。定期的な再評価と再バリデーションの手順。[70]
    • CI/CDポリシーとパイプラインの「ゲート」：自動化されたSAST/DAST検査、SCA（依存関係）、コンテナスキャン。信頼できるレジストリでのアーティファクト署名と保管。環境間（dev/test/stage/prod）のプロモーションルールと、検査失敗時のビルドブロック条件。デフォルトでの可観測性要件。[71]
    • データおよびモデル管理計画：データソースとリネージのカタログ。データの品質と可用性の基準。データセット/モデルのバージョン管理。（再）トレーニングのスケジュールとバイアス管理。アクセスと保管のポリシー。必要に応じたモデルの安全な無効化とデータ削除計画。[70]
    • 運用と可観測性（Ops/Runbook）：AIの信頼性メトリクスとSLO。監査とロギング。劣化/異常に関するアラート。インシデント対応計画。AIコンポーネントのフォールバック/キルスイッチ。報告と事後分析に関する要件。[70][71]
    • トレーサビリティ（エンドツーエンド）：ライフサイクル全体でセキュリティと品質を証明可能に検証できるよう、「要求 ↔ パイプライン内の管理/検査」および「要求 ↔ 運用中のテスト/モニタリング」の明確な関連付け。[71][70]
  • システムアナリストの役割。
    • AIのコンテキストとリスク（関係者、利用シナリオ、データの前提と制約）を管理する。
    • 「要求 ↔ パイプライン内のセキュリティ管理」のトレーサビリティを確保する。
    • システムのライフサイクル全体にわたって、検証可能な非機能要件（セキュリティ、透明性、可観測性）を策定する。[70][71]

古典的なシステム分析との違い

「システム分析」という用語は、歴史的にソフトウェア開発よりも広い意味を持ちます。古典的なシステム分析は、複雑な学際的問題（社会的、経済的、経営的）を解決するためのアプローチであり、システム思考と定量的手法に基づき、通常は経営上の意思決定を支援するために用いられます。IT分野では、システム分析はソフトウェア工学における応用分野と見なされ、情報システムの構築に焦点を当てています。

以下に主な違いを示します。

  • 目標と分析対象。古典的な分析は、構造化が不十分で「曖昧な」問題を解決し、既存の社会技術システム（都市交通網、企業戦略、環境政策）を改善します。対象は現実のシステムであり、タスクは意思決定者が行動方針を選択するのを助けることです。一方、ITにおけるシステム分析の目標は、要求を満たす新しい情報システムやソフトウェア製品を設計・構築することです。対象は設計中のシステムであり、ユーザーが必要とする振る舞いや特性に焦点が当てられます。
  • 方法論的基礎。古典的な学派はシステム思考と、しばしば数学に依拠します。ハードアプローチ（hard systems）は、問題の形式化、定量的基準、最適化（オペレーションズ・リサーチのように）を特徴とします。ソフト方法論（soft systems）は、複数の視点の存在を認めます。例として、議論と概念モデルを通じて望ましい変化について合意を形成するソフトシステムズ方法論 (SSM)があります。IT分野の基礎は、要求工学、ソフトウェア設計、アーキテクチャフレームワークといった工学分野です。標準化されたプロセス（ISO/IEC/IEEE 15288, 12207, 29148）、UML/SysML記法、変更管理の実践が適用されます。
  • 役割と成果物。古典的な分析では、「システムアナリスト」の役割はしばしば非公式です。成果物は分析レポート、提言、数理モデル、「もしも」シナリオなどです。IT分野では、アナリスト（またはビジネスアナリスト）の役割は形式化されており、要求仕様書、システムモデル（UML, ER）、インターフェース仕様書、ユーザーストーリー、バックログといった、開発者やテスターが直接使用する成果物を作成します。
  • ライフサイクルとプロセス。古典的な分析には統一されたテンプレートがなく、ステップは問題に依存します（SSMでは状況調査から変更導入まで）。IT分野では標準的なSDLCサイクルが採用されています。ウォーターフォールモデルには独立した要求分析フェーズがあり、イテレーティブおよびアジャイルアプローチでは、分析は各スプリントで継続的に行われる活動です。現代の実践（DevOps, CI/CD）は、分析の範囲を運用まで拡張し、保守、可観測性、更新可能性に関する要件を考慮します。言い換えれば、ITにおけるシステム分析は開発ライフサイクルに組み込まれているのに対し、古典的な分析はプロジェクトベースまたはコンサルティング活動として行われることが多いです。

システムアナリスト

ITシステムアナリスト とは、情報システムの設計・開発においてシステム思考を担う専門家であり、要求の策定と検証、モデリング（UML/BPMN）、アーキテクチャ設計の合意形成、統合の確保に責任を持ちます。ロシア連邦では、この役割と資格要件が職業標準と連邦国家教育基準で定められています。

専門的活動の主目的： システムのライフサイクル全体にわたり、利害関係者への高品質かつ相互に関連した設計ソリューションの開発と伝達、個々の担当者の作業の開始と調整を通じて、ITサービス、自動化システム、自動化情報システム、自動化管理システム、ソフトウェア、情報製品またはツール（以下、システム）が、その環境、初期要求と制約、自動化の目標、および自動化された活動に適合することを保証すること。（ロシア連邦労働省令 2023年4月27日付 第367н号「職業標準『システムアナリスト』」）。[72]

主要用語集

基本概念と参加者

  • ITにおけるシステム分析 — 構想から運用までのライフサイクル全体にわたる情報システムを対象とする学問分野。
  • ステークホルダー — プロジェクトに関心を持つ、または影響を受ける個人やグループ（顧客、ユーザー、マネージャーなど）。
  • 設計成果物 — 仕様書、モデル、計画、決定など、プロジェクトの過程で作成される文書や成果物。

要求：種類と文書化

  • 機能要件 — システムが何をすべきか、その機能と振る舞いを記述するもの。
  • 非機能要件 — システムの品質属性（信頼性、パフォーマンス、セキュリティ、使いやすさ、スケーラビリティなど）を記述するもの。
  • 要求仕様書（初期） — プロジェクトの初期段階で収集された最初の要求セットを含む文書。
  • SRS (Software Requirements Specification) — 国際標準（例：ISO/IEC/IEEE 29148）に従ってソフトウェア要件を詳細に記述する標準化された文書。
  • URS (User Requirements Specification) — ビジネスプロセスとエンドユーザーの期待の観点から、システムに対するユーザーの要求を記述する文書。
  • アーキテクチャ上重要な要求 (ASR) — アーキテクチャ上の決定とトレードオフに大きな影響を与える要求。
  • 横断的要件 (CFR) — 非機能要件の同義語で、その横断的な性質を強調するもの。
  • 受け入れ基準 (Acceptance Criteria) — 要求に関する作業が完了したと見なされるための、検証可能な条件。
  • Definition of Ready (DoR) — バックログ項目が開発に着手できる状態（明確さ、見積もり、基準）にあることの合意。
  • Definition of Done (DoD) — 作業が「完了」したこと（コード、テスト、文書、デプロイ）の合意。
  • 制約 (Constraint) — 決定を制限する厳しい条件（納期、プラットフォーム、標準、ライセンス）。
  • 前提 (Assumption) — 証明なしに受け入れられる仮定で、後の検証が必要なもの。
  • 要求品質 — ISO 29148に基づく特性：明確性、完全性、一貫性、検証可能性、原子性。

要求の形式化、トレーサビリティ、優先順位付け

  • 要求の形式化 — 非公式な要望を、明確で検証可能かつ一義的な要求に変換するプロセス。
  • 要求トレーサビリティ — 要求のライフサイクルを、その源泉から実装、テスト、デプロイまで追跡する能力。
  • Bidirectional traceability (双方向トレーサビリティ) — 要求、設計要素、テストシナリオ間の関連を順方向と逆方向の両方で追跡する能力。
  • MoSCoW — 要求をMust-have（必須）、Should-have（あるべき）、Could-have（あってもよい）、Won't-have（今回は含めない）に分類する優先順位付け技法。
  • BDD (Behavior-Driven Development) — ユーザー視点でのシステムの振る舞いに焦点を当てた自然言語（Given–When–Then形式）でテストを記述する開発方法論。

記法とモデリング

  • UML (Unified Modeling Language) — ソフトウェアシステムのコンポーネントを仕様化、可視化、構築、文書化するための標準化されたグラフィカルモデリング言語。
  • SysML (Systems Modeling Language) — UMLをシステム工学向けに拡張したもので、要求、振る舞い、構造、パラメータなど、複雑なシステムの様々な側面をモデリングすることをサポートする。
  • BPMN (Business Process Model and Notation) — ビジネスプロセスを記述するための標準的なグラフィカル記法で、ワークフロー、イベント、ゲートウェイ、プールを可視化できる。
  • MBSE (Model-Based Systems Engineering) — 要求からテストまで、システムのライフサイクルの全段階でモデルを中心的成果物とするシステム工学のアプローチ。
  • ArchiMate — エンタープライズアーキテクチャ（ビジネス、アプリケーション、テクノロジー）とその関連性を記述する記法。
  • DMN (Decision Model and Notation) — ビジネス上の決定とルールテーブルをモデリングする記法。
  • DFD (Data Flow Diagram) — データフロー図（コンテキスト、分解レベル）。
  • ERD (Entity-Relationship Diagram) — エンティティ、関連、属性を持つ対象領域のモデル。
  • CRUDマトリクス — Create/Read/Update/Delete操作とエンティティ、役割/機能との対応関係。

アーキテクチャスタイルとソリューション評価

  • モノリシックアーキテクチャ — システム全体を単一の分割不可能なモジュールとして開発するアーキテクチャアプローチ。
  • マイクロサービスアーキテクチャ — システムを、独立してデプロイ・スケール可能な小さなサービスの集合として構築するアーキテクチャアプローチ。
  • トレードオフ — 一方の特性を改善することが他方の特性の悪化につながるような、相互に排他的または矛盾する特性や決定の間での選択。
  • ATAM (Architecture Tradeoff Analysis Method) — 品質属性（パフォーマンス、スケーラビリティなど）間のトレードオフを分析するために使用されるソフトウェアアーキテクチャ評価手法。

エンタープライズアーキテクチャとフレームワーク

  • TOGAF (The Open Group Architecture Framework) — 最も普及しているエンタープライズアーキテクチャフレームワークの一つで、アーキテクチャを開発・管理するためのADM（Architecture Development Method）を含む。
  • Zachman Framework — エンタープライズアーキテクチャの成果物のオントロジーで、6×6のマトリクスとして提示され、様々な視点からアーキテクチャの様々な側面を分類する。

分析アプローチと開発プロセス

  • ハードアプローチ (Hard Systems) — 事前に形式化された目標と要求、トップダウンの分解と設計を前提とするシステム分析方法論で、明確に定義された課題に有効。
  • ソフトアプローチ (Soft Systems) — 目標が不明確でステークホルダーの視点が複数ある場合に適用されるシステム分析方法論で、問題の理解と望ましい変更について合意形成を目指す。
  • SSM (Soft Systems Methodology) — ピーター・チェックランドによって開発された具体的なソフトシステムアプローチの方法論で、rich picture、ルート定義、CATWOEなどのツールを使用する。
  • ウォーターフォール (カスケードモデル) — ソフトウェア開発の古典的な方法論で、各段階（分析、設計、実装、テスト、導入）を順次実行し、前の段階を完全に終えてから次の段階に進む。
  • アジャイル — イテレーティブな開発、変化への適応、顧客との協調、価値の継続的提供に重点を置く、ソフトウェア開発の柔軟な方法論群。

選択手法と典型的なエラー

  • AHP (Analytic Hierarchy Process) — 複雑な問題を構造化し、基準の階層に基づいて代替案を評価できる多基準意思決定法。
  • Gold-plating (金メッキ症候群) — ステークホルダーに要求されていない機能を追加してしまうシステム分析のエラーで、プロジェクトのスコープと複雑性の増大につながる。

関連リンク

参考文献

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5th ed.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Official free version.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Official free download (under license).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4th ed.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3rd ed.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2nd ed.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5th ed.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3rd ed.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4th ed.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11th ed.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8th ed.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7th ed.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2nd ed.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4th ed.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4th ed.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2nd ed.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

注釈

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. 「well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable」の定義。 https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (URSについて言及). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — アーキテクチャ記述と視点に関する要求。 https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (overview). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (specification). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (EAの定義として「organizing logic for business process and IT capabilities…」). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Reprint (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (歴史的標準). 学習用コピー (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (要求/トレーサビリティの典型的な問題について). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н)。
Retrieved from "https://systems-analysis.ru/int/index.php?title=Systems_analysis_in_IT_—_ITにおけるシステム分析&oldid=9927"