投稿元:
レビューを見る
機械設計書を書く際に、どういう視点を持てばよいのか?どう記述すればよいのか?という疑問に対して、本書が参考になるのでは?ということで読んでみた。IT向けの書だったため、ちょと違ったかもしれん。しかしながら仕様の定義や、要件の洗い出しなどは、分野問わず共通の話であるので、単なるフォーマットの違いだ、という読み方でなんとか読了。まだ理解が足りないせいかピンと来ていない。類書をそれなりにあたり、補足する必要がある。
投稿元:
レビューを見る
非常に簡潔に「要件定義」のツボがまとめられている。さらっと一通り読むこともできるし、立ち止まってじっくり考えてみることもできる。
さすが、現場担当者にも業務分析が可能なツール「(おしごと)マジカ」の考案者だけあって行動シナリオの分類はお見事!カスタマージャーニーマップやサービスブループリントを使ってシステムとユーザーのインタラクションをささっと整理する人は必見!
プロトタイピングツールを使って要求洗い出ししている人にも、要件定義の全体像をサクッと把握したり時々見直すにもオススメ!
次は企画の本が欲しい…
投稿元:
レビューを見る
イラスト入りで読みやすいし、現代のテクノロジーも古典的な知見も満遍なく組み入れているあたりに筆者の力量を感じる。良書。
投稿元:
レビューを見る
「要件」という用語の定義には少々の違和感がありますが,要求工学の難しい本ばかりの状況にあって,非常にさらりと読めるのが良いですね。
最初に押さえておくべきトピックスもちょうど良いバランスなので,これから要求を勉強しようとする際に,最初の一冊に良いと思います。
投稿元:
レビューを見る
なんだか開発者にとって理想的なことが書かれてあった。こういう書類をもらえたら本当にありがたいよね。
とりあえず営業から作って欲しいシステムについてお願いされた時は、『UI』『機能』『データ』を意識して質問してみようと思った。後、CRUDも。たまに、あるデータについて、○○ならこうして、そうでなければこうして……、といわれるときがあるけど、その○○はどうすれば取得できるのか分からない時もあるし……。
投稿元:
レビューを見る
20150614 思い出す為に買ってみたが今の時代のやり方でまとめてあるので新鮮に読めた。同じことようでだいぶ違う。定期的に考え方を変えないとダメなのか。そこがこの業界の大変なところ。
投稿元:
レビューを見る
簡単な比喩から入りやすく、絵が多く分かりやすいです。
また、後半からは画面の作り方など、プログラムではありませんが、どう作るのかが書いてあり、あぁ、これが要件定義なのかと思いました。
後半は時間をかけずに読んでいましたが、なかなか興味深いお話し(作り方)だったので、機会があればもう一度読みたいです。
UIについて調べている人には一度目を通す価値はあると思います。
プログラミングの本ではありませんので、あくまでも要件定義の本です。
推薦図書なだけに、読みやすかったです。
投稿元:
レビューを見る
オンプレと違って、クラウドだったらこれくらいで十分でしょう。
とても優しく解説されていて分かりやすいです。
ただ、PaaSなどで使う場合は、UIの検討は後回しで良いと思います。
投稿元:
レビューを見る
とても分かりやすい本だった。イラストがあったのも大きいと思うが、情報が整理されている感じがした。明日からでも実践出来る内容が満載で、今要件定義で困っている人にも役立つ。
要件定義の準備が結構重くて、要件定義の中身はUI、機能、データという。これまで要件定義だと思っていたものが、要件定義の準備で、要件定義は半分基本設計みたいな感じがした。
要件定義にまつわる他の本も読んでみるつもりなので、比較してみたい。
投稿元:
レビューを見る
業務システム開発でもスマホアプリ開発でも、
ユーザ・顧客が納得のいくソフトウェアを実現するためには「要件定義」というフェーズが欠かせません。
要件定義とは、「作ってほしい人と作る人の間の合意事項」であり、
「UI」「機能」「データ」をどのようにするか決めていくことを言いますが、
実際にはこのフェーズをおざなりに開発を進め、プロジェクトが迷走するケースが後を絶ちません。
本書では、ソフトウェアの企画・開発に携わるすべての方にとって役に立つ「要件定義」の知識を、豊富な図解とともにわかりやすく解説します。
本書では、UI・機能・データという3要素を軸に、
どのように要件定義の工程を進めれば良いかが簡潔に解説されています。
一般的には画面設計(UI)だけ作って終わりというプロジェクトが多く、
本書でも「画面遷移図を描こう」が肝だとあとがきで述べられています。
また、ER図やCRUDマトリクスについてや、
要件定義の準備として企画内容を確認したり、
システム全体像を描いたりなどといった話も少ないページの中にバランス良く盛り込まれています。
・要件とは注文であり、依頼事項(リクエスト)である
・自社で何を作れるか、技術が分かっていないと注文は受けられない
・”依頼者の目的を達成すること”がソフトウェア開発の目的
依頼者の目的を達成できるのなら、要求とは違う代替案の提示もありえる
・依頼者は画面(UI)越しでしか確認できない。画面は大事
・企画書(目的、ゴール)を資料として明確にし、共有すべき
依頼側と開発側でこの認識がブレると、手戻りが発生しやすく、完成したものが別物になりやすい
当然、互いにとって理解できる企画書であるべき。開発者しか分からない資料は意味がない
■要望と要求と要件を分けて考える
要望: システムによって叶えたい思い・未来像
要求: 要望を叶えるために必要な能力や成果物
要件: 要求を満たすために必要な条件
要件定義が出来ているというのは、
この「要望⇔要求⇔要件」が分割統治されていることが大切です。
つまり、
要件に落としこむまでに然るべき理由がそこに存在しているか、
その要件でなければならない理由は語られているか、
そういうことをチェックするには分割統治するしかないからです。
やりたいことと、やらねばならない理由と、
要求を満たすためにやらなあかんことが分けて考えられていないと、
要求自体の間違いに気が付かないことになります。
■全てのステークホルダーを明確に
要件定義はそのシステムに関わる「全ての」ステークホルダーの要求を
可能な限り実現する必要がありますが、
その全体像をこうまとめると簡単だよって絵がありました。これはわかりやすい。
システムを中心とし、ステークホルダーでレベル1を作り、
その要望をレベル2として書いているマインドマップのようなもの。
そのシステムを使うことで別のステークホルダーの負担が増えたり、
何かが犠牲になったりするということが、要件定義の過程で結構あります。
大抵それが地雷になりますので、早めに地雷を摘むためにも全てのステークホルダーの要求をキチンと整理しましょう。
■システム化対象業務の設計ポイント
全体図だけでは設計に移れませんので、
ドリルダウンして実際の作業とシステムの関係を明確にしていく必要があります。
羽生さんは「行動シナリオ」の作成を薦めています。
下記の情報が整理された実際のお仕事の流れをまとめたもの。
“
•その仕事を行う人(役割)
•その仕事の判断・完了基準
•その仕事の受け渡し先
特に自分の仕事が終わった!と判断できる基準が最も大切。
知りたいのは行動を決めるための判断基準。
その基準を満たせない場合は例外処理やバリデーション対象になる。
要件定義の時点でそこまで見ていく必要があります。また、下記の2つも考慮ポイントです。
“
•差し戻される場合はどういう時か
•やり直したい・中止したい場合はどうしているのか
この2つも重要なので考慮して下さい。
前者は例外処理やバリデーション、
後者はCRUDが発生した場合に仕様として足りていないものがないかを確認できます。
この設計したシナリオを元にユースケースが生まれて要件が見え、
要件を満たすための仕様を考えるフェーズに移っていく。
■システム仕様検討はUIファーストで
UIを作りながら作業に必要なデータを洗い出して構成をまとめ、
仕事に必要な情報を定義してまとめていきます。
最終的に、必要なのはレイアウトとアクションと生み出されるデータ。こ
れが定義されていないとシステムの機能が正しいかどうか、ユーザーが判断できない。
レイアウト: UI部品。タブ、コンボボックス、テキストボックス、ボタン、表など。
アクション: クリック、スワイプ、キーダウンetcのUIのイベント。
データ: その画面で最終的に作られる or 表示されるデータ。
どの作業中に何をして欲しいかを明確にして、
ユーザーが何を判断してどんな仕事を完了したいかを詰めていくのが良いと思います。
これがこう出来ていればあなたのお仕事は完了できますよね〜っていうアプローチ。
UI設計は入力系の画面から。
まずは何を入れるかを先に決めないと。
マスタメンテじゃなくて、行動シナリオの中で受け渡して流れていく情報を作って保存するための画面のUI設計からはじめて下さい。
(いきなり帳票設計はしない。インプットが決まらないのに検索項目の話はしない)
UIを決める→データを決める→そのデータを作り出すためのプロセスを決める、という流れ
(目次)
第1部 要件定義って何だろう?
•Chapter-01 要件定義=要件を定義すること
•Chapter-02 要件定義の基本的な流れ
•Chapter-03 定義すべき要件の内訳
•Chapter-04 3つの要素の定め方第2部 要件定義の詳細
•Chapter-05 要件定義,その前に[準備編]
•Chapter-06 企画を確認する
•Chapter-07 全体像を描こう
•Chapter-08 ��まかに区分けしよう
•Chapter-09 実装技術を決めよう
•Chapter-10 実現したいことを整理整頓しよう[助走編]
•Chapter-11 利用者の行動シナリオを書こう
•Chapter-12 概念データモデルを作る[離陸編]
•Chapter-13 UIを考えよう
•Chapter-14 機能について考えよう
•Chapter-15 データについて考えよう
•Chapter-16 要件定義の仕上げ
•Chapter-17 要件定義,その後に
投稿元:
レビューを見る
ベテランが読むのに適しているかは分からないけど、ビギナーにもとても読みやすいと思った。
◼ビギナーにも読みやすいポイント
「易しい言葉に言い換える」
「イラストを多用する」
◼その他の読みやすいポイント
「キーワードは繰り返し提示する」
「1ページに情報を詰めすぎない」
投稿元:
レビューを見る
良著だと思います。
ブリッジSE業務内容そのもので、わかりやすい言葉で書かれています。ぜひ、発注者側に読んで欲しい...
特に、次の点でよかったです。
・言葉の定義が丁寧
・マインド(成果⇒評価⇒効果があって然るべき)
・要件定義工程を全体⇒詳細で網羅
⇒最低限、これだけあれば大炎上は防げるレベル
本書内で「中流工程」と書かれていますが、そのとおりで、企画と実装のブリッジを理解されたい方の入門書としておススメです。
投稿元:
レビューを見る
システム開発には10年ほど関わっていますが、この本を読むことで要件定義ですべきことを改めて整理することができました。いつも感覚的に行っていたことが体系的にまとめられていてとても分かりやすく、新たな方法や気づきを与えてくれる本だと思います。
必要な時にいつでも読み返せるように手元に置いておきたい本です。
投稿元:
レビューを見る
プログラミングについてある程度の知識がないと理解するのが少し難しい。全くの初心者よりも、プログラミングの技術はあるけれどもうまく周りと連携が取れないという人向けの本だと思う。
投稿元:
レビューを見る
システム開発の要件定義の入門書。プロジェクト失敗の原因は要件定義が最も多いと聞いたことがあるがそもそも何が出来ていれば十分なのか?要求一覧からの絞り込みで迷走気味だったので要件定義の前に全体像を描いて実装技術を選定するという話がとても勉強になった。サクッと読める分量も助かる。