srs-documentation

SRS ドキュメント作成スキル

概要

このスキルでは、IEEE 830 標準の構成に従った正式なソフトウェア要求仕様書（SRS）の作成方法を説明します。

IEEE 830 標準の構成

1. はじめに

1.1 目的

• SRS ドキュメントの目的を記述する
• 想定読者を特定する
• 対象範囲を明記する

1.2 範囲

• ソフトウェア製品を名前で特定する
• ソフトウェアの機能を説明する
• アプリケーションのメリット、目的、目標を説明する
• 関連する上位レベルの仕様書との一貫性を保つ

1.3 定義、頭字語、略語

• ドキュメントで使用する用語をすべて定義する
• 技術用語、頭字語、略語を含める
• 用語が多い場合は、用語集または付録を参照する

1.4 参考資料

• 参照するドキュメントをすべて列挙する
• ドキュメントのタイトル、番号、日付、出典を記載する
• バージョンまたは改訂情報を明記する

1.5 概要

• ドキュメントの構成を説明する
• 以降の各セクションの構成を説明する

2. 全体的な説明

2.1 製品の位置付け

• システムのコンテキスト：製品がより大きなエコシステムにどのように組み込まれるか
• システムインターフェース：他のシステムとの接続
• ユーザーインターフェース：UI に関する考慮事項と制約
• ハードウェアインターフェース：必要なハードウェア接続
• ソフトウェアインターフェース：必要なソフトウェア接続
• 通信インターフェース：ネットワークおよびプロトコルの要件
• メモリ制約：メモリとストレージの制限
• 運用：通常時および特別な運用モード
• 設置環境への適応要件：インストールおよびデプロイのニーズ

2.2 製品の機能

• 主な機能の概要
• 機能の概要
• ユーザーまたは業務機能別に整理する

2.3 ユーザーの特性

• 想定ユーザーの一般的な特性
• 教育レベル、経験、技術的な専門知識
• アクセシビリティに関する考慮事項

2.4 制約

• 規制要件
• ハードウェアの制限
• インターフェース要件
• 標準への準拠
• セキュリティに関する考慮事項

2.5 前提条件と依存関係

• 真であると想定される要素
• 他のシステムやコンポーネントへの依存関係
• 変更された場合に要件に影響する条件

3. 個別要件

3.1 外部インターフェース要件

• ユーザーインターフェース：詳細な UI 仕様
• ハードウェアインターフェース：ハードウェアとの連携の詳細
• ソフトウェアインターフェース：API と統合の詳細
• 通信インターフェース：プロトコル仕様

3.2 機能要件

次の項目別に整理します。

• 機能または処理
• ユーザークラス
• 業務オブジェクト
• 運用モード
• 刺激／応答のシーケンス

各要件には、次の内容を含めます。

• 一意の識別子（FR-XXX）
• 機能の説明
• 入力と出力
• 処理ロジック
• エラー処理

3.3 性能要件

• 応答時間の要件
• スループットの要件
• 容量の要件
• リソース使用量の上限

3.4 設計上の制約

• 標準への準拠
• ハードウェアの制限
• ソフトウェアの制約
• アーキテクチャ要件

3.5 ソフトウェアシステムの特性

• 信頼性：平均故障間隔、復旧
• 可用性：稼働時間の要件
• セキュリティ：アクセス制御、データ保護
• 保守性：変更の容易さ、ドキュメント
• 移植性：プラットフォーム要件

3.6 その他の要件

• データベース要件
• 運用要件
• 国際化要件

4. 付録

A. 用語集

定義した用語の完全な一覧

B. 分析モデル

• データフロー図
• ER 図
• 状態遷移図
• ユースケース図

C. 要件トレーサビリティマトリクス

• 要件と業務目標を対応付ける
• 要件とテストケースを対応付ける
• 要件間の依存関係を示す

作成ガイドライン

要件の特性

各要件は、次の特性を備えている必要があります。

特性	説明	例
必要性	システムの成功に必要	あれば望ましいというだけではない
明確性	解釈が一つに定まる	「ユーザー」を具体的に定義
完全性	必要な情報がすべて含まれている	エラーシナリオを含む
一貫性	矛盾がない	他の要件と整合している
検証可能性	テストできる	測定可能な基準
追跡可能性	明確な起点がある	ビジネスニーズへのリンク
変更容易性	簡単に変更できる	一意の ID、重複がない
優先順位付け	重要度順に並んでいる	MoSCoW 分類

要件の記述スタイル

推奨事項：

• 必須要件には「shall」を使用します
• 望ましい要件には「should」を使用します
• 任意の要件には「may」を使用します
• 具体的かつ定量的に記述します
• 用語を一貫して使用します
• 能動態で記述します
• 1つの記述につき要件は1つにします

避けるべき事項：

• 曖昧な用語（速い、使いやすい、柔軟など）を使用しないでください
• 可能な限り否定形の要件を避けてください
• 複数の要件を組み合わせないでください
• 設計や実装の詳細を含めないでください
• 用語を一貫して使用してください

例

良い要件：

FR-001: The system shall display search results within 3 seconds
of the user submitting a search query.

悪い要件：

The system should be fast and display results quickly.

要件 ID の規約

機能要件

FR-XXX: Core functional requirements
FR-AUTH-XXX: Authentication related
FR-RPT-XXX: Reporting related
FR-INT-XXX: Integration related

非機能要件

NFR-PERF-XXX: Performance
NFR-SEC-XXX: Security
NFR-REL-XXX: Reliability
NFR-USA-XXX: Usability
NFR-MAINT-XXX: Maintainability

制約

CON-XXX: General constraints
CON-REG-XXX: Regulatory constraints
CON-TECH-XXX: Technical constraints

優先度レベル

MoSCoW メソッド

優先度	コード	説明
必須	M	成功に不可欠
望ましい	S	重要だが不可欠ではない
あればよい	C	あれば望ましい
対象外	W	今回のリリースの対象外

リスクに基づく優先度

優先度	レベル	説明
重大	P1	これがないとシステムが機能しない
高	P2	主要な機能に影響する
中	P3	軽微な機能に影響する
低	P4	拡張または利便性向上

ドキュメントの書式設定

セクション番号

1. Introduction
   1.1 Purpose
   1.2 Scope
2. Overall Description
   2.1 Product Perspective

要件テーブル

| ID | Description | Priority | Status | Source |
|----|-------------|----------|--------|--------|
| FR-001 | User login | M | Approved | Stakeholder Meeting 2024-01-15 |

相互参照

• ドキュメント内でハイパーリンクを使用します
• ID で参照します：「FR-001 を参照」
• トレーサビリティを記載します：「BR-003 を実装」

検証チェックリスト

SRS を完成させる前に、次の項目を確認してください。

• IEEE 830 テンプレートのすべてのセクションが完成している
• すべての要件に一意の識別子がある
• すべての要件が検証可能である
• 要件間に矛盾がない
• すべての用語が用語集で定義されている
• トレーサビリティマトリクスが完成している
• ステークホルダーの承認を得ている
• バージョン管理と変更履歴が含まれている

完全な SRS テンプレートについては、template.md を参照してください。 検証チェックリストについては、checklists.md を参照してください。