要求分析・要件定義
Client と Server があるスマフォゲームを 開発するときに人類が考えておくべき、ほとんど全てのこと
要件定義
プロジェクトの目標
・存在意義：食を通じて多くの家族を幸せにする
・使命：主婦の炊事の負担を減らし、かつ満足度の高いメニューを提供する
・目的：自社製品で主婦が楽に夕飯を作ることのできるクッキングサイトを開設
・目標：主婦のユーザーを1日1万人呼び込む
・与件：30～40代の既婚者にユーザーになってもらう、レシピには自社製品を含める
進め方
STEP1
情報収集……ヒアリングにより、発注者からの与件や要望をもれなく聞き出す
STEP2
整理・分析……要件を重要度に分けて取捨選択
STEP3
文書化……要件定義書を作成
ドキュメントの土台
聞くこと
聞く事 | |
What | 目的はなにか？ |
Why | なぜこの手段をとるのか？ |
Who | 誰、どのメンバーにするか？ |
When | スケジュール、期間は？ |
Where | ドメイン、デバイスは？ |
How | 制作の手法は？ |
Whom | 誰をターゲットにするか？ |
Which | どこからやるか？ |
How much | 予算は？ |
メリット・デメリット | メリット・デメリット |
基準 | 達成基準は？ |
カバーする項目
目次 | 内容 |
背景・目的 | プロジェクトが立ち上がった背景と目指すもの |
開発概要 | プロジェクトの目的を達成するために、開発する範囲とそのための手法。最終成果物は何か？ |
システム要件 | URL、サーバ環境、プログラム開発言語、データベース、ライセンスなど |
機能要件 | どのような機能、画面を介してユーザ体験を提供するか？ |
非機能要件 | セキュリティ、性能、バックアップ、デザイン、運用要件など |
基本ルール | レギュレーション、用語集 |
書くこと
このサービスは（例：働く主婦）のために（例：簡単なレシピ）を提供します。
それによって（例：自社製品）の売り上げを伸ばし、（例：企業名）は利益を出します。
注意点
あとで変更できるもの、できないものについて説明しておくこと。さらに、『いつまでに指摘してくだされば変えられます』というように、期限を明確にすることも大切です。「変更させないゾ」という脅しになってはいけない
https://creator.levtech.jp/tips/article/13/
アイデア抽出
ブレインライティング
＜ブレインライティングの流れ、まとめ＞
【1】アイデアを出すテーマを設定
【2】人数分用意しておいたブレインライティング用シートを各自に配布
【3】5分間、各自がテーマに沿ってアイデアを考えて一番上の3つの枠に記入
【4】左隣の人に自分のシートを渡し、右隣の人からシートを受け取る
【5】5分間、受け取ったシートに書かれた3つのアイデアの下に、そのアイデアを「発展」「補足」するアイデアを記入（全く新しいアイデアでもOK）
【6】以降、シートが埋まるまで、【3】～【5】の流れを繰り返す
【7】シートが埋まったら、手元にあるシートの中から良いアイデアを発表
シックスハット法
参加者は、会議の状況に合わせて、「白＝客観的」「赤＝直感的」「黒＝否定的」「黄色＝肯定的」「緑＝創造的」「青＝管理的」という役割が求められます。ファシリテーターが青になります。
通常、全員が黒色から始めます。最初にネガティブな意見を出しておいて、次に黄色や白色などに移っていきます。
この会議の実施にあたっては、帽子やバッチなどで各色を示すアイテムを、それぞれ人数分用意する事を忘れないで下さい。
＜シックス・ハット法の流れ、まとめ＞
【1】参加者の役割を決める
【2】決めた役割を示すバッチなどを配布
【3】予め設定しておいた議題に合わせて、ファシリテーター以外は黒色からブレストを行う
【4】以降、バッチの色を順番に変えていく。
【5】黒・黄色など反対の色の役割を交ぜてディスカッションする。両面での意見が出て議論が深まりやすい
ゴードン法
ゴードン法はブレーンストーミングの一種です。ブレーンストーミングと異なるのは2点。2セットに分けて行うことと、1セット目では本来のテーマではなくもっと広いテーマでブレストと行い、且つ、司会者しか本当のテーマを知らない事です。
1セット目はテーマを敢えて広げて視点を広げる
例えば、「不動産関連のWebサービス」の新サービス企画を考えるとします。その際、いきなり「不動産関連Webサービス」のブレストをしてしまうと、これまでの経験が思考に制限をかけて、知らず知らずのうちに固定概念に縛られたアイデアばかりが出てしまいます。
ですので、1セット目には「普段の生活であったら便利なWebサービスのアイデア」などのテーマでブレストをし、アイデアを募ります。
そしてようやく2セット目に本来のテーマでブレストを行います。この時、1セット目で出たネタも使いブレストを行うと、視点が面白いアイデアが出てきます。
＜ゴードン法の流れ、まとめ＞
【1】1セット目のテーマ発表
【2】1セット目のブレストを行う
【3】2セット目のテーマ発表
【4】2セット目のブレストを行う（この時、1セット目で出たネタもアイデアの視点として加える）
ブレーンストーミング（ブレスト）
基本
「批判をするな」：他人の意見を批判してはいけない。批判があると良いアイディアが出にくくなる。
「自由奔放」：こんなことを言ったら笑われはしないか、などと考えず、思いついた考えをどんどん言う。「上品は」ジョーク歓迎。
「質より量」：できるだけ多くのアイディアを出せ。
「連想と結合」：他人の意見を聞いてそれに触発され、連想を働かせ、あるいは他人の意見に自分のアイディアを加えて新しい意見として述べるというのが一つやり方。
「結論は出さない」
ルール
時間は30分以内くらい
１意見30秒以内
流れ
テーマ説明
参加者の殆どはこの時に初めてブレストのテーマを知ります。主催者からの説明は大切で「なぜそのアイディアが必要なのか」、「最終的に達成したい目的は何か」を参加者と共有させます。
非機能要件
非機能要求大項目 | 説明 | 要求の例 | 実現方法の例 |
可用性 | システムサービスを継続的に利用可能とするための要求 | 運用スケジュール（稼働時間・停止予定など） 障害、災害時における稼働目標 | 機器の冗長化やバックアップセンターの設置 復旧・回復方法および体制の確立 |
可用性 | システムサービスを継続的に利用可能とするための要求 | 運用スケジュール（稼働時間・停止予定など） 障害、災害時における稼働目標 | 機器の冗長化やバックアップセンターの設置 復旧・回復方法および体制の確立 |
性能・拡張性 | システムの性能、および将来のシステム拡張に関する要求 | 業務量および今後の増加見積り システム化対象業務の特性（ピーク時、通常時、縮退時など） | 性能目標値を意識したサイジング 将来へ向けた機器・ネットワークなどのサイズと配置＝キャパシティ・プランニング |
運用・保守性 | システムの運用と保守のサービスに関する要求 | 運用中に求められるシステム稼働レベル 問題発生時の対応レベル | 監視手段およびバックアップ方式の確立 問題発生時の役割分担、体制、訓練、マニュアルの整備 |
移行性 | 現行システム資産の移行に関する要求 | 新システムへの移行期間および移行方法 移行対象資産の種類および移行量 | 移行スケジュール立案、移行ツール開発 移行体制の確立、移行リハーサルの実施 |
セキュリティ | 情報システムの安全性の確保に関する要求 | 利用制限 不正アクセスの防止 | アクセス制限、データの秘匿 不正の追跡、監視、検知 運用員などへの情報セキュリティ教育 |
システム環境・エコロジー | システムの設置環境やエコロジーに関する要求 | 耐震/免震、重量/空間、温度/湿度、騒音など、システム環境に関する事項 CO2排出量や消費エネルギーなど、エコロジーに関する事項 | 規格や電気設備に合った機器の選別 環境負荷を低減させる構成 |
狩野モデル
E ・・・魅力的。競合との差別化に有効な機能。隠れたニーズとも呼ばれ、体験するまで気が付かない場合がある。
M ・・・必須。あって当然の機能。
L ・・・線形。あればあるほど満足度があがるような機能。コストとのバランスを考慮する必要がある。
I ・・・無関心。あってもなくても気にならない程度の機能。優先度が低い。
R ・・・逆効果。あると困る機能。
Q ・・・懐疑的回答。回答が不整合。
言語選定
コンパイル言語とシェルスクリプトの使い分け
コンパイル言語にするもの
実行速度が要求される場合
ソースコードを隠蔽したい場合
シェルスクリプトにするもの
Unixコマンドで処理を代用できる場合
複数のプログラムを連携させる場合
方針と前提の違い
方針：～しよう
前提：～されていること
方針：
今日夕飯は中華にしよう
前提条件：
食材がそろっていること
調理できる場所があること
問題分析
背景（Background）
問題・課題（Problem,Task）
解決策（Solution）
提案
序 本提案の概要と結論
1 システムの導入について
1.1 業務の現状
1.2 現状での問題点
1.3 システム導入の目的
1.4 システム導入の効果・成果
1.5 システム導入の背景
1.6 システム導入における課題
1.7 実現の方針・方策・方法
1.8 対象となる業務の範囲・領域
2 導入システムの概要
2.1 システムの構成
2.2 システム導入後の業務フロー
2.3 システムの品質条件、性能条件
2.4 システムの範囲
3 開発プロジェクトの進め方
3.1 開発プロジェクトの進め方
3.2 納入する成果物
3.3 開発体制
3.4 開発スケジュール
4 見積もり
4.1 コスト見積もり
5 先行企業の導入事例
5.1 A社のシステムと導入効果
5.2 B社のシステムと導入効果
5.3 C社のシステムと導入効果
Last updated