Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
545
Help us understand the problem. What is going on with this article?
@syantien

[Doc] 要件定義書テンプレート・要件定義書の書き方

毎度書いてるのでテンプレートをここに書き起こします、ご自由にご利用ください。

はじめに

誰が何をどのように求めているのか、これをまずは整理してみます。要件定義書=5W1Hを語るドキュメントです。下記をご参考までに。

5W1H なにをする 備考
Who 登場人物を整理 各登場人物と責任を明確化、判断する人いないプロジェクトは燃える。
What 何を作るのか整理 口頭は危険!顧客が本当に必要だったものを見て。
When いつまでにやるのかを整理 時間に限りがある場合は・・やれることも限られます
Where 範囲・スコープを整理 範囲決めないと、ここも後でもめます。本当に始めに決めないともめます。
Why そもそもどうして作るのかを整理 共通認識大切
How どうやって作るのかを整理 環境や、簡単なロジックやらやら

要件定義書

ドキュメントのバージョン管理

更新がある度に、何をどうして更新し、だれがその更新内容を承認したのか記載してください。

例)

バージョン 日付 変更内容 担当者
1.0.0 2021-07-12 ××の要件変更がされたため、○○部分追記ました。 鈴木

1. 概要

関係メンバー全員、誰が読んでもわかるように、今回開発するモノの概要をここに記載してください。

A. システム構成図

ここにシステムの構成図を、一目でシステムの構成がわかるといいです。データと業務のフローがカバーされているといいかも。

↓クラウドで構成組んでいる方には便利なリンク

AWS使っている方はこちらのアイコンを使えます。
https://aws.amazon.com/jp/architecture/icons/

Azure使っているかたはこちらのアイコン使えます
https://docs.microsoft.com/ja-jp/azure/architecture/icons/

B. 背景

なぜ開発することになったのかここに記載。お客さんも要求する事がミッション達成に寄与しない場合もありますので、ただ受けるよりもここで背景をちゃんと理解して正しアドバイスをしてあげられるといいですね。

C. 定義

これから使う専門用語はここで簡単に説明しておきましょう。最後でもいいかも?

2. 業務要件

A. 業務フロー

ここに業務フローを1Pでまとめてみます。フロー(流れ)が一目でわかるといい。業務を行う人たちをグループ化して、フローを書いてみる。

B. 規模

業務の規模をここに定義、どれぐらいの規模の業務を想定していますか?

C. 時期・時間

業務フローに関しての時期と時間をここに定義。時間軸大切、これを定義してください。

D. 指標

業務フローでの指標を定義。

E. 範囲

システムに関連する範囲をここで定義。システムに関係ないことは・・関係ないので。

3. 機能要件

A. 機能

ここに機能を大区分、中区分、小区分みたいにブレイクダウンしてください。開発案件によってここはだいぶボリュームあるかも。

B. 画面

細かいことは外部設計書に記載、もしくはここは外部設計書。

C. 情報・データ・ログ

データ項目、処理方法などを記載。どんなデータを保存するの?

D. 外部インタフェース

外部インターフェイスを定義して記載。入力される項目なども。

4. 非機能要件

A. ユーザビリティ及びアクセシビリティ

誰がどう使えればいいのか、ここに定義して記載。なんとなく・・つかいずらいみたいなを回避。

例)
3クリック以内に決済完了ページにたどり着く必要がある

B. システム方式

構成をここに定義。

C. 規模

想定規模をここに記載。

D. 性能

性能に関する事項+閾値をここに記載。

E. 信頼性

信頼性に関する事項をここに記載。

F. 拡張性

拡張性に関する事項をここに記載。

G. 上位互換性

バージョン対応などなどをここに記載。前のバージョンにどうやって対応するのか。

H. 継続性

冗長性などなどここに記載。

5. セキュリティー要件

A. 情報セキュリティ

必要とされるセキュリティーレベルをここに記載。

B. 稼働環境

環境に関してここに記載。要されるセキュリティーを見てから最適な環境を決めましょう。

C. テスト

テストに関してここに記載。テストは(も)お金がかかりますからね。下記を少なくても含んでください。

  • 実行するテストタイプに関して、機能テスト、ユーザビリティテスト、負荷テスト、セキュリティテスト
  • 担保する範囲とテスト範囲の定義(定義してテストが担保する範囲をカバーしていることを確認)
  • テスト環境、だれが行うのか
  • OKとNGの定義
  • 使用するツール
  • テストデータ、テストデータはどんなものか、どのように用意されるのか

6. 移行要件

A. 移行

移行のプロセス、タイミングなどをここに記載。

B. 引継ぎ

引継ぎ業務などをここに記載。

7. 運用要件

A. 教育

運用・利用・活用方法の教育など。

B. 運用

運用体制、運用業務をここに記載。

C. 保守

保守に関して記載。誰がどうやるのか。 保守に関するSLAはSLAの書き方を参照してください。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
545
Help us understand the problem. What is going on with this article?