📝

【本の要約: 後編】はじめよう！要件定義〜ビギナーからベテランまで〜

2024/02/24に公開

本

要件定義

要約

idea

はじめに

こちらの後編の記事です。

内容的には要件定義の詳細部分の説明になります。

Chapter-13[離陸編] UI を考えよう

この章では、UI の要件を定義する詳細な方法を説明しています。

UI を定義するということ

UI を構成する要素は以下のものがあります。

データ項目
操作項目
レイアウト
順番に手順を見ていきます。

対象となる UI をピックアップする

行動シナリオの中に現れたソフトウェアの UI を一つ選びます。

ラフなイメージを描いてみよう

ペーパープロトタイピング、モックアップ、ワイヤーフレームなどといった手法があります。
実際の操作感などを想定しながら画面のイメージを共有できるようにします。

必要な項目を列挙しよう

UI を構成する要素のうちの2つ「データ項目」「操作項目」をここで拾い出していきます。
写真などの画像、ロゴ、バナーなど目に見えるものはできるだけ項目として列挙することをおすすめしています。

動線を考えよう

ラフのイメージを描きながら、画面ごとの項目の割振りと、画面遷移について整理していきます。

操作と機能を織り込む

画面遷移図に、ユーザーの操作によって発生するイベントトリガーと、それによって実行される機能を織り込んでいきます。
機能の掘り下げは、これ以降で行います。

同一画面に戻る遷移や、初期処理、終了処理の考慮もここで漏らさずやっていきます。
同一画面に戻る遷移

初期処理の例

終了処理の例

ディテールを詰める

ラフイメージと照らし合わせながら画面遷移図にイベントトリガーや処理を含めて詳細を詰めていくと、
項目の漏れや定義の曖昧さに気づいていきます。

画面分割や、それに伴い生じる遷移図へのイベントトリガーの追加などをして詳細を詰めていきます。
このように、UI　を考える作業は1度に決めきるよりも、試行錯誤しながら進めていくことになります。

導出項目について

導出項目とは、「別の項目をもとに一定のルールに従って導き出される値に対しての認識」です。
税額＝金額×税率
というルールで税額が導き出せるとします。

ここで「税率」という項目は、ルール上現れるにも関わらず、 UI 上に全く現れない可能性があります（データベースに保存しているなどの理由で）。

「税率」という項目はルール上必要にも関わらず、その存在が認識されなくなってしまいます。
導出項目については、導出ルールに現れる項目を明記するようにしておくと、後工程で困ることがなくなります。

UI としてのエラーメッセージ

エラーメッセージを返すときは次の項目を必ず用意指定ください。

現象
原因
対処方法

例えば電話番号の場合、以下のようになります。

電話番号の入力が不正です ...現象
許可されない文字が入力されました ... 原因
数字（1~9）またはハイフン(-)のみを使って再入力してください ... 対処方法

何が起こったのか、なぜそうなったのか、自分が何をすればいいのか納得できる情報を提供します。

また、再入力させず、プログラムで自動補完できないかという考えもありです。
そうすることで実装の手間は増えても、ユーザフレンドリで、ゴールに近づくソフトウェアになるのは間違いないからです。

デコレーション

ここまで来たら、デザイナーと連携、協業して、ビジュアルデザインについて詰めていきます。

UI について考えた結果をまとめよう

ここまでで、次の成果が出来上がります。

ラフイメージまたはモックアップ
画面遷移図
項目の説明

一般的な UI デザインだけだと、プログラマ側からすれば実装のための情報が足りないとなりがちですが、
これらがあれば、かなり問題は解消するはずです。

Chapter-14[離陸編] 機能について考えよう

この章では、機能の要件を定義する詳細な方法を説明しています。

機能とはなにか

機能とは関数とも呼ばれ、
y=f(x)
で表されます。

x が入力、y が出力、f が処理と捉えることができ、これらを定義していきます。

出力を決める

画面遷移図のその機能の先につながっている画面の項目から、「出力」するものを決めます。
出力を決めたら、その出力を作るための材料として、遷移元の画面から「入力」を決めます。

「この入力を与えればこの出力が得られる」となるので、プログラミング的な意味だと
「Interface を定義する」ということになります。

また、画面以外のところから必要な入力を調達する場面が出てきますので、
このタイミングで、画面遷移図にその調達元も描いておきます。

処理を考える

処理については、入れ子構造をか考えていきます。
消費税の計算の場合は以下のような感じです。

消費税を計算する
- 消費税額を計算する
  - 消費税額を計算する
    - 金額を入手する
    - 税率を入手する
      　　- 税率をデータベースから取得する
    - 消費税額 = 金額×税率を計算する
- 消費税額を出力する

ここではプログラミングスキルがあったとしても、差し支えがない限り、類似コードなどは書かない方が良いです。

この時点で大事なのは、「どんな処理をすれば役割を達成できるのか」ということを考えることを優先させることで、プログラミングをすることではありません。

Chapter-15[離陸編] データについて考えよう

この章では、データの要件を定義する詳細な方法を説明しています。

データベースの設計の方法

データベースの設計方法に関しては、具体的な方法が存在します。
RDBMS(リレーショナルデータベース)を前提としており、ここの作業の成果としては、ER 図と呼ばれるデータベース設計の図面が出来上がります。

画面遷移図から、エンティティと項目を見出し、リレーションシップを定義します。

Chapter-16[離陸編] 要件定義の仕上げ

この章では、今まで作成してきた成果物を見直し、精度を上げるといった趣旨の説明をしています。

足りないワークセットを検証しよう

この時点で、「あるはずものがない」ということを検知するために、データベースを利用して検証します。
ここで、 CRUD マトリックスという表を作ります。

このワークセットは
このエンティティを
C/R/U/Dします
という一覧を作ります。

ここで言うワークセットとは、ユーザーの1つの仕事に対応するソフトウェア側のスコープの単位のことを指します。
このマトリックスを使って、R/U/D が存在するのにもかかわらず、Cが存在しないものを探します。

参照や更新をしようとしてもその対象が見つからないことになってしまいます。

これらの　C が存在しないエンティティに対して、生成を行うワークセットを追加します。

そして、追加したワークセットを利用する行動シナリオをさらに追加します。
このあたりは、マスタメンテナンス系と呼ばれるところに多く発生します。

消費税を計算するというワークセットにおいて、税率が必要となります。
ただし、税率は勝手にデータベースに入ってくるわけではないので、
「税率を登録する」というワークセットが必要になります。

Chapter-17 要件定義、その後に

この章では、作成した成果物を、どのように他の人に伝えるかという説明をしています。
ここまでで、以下の青果物が揃っています。

企画書
全体像
実装技術
実現したいこと一覧
行動シナリオ
概念データモデル
ラフイメージまたはモックアップ
画面遷移図
項目の説明
機能の入出力定義
機能の処理定義
結合 ERD

一覧を作ろう

これらの資料をただ次の工程に渡すだけではなく、他人に理解してもらえるようにする必要があります。
そのために、これまでの成果物の目次化を行います。
具体的には以下のものを作成します。

行動シナリオ一覧
ワークセット一覧
上記のものを作成した後、今までの青果物を以下の順番で並べます。
この順で並べることで、受け手が「全体から詳細へ」「Why から What へ」「What から How へ」
と徐々に理解してく事ができます。

企画書
全体像
実装技術
実現したいこと一覧
行動シナリオ一覧
行動シナリオ
ワークセット一覧
概念データモデル
ラフイメージまたはモックアップ
画面遷移図
項目の説明
機能の入出力定義
機能の処理定義
結合 ERD

成果をリリースしよう

これまでの作業で作成したものを、関係各位に伝えるための段取りを行って、
「説明」という形でリリースしましょう。