基本情報技術者試験など情報処理技術者試験を受験する方にとっては必須の，ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計についてシンプルにまとめています。ソフトウェア要件定義（外部設計）では，ソフトウェア要件の確立（業務モデルの作成（DFD，状態遷移図，状態遷移表），画面・帳票設計（GUIの部品），ヒューマンインタフェース（アクセシビリティ，ユーザービリティ（使用性）），コード設計（コードに要求される機能（識別機能，分類機能，配列機能，チェック機能），主なコード体系（順番コード（連番コード，シーケンスコード），区分コード，けた別コード，表意コード（ニーモニックコード），コード設計の留意点），チェック方法（チェックディジット，フォーマットチェック，ニューメリックチェック，リミットチェック，レンジチェック，重複チェック，照合チェック，シーケンスチェック，論理チェック）），論理設計，ソフトウェア適格性要件），ソフトウェア要件の評価及びレビューを，ソフトウェア方式設計（内部設計）では，機能分割と階層構造化，物理データ設計，入出力詳細設計（画面設計，帳票設計），ソフトウェア結合テストのためのテスト要件の定義，ソフトウェア方式設計の評価及びレビューを，ソフトウェア詳細設計では，ソフトウェアコンポーネントの詳細設計，ソフトウェアインタフェースの詳細設計（モジュール分割（STS分割，TR（トランザクション）分割，共通機能分割，ジャクソン法，ワーニエ法），モジュールの独立性の評価（モジュール強度（機能的強度，情報的強度，連絡的強度，手順的強度，時間的強度，論理的強度，暗号的強度），モジュール結合度（データ結合，スタンプ結合，制御結合，外部結合，共通結合，内容結合））），ソフトウェアユニットテストのためのテスト要件の定義，ソフトウェア詳細設計及び要求事項の評価とレビューについて説明します。たくさんありますので，繰り返しじっくり読んでみてください。
このページの内容は，システム開発の全体像を理解した上で読んだ方が理解が深まると思いますので，先に次のページを読むことをお勧めします。
ソフトウェア要件定義（外部設計）
ソフトウェア要件定義では，システムを構成する各ソフトウェアに求められる機能などを定義します。
※ 外部設計…利用者の視点から設計を行うプロセス
ソフトウェア要件の確立
ソフトウェア要件の確立では，業務モデルや論理モデルなどを作成して，ソフトウェアに求められる機能，能力，インタフェースなどを決定します。
業務モデルの作成
業務モデルの作成には，DFDや状態遷移図などが用いられます。
DFD（Data Flow Diagram）
DFDは，（プロセスを中心に）データの流れ（入力→処理→記憶→出力）に着目して，業務データの流れと処理の関係を図で表します。
※ システムと利用者（または，他のシステムなど）のデータの流れを図にしたり，システム内の構成要素間のデータの流れを図にしたりする
※ 現物理モデル→現論理モデル→新論理モデル→新物理モデルの順に作成する
※ 全体的なレベルから段階的に詳細化していくという手法を用いることが多い
 | プロセス | データの加工などを表す |
 | 源泉と吸収 | データの発生源，または，データの行き先を表す |
 | データフロー | データの流れを表す。名前を付ける |
 | データストア | データが一時的に保管される場所を表す |
状態遷移図
状態遷移図は，条件やイベントにより状態が変わるようなシステムの動作を図で表します。
※ 参考「情報に関する理論－オートマトン －情報処理シンプルまとめ」
 | 状態 | 非受理状態 |
 | 状態 | 受理（終了）状態 ※受理状態は2つ以上あってもよいし，なくてもよい |
 | 遷移 | 状態から状態への変化を表す。「入力/出力＋α」を付ける ※出力がない場合は「＊」を付ける |
 | 初期状態 | 初期状態 |
状態遷移表
状態遷移表は，条件やイベントにより状態が変わるようなシステムの動作を表で表します。
※ 状態遷移図から状態遷移表を作成できる（逆も可能）
画面・帳票設計
画面・帳票設計では，ユーザービリティ（使用性）を考慮したヒューマンインタフェースを設計します。
GUIの部品
GUIの部品には，次のようなものがあります。
※ GUI…Graphical User Interface。画面にアイコンなどを表示して情報を提示し，それをマウスなどで操作するユーザーインタフェース
※ CUI…Character-based User Interface。画面の表示や操作を文字だけで行うユーザーインタフェース
| ラベル | テキストを表示する部品 |
| プッシュボタン | 何らかの処理を引き受けるための部品 |
| エディットボックス | テキストを入力・表示する部品。複数行入力に設定することも可能 |
| グループボックス | ラベル付きの枠を表示する部品。グループ分けのために使用する |
| チェックボックス | オン／オフを選択するための部品 |
| ラジオボタン | 複数の部品の中で，どれか1つだけを選択するための部品 |
| リストボックス | いくつかの項目を表示し，その中から1つ（または複数）を選択するための部品 |
| コンボボックス | ドロップダウン形式のリストボックスで，項目を1つだけ選択するための部品。ボックス内に直接入力するように設定することも可能 |
| スクロールバー | 表示内容をスクロールするための部品 |
| トラックバー | （指定した範囲の）数値を選択し，設定するための部品 |
| プログレスバー | 処理の進捗状況を表示する部品 |
ヒューマンインタフェース
システムを利用しやすくするために，ヒューマンインタフェースに関する要件も定義します。
アクセシビリティ
アクセシビリティとは，システムやソフトウェアなどを障がい者や高齢者などが利用する場合に，どの程度支障なく利用できるかという度合いのことをいいます。
マウス操作が難しい場合 ⇒ 音声認識などで操作できるようにする
など
ユーザービリティ（使用性）
ユーザービリティとは，システムやソフトウェアなどの使いやすさのことをいいます。
※ 利用者が，戸惑うことなく使用できること
コード設計
コード設計では，入出力データとして使用するコードを適切に設計します。
コードに要求される機能
| 識別機能 | データを区別する機能 例）同音異字の識別 101 麻友美 102 真由美 |
| 分類機能 | データを分類する機能 例）科目の識別（数学はM，英語はE） M01 数学Ⅰ M02 数学Ⅱ E01 英語Ⅰ |
| 配列機能 | データの並びを決める機能 例）年月順 Jくん 19630217（1963年2月17日） Pくん 19650925（1965年9月25日） |
| チェック機能 | 入力されたデータが正しいかをチェックする機能 |
主なコード体系
順番コード（連番コード，シーケンスコード）
順番コードは，データを一定の順に並べて番号を割り当てる方式です。
例）学生番号
101 Aくん
102 Bくん
区分コード
区分コードは，データを幾つかのグループに分割して番号を与え，その中で順に番号を割り当てる方式です。
例）装備（剣は10番台，盾は20番台…）
11 木の剣
12 鉄の剣
21 木の盾
けた別コード
けた別コードは，データを大分類・中分類・小分類などに分け，それぞれの分類の中で順に番号を割り当てる方式です。
例）クラス分け（大分類：一般にはG，学生にはS，中分類：初級クラスには1，中級クラスには2，小分類：登録順（2桁））
G101 Aくん （一般初級クラス）
G102 Bくん （一般初級クラス）
S201 Cさん （学生中級クラス）
表意コード（ニーモニックコード）
表意コードは，コード化するデータの名称や略称，記号などをコードとし，その中で順に番号を割り当てる方式です。
例）テレビ
LTV32 32型液晶テレビ
LTV40 40型液晶テレビ
OTV40 40型有機ELテレビ
コード設計の留意点
- コードは標準化，拡張性，運用性を考えて設計する（システムの内部に合わせて設計しない）
- コードの利用期間を考えて設計する（保守方法も考慮する）
- コードの付番は，実際の利用者が担当する
- コードの入力ミスを防ぎたい場合は，検査文字（チェックディジットなど）を付加する
チェック方法
チェックディジット
チェックディジットは，検査対象のコード（基本コード）と，そのコードから算出したチェック用のコード（チェックディジット）を用いて，誤りを検出する方法です。
例）商品コードのチェックディジットを求める
その他のチェック方法
| フォーマットチェック | データが指定されたフォーマット形式に沿っているかを検査する 例）09-0123456-56（電話番号？） |
| ニューメリックチェック | データに数字以外が入っていないかを検査する |
| リミットチェック | データの値が指定された上限値より小さいか，または，指定された下限値より大きいかを検査する |
| レンジチェック | データの値が指定された範囲内であるかを検査する |
| 重複チェック | データが重複していないかを検査する |
| 照合チェック | 入力されたデータが，ファイルに存在するかを検査する |
| シーケンスチェック | キー項目として定義した項目の並び順や，抜けを検査する |
| 論理チェック | データの内容が論理的に正しいかを検査する 例）13月32日（不適切な日付） |
論理設計
論理設計では，画面・帳票設計やコード設計を基に，使用するデータを，ファイルやデータベースにする方法を決定します。
※ 詳細は，「関係モデル（論理設計） －情報処理シンプルまとめ」を参照
ソフトウェア適格性要件
ソフトウェア適格性要件も作成します。
ソフトウェア要件の評価及びレビュー
ソフトウェア要件の評価及びレビューでは，ソフトウェア要件が，システム要件やシステム方式を満たしていることを評価し，ソフトウェア要件定義書について（システムの取得者と供給者で）レビューを行います。
※ レビューの詳細は，「レビュー －情報処理シンプルまとめ」を参照
ソフトウェア方式設計（内部設計）
ソフトウェア方式設計では，ソフトウェア要件を実現するために，ソフトウェアをプログラム（ソフトウェアコンポーネント）に分割し，各プログラムに必要な機能やプログラム間の関係などを明確にします。
※ 内部設計…開発者の視点から設計を行うプロセス
機能分割と階層構造化
機能分割
機能分割では，ソフトウェア要件定義で作成したDFDなどを基に，各機能を詳細な機能（プログラム）に分割します。
階層構造化
階層構造化では，分割した各機能（プログラム）を階層構造にします。また，各機能（プログラム）間の入出力インタフェースも決定します。
※ 同系列の機能をまとめながら階層構造化する
また，プログラムの実行順序をプロセスフロー（流れ図など）で明らかにします。
物理データ設計
物理データ設計では，論理設計で決定した論理データについて，より具体的な方法を決定します。
- データ量や，データの追加・更新・削除の度合い，オンライン処理かバッチ処理かなどを分析し明確にする
- 処理形態や，処理速度，ファイルの特性などからファイル編成を決定する
- 格納媒体（磁気ディスクや，磁気テープ，光ディスクなど）を決定する
- レコード内のデータ項目の属性（文字，数字など）や，文字数・桁数などを決定する
※ 拡張性も考慮する
※ 参考「データベース管理システム（DBMS）（物理設計） －情報処理シンプルまとめ」
入出力詳細設計
入出力詳細設計では，画面・帳票設計で設計した内容から，より具体的な設計を行います。
画面設計
入出力に使用する画面イメージを設計する（メニュー項目や，入力可否，色，表示するメッセージなど）
帳票設計
出力する帳票類を設計する（用紙サイズや，文字の大きさ，各項目の配置など）
ソフトウェア結合テストのためのテスト要件の定義
ソフトウェア結合テストのためのテスト要件の定義では，ソフトウェア要件をすべて満たしているかを確認するために，テスト範囲やテスト計画，テスト方法を定義します。
ソフトウェア方式設計の評価及びレビュー
ソフトウェア方式設計の評価及びレビューでは，ソフトウェア設計がソフトウェア要件を満たしていることを評価し，ソフトウェア方式設計書についてレビューを行います。
※ レビューの詳細は，「レビュー －情報処理シンプルまとめ」を参照
ソフトウェア詳細設計
ソフトウェア詳細設計では，各プログラム（ソフトウェアコンポーネント）をモジュール（ソフトウェアユニット）にまで分割して，より詳細化します。
※ 作成したモジュールは，部品化することで再利用できるようになる
ソフトウェアコンポーネントの詳細設計，ソフトウェアインタフェースの詳細設計
ソフトウェアコンポーネントの詳細設計，ソフトウェアインタフェースの詳細設計では，各プログラムをモジュール（ソフトウェアユニット）のレベルにまで詳細化し，モジュール間のインタフェースなどを設計します。
モジュール分割
モジュールを分割する技法については，次のようなものがあります。
データの流れに着目した方法
STS分割
STS分割は，プログラムを入力処理機能（源泉；Source），変換処理機能（変換；Transform），出力処理機能（吸収；Sink）の3つのモジュールに分割する技法です。
TR（トランザクション）分割
TR分割は，データの種類によって（トランザクション）処理が複数に分かれる場合に適した技法です。
共通機能分割
共通機能分割は，プログラム中で共通して行われる機能をモジュールとして分割する技法です。
※ エラー処理などがある
データの構造に着目した方法
ジャクソン法
ジャクソン法は，入力データと出力データの構造からプログラムの構造は決まるという考えのもとに，主に，出力データの構造からプログラム構造を作成する技法です。
ワーニエ法
ワーニエ法は，入力データの構造を基にプログラム構造を作成する技法です。
モジュールの独立性の評価
分割後のモジュールは，独立性が高い方が良いとされています。
※ モジュールの独立性が高いと，他への影響が少ないため保守性が上がる。また，別のソフトウェアでも利用しやすくなるので再利用性も上がる
モジュール強度
モジュール強度とは，モジュール間の結び付きの強さを表すもので，モジュール強度が高いほど独立性が高いモジュールとなります。
モジュール結合度
モジュール結合度とは，モジュール間の関係性の強さを表すもので，モジュール結合度が低いほど独立性が高いモジュールとなります。
ソフトウェアユニットテストのためのテスト要件の定義
ソフトウェアユニットテストのためのテスト要件の定義では，ソフトウェア詳細設計の要件をすべて満たしているかを確認するために，テスト範囲とテスト計画，テスト方式を定義します。
ソフトウェア詳細設計及び要求事項の評価とレビュー
ソフトウェア詳細設計及び要求事項の評価とレビューでは，ソフトウェア詳細設計を評価し，ソフトウェア詳細設計書についてレビューを行います。
※ レビューの詳細は，「レビュー －情報処理シンプルまとめ」を参照
まとめ
今回は，ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計ついて，シンプルにまとめてみました。内容がたくさんあり1回で完璧に理解し覚えるのは難しいと思いますので，また，いつか読みに来てください。基本情報技術者試験や応用情報技術者試験で問われるところですので避けてはとおれません…。根気よく頑張りましょう。
