1. 要件定義
【概要】
目的は以下２点。
・開発工数を見積る(最大の目的)。
・システムの利害関係者に対して、システムが必要とする機能や特性、品質を明確に定義すること
開発工数を見積れるレベルまで要件を定義できたら、終了してしまうことが多い。
この場合、要件定義の残りの外部仕様は設計で検討することになる。
ユースケース記述が完成してユースケース数から開発工数を見積もることができれば、そこで要件定義は終了してしまう。
要件定義フェーズではユーザ企業の業務知識を身に着けている必要がある。
1.1 機能要件
【概要】
・システムの利用者に対して具体的に提供される価値。システム利用者が何らかの目的を達成するために必要な機能を定義したもの。
例：ログイン、会員登録、注文入力、会員ポイント付与など
・代表的な記述形式には「ユーザーストーリー」や「ユースケース」が存在するが、業界標準は存在しない。
・ユーザーストーリー
としてができる。になるために。
→会員として、商品を購入できる。欲しい商品を手に入れるために。
→EC事業者として、商品を出荷できる。会員に商品を届けて売り上げを立てるために。
アジャイル開発で使われることが多く、あえて不完全な要求事項とすることにより、不完全さを補うためにコミュニケーションをプロダクトオーナーと開発者の間で活性化させる必要がある。
・ユースケース図
システムの利用者や外部システムに対するシステム自身の振る舞いを表現したもの。
ニーズを視覚的に表現する。
ビジネスルールを組み合わせて記述する。
正しく作業を分けられているかの判断軸はコーヒーブレイクができるかどうか。
・ユースケース記述
文章で記載する
記述すべき内容は4つ。「ユースケース名」「主アクター」「主シナリオ」「拡張シナリオ(例外シナリオ)」
ユースケース名…どんな機能か(大まかに)
主アクター…どんなユーザか
主シナリオ…主アクターとシステムが交互にどんな流れになるか。
拡張シナリオ…例外時の振る舞い
・概念モデル
システムの静的な構造を表す。
ユースケースを記述していると、様々な概念が登場する。会員、注文、配送、返品など。
これらの概念がどのような意味で、どうように関連しているのかはユースケースでは触れない。
ユースケースでは注文と表現しているものが、一体どのような属性をもち、商品とどのように関連しているかについては全く言及していない。これらの情報を概念モデルで明らかにする。
概念モデルで表現するものは３つ
「概念の名前」「概念の関連」「概念の関連の多重度（*）」
UMLのクラス図で記述する。
1.2 非機能要件
ユーザが機能を利用するときに補助的に必要なシステムの特性や性能のこと。
例：システムの性能、可用性、データ容量、運用保守、SLA/SLOなど
機能要件を補う特性がある。
機能要件と比べて軽視されがちだが、後で変更しようとするとシステム全体に影響が及ぶ。先行して検討すべき。
非機能要件定義の内容は負荷テストや運用テストのインプット情報になる
非機能要求グレード
IPAが定義する非機能要件の項目のこと。
数が膨大なので、開発するシステムに関係する項目を絞る必要がある。
SLI / SLO / SLA
〇SLI：サービスレベル指標
提供されるサービスについて、どの値を計測するか定義したもの
例：可用性、レイテンシ、スループットなど
〇SLO：サービスレベル目標
提供されるサービスについて、SLIとして定義した指標についての目標値。
例：可用性99.9%、レイテンシ20ms、スループット100kbps
〇SLA：サービスレベルアグリーメント
提供されるサービスについて提供側とユーザの間でSLOの値について契約を交わすこと。もしくはその同意書。
2. 基本設計
【目的】
・要件定義の内容をシステムでどのように実現するかを検討・記述すること(最重要)
・要件定義で明確になっていない外部仕様を検討する
・情報をドキュメントで明文化することで開発の関係者間で情報を共有する
・システムの品質を高める。要件定義工程で非機能要件が決まっていなければ、外部設計工程で検討する。
・メンテナンスのために設計情報を残す。保守工程では各機能が実装された目的を把握しないといけない。
【設計者が最優先で確認すべきこと】
・設計の入力になる要件定義の成果物はどのようなものか
→十分な要件定義の成果物が無ければ、それらを補う作業から進めるべき。
要件定義者に残りを検討してもらう or 設計者が残りを検討する。
・設計の期間と範囲はどこまでか
・設計の出力(設計書)はどのようなものか
【やること】
・システムの具体的な外部仕様(システムがユーザや外部システムに対して提供する機能やインターフェース)を設計する。
・システム全体の入力と出力を明確にすること
【外部設計の一覧】
・ユーザストーリー/ユースケース分析(機能要件とみなすこともある)
・概念モデリング(機能要件とみなすこともある)
・画面設計
・その他の外部設計(外部システムI/F設計、バッチ設計、帳票設計)
・データベース論理設計
2.1 画面設計
〇画面設計はシステム担当者が技術的な視点で設計するものであり、機能要件で定義された機能をシステムが提供できるように設計するもの。
〇ユーザビリティに関わるような話題はシステムとデザインの中間の領域にあたる。
ボタンをどこに配置するのかは、機能とデザインの両方の側面から考える必要がある。
〇画面設計で作成するものは以下。
・UI設計ポリシー
・画面遷移図
・画面一覧
・画面モックアップ
・画面入力チェック仕様書
UI設計ポリシー
個々の画面に統一感のあるユーザビリティを実現させるためのもの。以下の内容を検討する。
技術的な観点でなく、ユーザビリティやデザインの観点からの検討する必要がある。
・前提条件
→対応ブラウザ、ディスプレイ解像度、画面レイアウト幅、文字コード
・画面レイアウトパターン
→ヘッダー、フッター、メニュー、ボディなどの画面の共通レイアウトの設計
・画面機能パターン
→検索画面、一覧画面、登録・更新画面、削除画面などの機能に応じて画面レイアウトにおけるボディの構成と画面遷移をパターンとして検討する。ただし、SPAとしてWebサイトを構築することも増えており、ページ遷移をすることなく画面機能パターンを実現することもある。
・画面項目パターン
→画面に配置する項目の形式を検討する。表示項目と入力項目に分かれ、入力項目としては「電話番号を3つの入力項目とするか、1つの入力項目とするか」「都道府県をリストボックスで選択させるか、直接入力させるか」など、入力項目の画面上の形式について検討する。
画面遷移図
UI設計ポリシーの画面機能パターンとユースケース記述を使って作成する。シナリオを実現するにはどんな画面が必要で、それらの画面はどのように関連しているかを図で表現する。
画面モックアップ
画面遷移図を作成後に、個々の画面の具体的な画面イメージを作成する。
概念モデルと対応付けながら、過不足を確認する。
・画面項目を明らかにする
・画面項目の配置を明らかにする
・画面遷移を意識する
・実装前の画面イメージを作成する
入力チェック仕様書
・フォーマット
・デフォルト値
・必須 or 任意
・最小値
・最大値
・利用可能文字
2.2 その他外部設計
外部システムI/F設計
外部システムI/Fはネットワークやファイル交換などにより、外部システムとデータを交換する部分のこと。
・システム間で即時に直接通信を行う。結果も即返す。：同期(例 WebAPI)
・メッセージングサービスを経由して、メッセージを蓄積させることで遅延しつつも確実に通信する：非同期(例 Pub/Sub）
・データ量が大きく処理時間がかかるバッチ処理：ファイル連携
同期処理…相手の応答を待たないとメッセージのやり取りができない処理。電話
非同期処理…相手の応答を待たなくてもメッセージを送信できる処理。メール
注意
相手側のシステムが開発中であったり、I/Fが独自のプロトコルでだったりして明確に定義されていないことが多い。
その場合、こちら側のシステム開発にも影響が出る。そのため、できるだめ早く正確な仕様を入手し、疎通テストだけでも行っておくべき（いつから疎通テストが可能かを聞いておく）。
検討項目
・接続先
・プロトコル、手段
・接続タイミング
・インターフェース項目
・認証、セキュリティ
・例外処理
WebAPI
・Webサービスを開発するための、主にHTTPを使った外部システムI/Fの方式
・例：SOAP, REST, GraphQL
バッチ設計
・サーバプログラムのように常駐しておらず、ある時間が来て自動起動される or 手動で起動することによって実行されるプログラムのこと。サーバサイド言語でリアルタイムに処理を行わせるには時間や負荷がかかり過ぎてしまう場合、バッチプログラムとして夜間などの処理の負荷が低い時間帯に実行する。
・大規模なシステムでは多数のバッチプログラムを決まった順番と時間帯に実行する必要がある。その場合は、バッチを決まった順番と時間帯に応じて起動・実行するジョブスケジュール管理製品を導入することもある（例：Linuxのcron）
・検討項目 「実行タイミング」「実行制御・ジョブ制御」「トランザクション」「リカバリー」
・難しい観点はパフォーマンスと例外処理。
バッチ処理は決められた時間帯の中で大量のデータを処理しないといけないので、パフォーマンスを十分に考慮する必要がある。多くはデータベース処理やファイルを操作するか、非常に時間のかかる計算処理を行うかである。データベース処理はSQLの書き方次第でパフォーマンスが大きく変わる。ループの中でSQLを発行する際は注意。
ループが1万回、各ループでSQLが1万行あると、合計1億行のSQLを処理することになる。
場合によっては上限数を設計する必要がある。
トランザクションをどの範囲で区切るかの設計も重要。
一万件で一つのトランザクションとしてしまったら、最後の一件でエラーが起きたときに全てロールバックされてしまうため。
帳票設計
どのような出力方式にするのか
・WebからPDFでDL
・画像ファイルの生成
・プリンタで印刷
Javaなどの標準的なAPIでは提供されていないことが多い。
3. データベース論理設計
外部設計と並行してデータベース論理設計を行うことが一般的。
ER図で設計することが多い。書き方は「IDEF1 X表記」「IE表記」のどちらかを選択する。
ツールはdraw.ioなど。
作成済みの概念モデルを詳細化していく。
FKやPrimary Keyなどを踏まえて記載する。
NoSQL (Not only SQL)
・RDB以外のデータベースを指す。
・RDBは正規化された構造化データを格納するが、NoSQLでは半構造データや非構造データを格納する。
・ACIDの特性を簡略化している製品もある
・様々なタイプが存在するため、実現したい要件に合わせて製品を選択する必要がある。