投稿元:
レビューを見る
要件定義について分かりやすく説明されている。
要件定義時点で決めなければならない項目が多いことと、実際の仕事上ではそこまで決めていないを再認識させられた
UIが最重要、とのことであったが
組み込みシステムや複数機器の組み合わせシステムなど
人か介在しない(介在が限りなく少ない)システムの場合、
どのように読み替えてよいのかが分からなかった。
投稿元:
レビューを見る
要件とは、依頼した人ができあがったものに対して「これならOKです」と言うために、「何がどうなればよいのか」ということを明確に定めたもの
要件として何を定めればよいのか。「ゴールから逆算する」
・UI
・機能
・データ
要件を決めるには大雑把には上記の流れになる
要件定義のために要件定義をするのではない
後工程につなぐための要件定義
要件定義は決して簡単でも楽でもない
急がば回れ
[準備編]
1.企画を確認する
企画書を確認できない=ゴールの定義が不明瞭
ない場合はひと目で理解を共有できる企画書を作る必要がある
?プロジェクトの名称
?なぜ
・目的
?何を
・目的達成のためにつくるもの
・作るものの説明
・作るものを利用する人
・利用する人が得られる便益
?どのように
・作るための体制
・期限
サンプルあり、別紙参照あり
2.全体像を描こう
企画の中の特に「何を」の部分をビジュアルに表現したもの、コンテキスト図と呼ばれる場合も
大枠の理解を共有することを主眼とする
実現しようとしているソフトウェアを紹介するパンフレットを作る感じ
描く手順
ソフトウェアを中心に置く
利用者を配置する
利用者が行うことを書く
システム管理者を書く
連携するシステムを書く
連携する内容を書く
移行対象データとしておくだけでもかまわない
誤解を招かない程度に魅力的にお化粧する、UIイメージ図などを加えるなど
これが要件定義の対象範囲
3.大まかに区分けする
サブブロック図を作成する、大規模な場合
これが非常に難しい、経験、実力、センスに左右される
サンプルあり
4.実装技術を決める
ソフトウェアアーキテクチャの決定
第1段階、基本的なシステムアーキテクチャを決める
・メインフレーム
・2層クライアントサーバ型
・Webブラウザ型
・モバイル端末+Webサーバ型
オンプレミスかクラウドか
第2段階
図あり
[クライアント側]
・ユーザアクションの検知方法は?マウス?タッチ?音声入力?
・入力や受信したデータの保持の仕方は?
・データと画面上の項目との連携方法は?
・画面遷移はどのように行うの?
・クライアント側のプログラミング言語は何?
[通信]
・通信プロトコルは何?
・通信データのフォーマットは?
[サーバ側]
・データ変換の方法は?
・使用するデータベースは何?
・どうやってデータベースを操作するの?
・サーバ側のプログラミング言語は何?
・フレームワークは使うの?
5.実現したいことを整理整頓
やりたいことを洗い出す
やりたいことを一覧にする
[助走編]
1.利用者の行動シナリオを書こう
行動シナリオの別名、ビジネスプロセスフロー、プロセスマップ、業務フロー、ユーザシナリオ、ユースケース、ユーザストーリー
行動シナリオから得るもの
・ソフトウェアを利用するタイミング
・ソフトウェアを利用する理由
・ソフトウェアを利用することで利用者が具体的に達成する仕事
要件定義の前に行動シナリオを書くこと
利用者が行う行動の単位を「仕事」とする
仕事とは、何らかの成果と、その成果を出すために行う活動のまとまり
仕事の本質は変換
成果を出すための3要素
「材料」「道具」「手順」
変換には「状態の変更」というものもある、「検査する」という仕事はその典型
仕事を行うタイミングは大きく2つ
「他からのリクエストがあったとき」
「ある条件を満たしたことを検知したとき」
「材料」「道具」「手順」「条件」が揃うと仕事を行うことができる
仕事は1つで完結するわけでなく、仕事の連鎖が生じる。この連鎖を業務フローや工程や段取り、プロセスや、プロトコルやプロシージャと呼ぶ
仕事の連鎖で発生するのが、「受け渡し」「保管」「ピックアップ」。要件定義にはさほど重要ではないが、業務設計には非常に重要
スイムレーン(図)あり
仕事の入れ子はサブルーチンや別メソッドに処理を分けるのと同じ。物事を箇条書きで整理する練習がおすすめ
ITの本質は「中抜きの実現」
行動シナリオをどう書くか
重要なのはUIの出現場所
行動シナリオのサンプルあり
サンプルのフロー図は仕事同士を繋ぐ線を、排除している、IT素人には見やすいと好評
2.概念データモデルを作る
本来的には不要、要件定義を行う担当者が従来のシステム開発に染まりきっている場合のための対策
概念データモデルの作り方
ドラム缶型のパターン、もしくはERD型で、行動シナリオの名詞、動詞を抽出し、〇〇データとする
要件定義でがっつりやるので、ほどほどに
[離陸編]
1.UIを考えよう
要件定義の中でもUIが最も重要
利用者が判断できるほぼ唯一の箇所
UIを構成する要素
・データ項目
・操作項目
・レイアウト
手順
・行動シナリオの中に現れた「ソフトウェアくん」のUIを1つ選ぶ
1つの仕事のために複数のUIが出てくる
この単位を「ワークセット」とする
ワークセットの概念を確認、「何をどうする」の形式で記述、これが責任範囲(スコープ)の定義になる
・ラフなイメージを描く、ペーパープロトタイピングや、モックアップ、ワイヤーフレーム
・必要な項目をラフから列挙、データ項目と操作項目、ここから画面遷移図を作成(サンプルあり)
・動線を考える
(サンプルあり)
レイアウトも記録していく
・操作と機能を織り込む
(サンプルあり)
イベントトリガーと機能を書く、機能は手掛かりがきちんとと明記されていれば良い、同一画面に戻る遷移も端折らず記載
開始と終了や初期処理も明記する
(サンプルあり)
ワークセット間の遷移とかメニュー体系とかはどちらの受け持ちかは悩ましいが、終了処理と初期処理とに明確に分離できるものは分けて書こう
(サンプルあり)
・ディテールを詰める
ワークセット単位で
要件定義で、項目を全部決め���
スワイプや、非操作系のイベントトリガーも記載
(サンプルあり)
・項目の名称
「エイリアス」「シノニム」「ホモニム」を出来るだけ排除する、出来ない場合は必ずメモして後工程に伝達
・導出項目
別の項目をもとに一定のルールに従って導き出される値に対しての認識の定義
例:税額=金額×税率
導出ルールに現れる項目をきちんと明記する
・UIとしてのエラーメッセージ
・現象
・原因
・対処方法
・デコレーション
配置、カラーリング、タイポグラフィ、グラフィックなどをラフイメージに反映
エフェクトやアニメーションも明記しておく、詳細は要らない
共通化は後回しに
・UIについて考えた結果をまとめる
1つのワークセットに対して次の成果が出来上がる
・ラフイメージまたはモックアップ
・画面遷移図
・項目の説明
2.機能について考える
・機能とは何か
機能とは仕事である
ここからは「仕事のモジュール化」であり、サブルーチン設計、構造化手法の基本的知識が必要
・段階的詳細化
・凝集度
・結合度
・ワークセットの機能をピックアップする
画面遷移図から機能をピックアップ
・出力を決める
成果=出力と考える (遷移先から)
出力するための材料=入力 (遷移前から)
これがinterfaceを定義するということ
入力が足りない場合は調達する
どこから調達するのか、たいていはデータベース、画面遷移図にドラム缶を追加する
・処理を考える
入れ子構造を考える
ツリー構造でもある、大見出し、中見出し、小見出し
プログラムはここでは書かない、あくまでコンピュータにらやせる仕事として記載
・機能を分割する
(サンプルあり)
入れ子が深くなれば別機能として切り出す、ただし画面遷移図にあわられている機能を、トップノードとして、それ以下は1つのセットでまとめる
・ストア系の機能
マスタ処理なども画面遷移図として記載する
・機能について考えた結果をまとめる
ワークセット全てに行うと
・ラフイメージまたはモックアップ
・画面遷移図
・項目の説明
・機能の入出力定義
・機能の処理定義
3.データについて考える
・データベースとは何か
超グローバル変数
・データベース設計の方法
「楽々ERDレッスン」参照
手順1.ワークセット単位で設計する
手順2.1.の成果を1つに統合する
・ワークセット単位で設計する
画面遷移図等に書かれているデータベースの項目を全部書き出す
項目の区分け=正規化
区分けの方法はまずは器(エンティティ)を用意、器を見いだすには、名詞・動詞法を使う、一般にはイベント系・リソース系という
イベント系
ワークセットの仕事を表現するもの、「〜する」という言い方ができる、つまり動詞にすることができる。
もう一つの特徴はタイムスタンプを入れられる
リソース系
名詞で表現できるもの
繰り返し項目のグループを切り出して、いわゆる見出し明細形式にする、第一正規化
エンティティ間の参照関係を定義する
これで一つのワークセットに対応するERDができる、ワークセット分のERDが出来たら一つのERDに統合する、同じ名前のエンティティを1つにまとめていく
・データについて考えた結果をまとめる
・ラフイメージまたはモックアップ
・画面遷移図
・項目の説明
・機能の入出力定義
・機能の処理定義
・統合ERD
4.要件定義の仕上げ
・足りないワークセットを検証する
データベースを利用して検証
・CRUDマトリックスを作る
ワークセットとエンティティでマトリックスをつくる
検証は「C」がないものを探す
ないものがあれば、ワークセットを追加する、そのワークセットを利用する行動シナリオをさらに追加
マスター系によく発生する
・精度を高める
どんどん足りないワークセットが出てくるので都度ワークセットを追加していく
・仕上げる
ここまでくれば、要件定義はほぼ完了。あとは必要に応じて、応答性や可用性などの非機能要件(いわゆるビリティ系)を定義
権限管理は要件定義の工程の中で行うべき、基本的には権限ごとにワークセットを分ける、見ることができる項目が違うという場合は、ワークセットを分ける、ワークセットが分かれるということはそもそもの行動シナリオが異なるはず、それでも同一ワークセットで権限別の制御を行う必要が生じることもあるときはワークセットに必ず「権限制御をする」という機能をUIごとに置く、処理内容にはパーミッション表を用意する(サンプルあり)
[要件定義、その後に]
ここまてで、以下のものが揃っているはず
・企画書
・全体像(オーバービュー)
・利用する実装技術
・実現したいこと一覧(要求一覧)
・行動シナリオ
・概念データモデル
・ラフイメージまたはモックアップ
・画面遷移図
・項目の説明
・機能の入出力定義
・機能の処理定義
・統合ERD
・一覧を作ろう
成果物の目次化を行う
・行動シナリオ一覧
・ワークセット一覧
・想定問答集を作る
これらの一覧を加えると成果物は次のものになります
・企画書
・全体像(オーバービュー]
・利用する実装技術
・実現したいこと一覧(要件一覧)
・行動シナリオ一覧
・行動シナリオ
・ワークセット一覧
・概念データモデル
・ラフイメージまたはモックアップ
・画面遷移図
・項目の説明
・機能の入出力定義
・機能の処理定義
・統合ERD
これが説明資料の目次になる
内部レビューの成果が想定問答集になる
予測されるなら資料自体に自明となるように手を加えること
・成果をリリースする
説明という形で成果をリリースする
[あとがき]
本書の肝は「画面遷移図を描こう」
おすすめツール
・inkpod(インクポッド)
・BEITEL(バイト)
カラビナシステムズのJavaソフト
クラウドならヌーラボのcacoo(カクー)
投稿元:
レビューを見る
平易で極めて分かりやすい内容。特にシステム関連以外の事例に例えて説明してあるので文系でもよくわかる。入門書に最適。
投稿元:
レビューを見る
要件定義はなんとなく先輩の動きを見て覚えてたが、この本を読んでから取り組んだらとてもわかりやすかったと思う。後輩にはまず最初に読ませる。
投稿元:
レビューを見る
20200216読了
要件定義の入門書。要件定義の位置づけや画面遷移図の作り方の記載がメイン。
自分が思っているよりも、要件定義とは実装よりだと実感した。
顧客の要望をシステム要件に変換する工程は、同シリーズのプロセス設計や他の本を読むべきかもしれないが、一冊で要件定義の全体像を理解するにはちょうど良いと思った。
投稿元:
レビューを見る
要件定義を行う機会があるので、全体像を理解する上に手に取りました。
要件定義とは何か、そのために必要な情報は何かについて平易な言葉で書かれていて読み進めることができました。
例示も注文といった身近な例を持って説明をしていました。飲み込みやすかったです。聞き漏らしたり、決めるを忘れると後工程の人は確かに大変だなと思うことがあったので気をつけていきたいと思いました。
何も分からない状態から何を聞いてまとめないといけないかを理解を進めることができました。要件を決めるとき、その時は落ち着いて臨みたいと思います。
投稿元:
レビューを見る
salesforce改修にあたり、改めて要件定義のおさらいをしようと手に取る。
平易な言葉と例えイラストで直感的に入ってきて分かりやすい。まとめる図例などは参考になる。
投稿元:
レビューを見る
要件定義という言葉を初めて聞いた人向けの本。
レベル感的にかなり易しめな印象で、要件定義でどんな作業が必要か、その作業を怠るとどんな問題が起こるかがわかる。
内容は簡潔にまとめられているため、詳細な勉強に進むための次のレベルの参考文献などが記載されてると良いと思った。
投稿元:
レビューを見る
仕事=活動+成果
業務プロセスを設計・改善するにあたり、3層での捉え方はとてもわかりやすく、誰にでも活用できるものだと感じた。
各層の捉え方もわかりやすく書かれており、全ての人にとって有益な本だと思う(値段は高いが、その分の価値は後々生み出せると思う)
本書はシステム開発の流れの一部について具体的な方法等を書いてあるが、システム開発云々以前に業務の棚卸しとプロセス設計出来てないですよねというところから書かれており、その点が全ての人にお勧めできる根拠である。
なにより著者による講座を受けれたこともあり、かなり自分にとって実用的な本であると感じた
投稿元:
レビューを見る
要件定義と一言で言ってもその工程はプロジェクトごとにバラバラで大変曖昧である。その中からこれは決めなきゃいけないよねというトピックを抽出しており、平易に理解しやすい内容になっている。
投稿元:
レビューを見る
内容は順序立っているので読むには良いと思う
要件定義は発注側の責任なので、やったことない人が最初に手に取るには良いかも