要件定義

開発するシステムに求められている機能などの要件をまとめる事。
例えば

「パスワード認証」「データベース内検索」などの機能要件
「入力データ」「出力データ」の仕様
「保守性」「操作性」などの非機能要件
業務フロー

などが挙げられる。
RFP(提案依頼書)作成や事前調査などを行って、本当に必要な要件をじっくりと精査していく。
ココでまとめた内容を元に開発が進められる為、洗礼された要件定義を行うことで見落としによる仕様変更の回数を減らす事が出来る。
要件定義時に扱うのは必ず保証しなければならない項目が中心であり、UIデザインなどのデベロッパー側が決めても構わない部分は、後述の外部定義で行う。

要件定義書

要件定義の結果を文書にしたモノを要件定義書と呼ぶ。
参考 : http://www.atmarkit.co.jp/ait/articles/0911/19/news109.html

最低限明記しておいた方が良さそうな項目は以下の５つ。

システム概要
- 何をするシステムなのか
- どうしてそのシステムが必要なのか
- そのシステムの目標は何なのか
システムの構成図
- システム概念図
- システムの業務フロー
- ユースケース図
機能要件
- システムの機能一覧
- 各機能の詳細
入出力要件
- 入力データ一覧
- 各入力データの詳細(データ項目・ファイル形式など)
- 出力データ一覧
- 各出力データの詳細(入力データと同様)
非機能要件
- セキュリティ要求
- 品質・性能要求
その他
- 概略スケジュール
- ステークホルダー相関図（関係図）

外部設計

(クライアントからの要件がほぼ出揃った後に、)
要件定義書に従ってシステムの構成を具体的に設計していく事。
クライアント側にも共有する前提の「要件定義書」とは異なり、「基本設計書」(=外部設計書)はデベロッパーの視点に立って記述していく。ただし基本仕様書をレビューにはクライアントも参加する(らしい)。

「外部設計」は主に以下の３つに分類される。

方式設計

別名「アーキテクチャ設計」。
「何を使って」「どのような工程で」「どのようなシステムを」製作するのか？を順番に設計していくイメージ。

何を使って
- 開発方針を定めていく。具体的にはハードウェア・ソフトウェア構成など
- 大規模開発の場合、使用言語やプラットフォームは指定するのが望ましい
どのような工程で
- 開発体制
- 開発スケジュール
- プロジェクト管理ツール
どのようなシステムを
- システム構成図

機能設計

システムをモジュール単位に分割し、各モジュールの外部仕様を設計する。UML図が活躍する事が多いフェーズ。
各モジュールの詳細設計は、後述の「内部設計」で行う。

画面遷移図
画面レイアウト(UI)設計図
シナリオ
ビジネス・ロジック
機能一覧表
データベース設計
- ER図
- テーブル定義書

その他設計

この他にも「セキュリティ設計」「運用設計」「テスト設計」などを行う。

基本設計書

外部設計で決定した事をまとめて文章化したモノを基本設計書と呼ぶ。

システム概要
- シナリオ
- ビジネス・ロジック
システムの構成
- システム構成図
- 業務フロー・アクティビティ図
- ハードウェア・ソフトウェア構成図
- ネットワーク構成図
機能一覧表
データベース仕様
- ER図
- テーブル定義書
UI設計
- 画面遷移図
- 画面レイアウト設計図
その他
- 開発体制
- 開発スケジュール
- プロジェクト管理ツール

内部設計

外部設計では「システム全体の構成」「開発方針の決定」をメインに設計していましたが、
内部設計では「どのようなモジュールを実装してシステムを構成するか」の一点に注目して設計していきます。
各モジュールの構造・データフローが主な記述事項です。
外部設計ではレビュワーにクライアントが含まれていましたが、内部設計にはSE・PGだけが携わります。PGのみを対象にした資料だと考えて問題ありません。
実は、そもそも内部設計書無しでコーディングを始めてしまった方が効率が良い！と考えている人も少なくないようです。

内部設計書

「詳細設計書」とも呼ばれるようです。
内部設計書は資料として１枚にまとめるのではなく、各モジュールの仕様書として１枚ずつ作成される場合が多いみたいです。

機能分割説明
- クラス図
データフロー
- DFD図
モジュール詳細
- モジュール名
- 役割
- 引数・戻り値
- 処理概要
- 備考

実装開始

内部設計が終わった後に、ようやくPGによるプログラミングが開始されます。
実装が完了した後は、外部設計で作成した「テスト仕様書」に従って、単体テスト→結合テストを行っていきます。

あとがき

調べてみるまで全く知りませんでしたが、上流工程って作らなければならない仕様書・図が多いんですね。
また、仕様書の書き方も会社によって異なる事が多く、デファクトスタンダードになってるサンプルが見つからなかったので苦労しました。
SEとして働き始める人は、その会社の流儀を覚える事から始める必要がありますね。

この記事はシステム開発未経験者が短時間で調べた内容をまとめただけですので、工程の抜け・間違いがあるかもしれません。あくまで参考資料として、ご了承ください。

#参考
https://hnavi.co.jp/knowledge/blog/external_design/
http://www.atmarkit.co.jp/ait/articles/0907/31/news103_2.html
https://qiita.com/mikakane/items/b8045a11dba8d08e5fe4
https://www.widesoft.co.jp/technology/3536