デザインレビュー

設計の各段階で、設計書などの成果物を関係者が評価し、要件を満たしているか、問題がないかを確かめるレビュー。設計の段階で欠陥を見つけて取り除くことで、後の工程での手戻りを減らす。DRと略す。

設計の各段階の成果物を、関係する部門や専門家が集まって評価し、要求事項を満たしているか、問題がないかを確かめるレビュー。次の段階に進む前に設計上の誤りや考慮漏れを見つけ、後の工程での手戻りを防ぐ。

設計の妥当性を関係者が確認する会議。DRともいい、工程の節目で実施して後戻りを防ぐ。

設計の各段階で、設計書が要件を満たしているか、実現性や品質、保守性に問題がないかを、設計者以外の関係者や有識者を交えて評価・確認する会議。問題を上流工程で見つけ、後工程での手戻りを減らす。

作成者と同じ立場や同程度の技術を持つ同僚が、成果物を調べて誤りや改善点を指摘するレビュー。管理者の評価の場にせず、技術的な問題の発見に集中できるので、率直な指摘が出やすい。インスペクション、ウォークスルーなどの形で行う。

システム設計の妥当性、完全性、整合性を検証するための公式なレビュー活動。基本設計、詳細設計の各段階で実施され、要件との適合性や設計上の問題点を早期に発見する。監査ではレビュー記録の確認を行う。

将来の業務量やユーザ数の増加を予測し、必要なシステム資源（CPU、メモリ、ディスク、ネットワーク帯域等）を事前に計画すること。過剰投資と性能不足の両方を避けるために、適切なサイジングを行う。

業務で扱う実体と、その属性および関係を構造として表したもの。概念、論理、物理の各段階があり、段階を追って実装に近づけていく。

概念データモデルを特定のデータモデル（関係モデルなど）に変換したもの。テーブル名、属性名、データ型、制約（主キー、外部キー、NOT NULLなど）を定義する。DBMS製品には依存しない。

システムの企画・要件定義段階で、脅威分析の結果やセキュリティポリシーに基づき、必要なセキュリティ機能や非機能要件を明確化すること。認証・認可、暗号化、監査ログ、可用性などの要件を含む。