僕の要件定義アプローチを整理してみる - Life is Really Short, Have Your Life!!
あとでメインのブログにまとめようと思うので、軽めに書いておきます。 先日要件定義の手伝いを頼まれたことも踏まえて、少し自分の考えをまとめたいと思います。 コンピュータに出来ることは少ない 最初に訪れる問題は、システムで行えること・達成できることを大風呂敷を広げた状態で考えていないかどうかの確認です。Amazonと同等のレコメンドエンジンが欲しい！って言われても、はいそうですかと出来る話ではございません。 打ち合わせをしていくと「コンピュータに任せればあとはよしなにしてくれる」という空気感は、必ず所々に出てきます。そこを詰めていかないと認識がずれたままなので、いかにコンピュータでやることを具体化出来るかというのが要件定義の最重要課題だと思います。 業務フローを書こう 細かいのは要らん。決めたいのはシステムを利用する仕事の世界地図。見積から受注までの管理が必要なのか、売上のBIを分析したいのか
仕様変更に強い開発をするための、ヒアリングモデル
仕様変更に強い開発をするための、ヒアリングモデル：仕事を楽しめ！ エンジニアの不死身力（21）（1/2 ページ） 今回のテーマ：仕様変更が起きる理由、そしてそれを防ぐには ある程度の経験を積んだエンジニアなら誰しも、顧客から仕様変更を依頼されて困った経験があるかと思います。 仕様変更が起こると手戻りが発生し、開発工数の増大や予算の圧迫、納期遅れなどを引き起こします。さらに。「仕様だ／仕様ではない」「言った／言わない」といったコミュニケーションのトラブルは感情論になる場合が多く、顧客との信頼関係も悪化します。エンジニアは無理な仕様変更で士気を落とし、顧客は社内調整などでいら立ちを覚えます。 せっかく開発するなら、リソース的にも感情的にも気持ち良く仕事をしたいものです。そこで今回は、「なぜ仕様変更は起こるのか？」をテーマに、仕様変更が起きる原因を探り、それを防ぐヒアリング方法を紹介します。 ヒ
『要件定義の段階でユーザーが反射的に「YES」と答える理由』
ユーザーと要件を固めていっているときに、始めは特に制約を設けることなくヒアリングをしたりします。 こうすることで、ユーザーの要望が次々と出てくるのですが、どうしても工数やコストの関係からその中で取捨選択していかなくてはなりません。 ただ、その制約なき要件定義の場においてユーザーがやりたいことと実際に出来ることへのギャップというものが出てきます。 そういったものを無視してプロジェクトを進めていくと、後で大きな問題になることが多々出てきたり。 特にITにあまり詳しくないユーザーとヒアリングしていると、ある機能を実装するかどうかを決める段階で、「この機能を使えばこういう便利なことができますよ」とこちらから提案すれば、ユーザーはだいたい「YES」の答えを出してきたりします。 実際にその便利な機能を使うかどうかはその時点でイメージできてなくても、「あれば使うだろう」とか「付けれるというんだから取り合
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
ソフトウェア開発における、実現可能性を判断することの重要性：エンジニアの年輪：エンジニアライフ
ソフトウェア開発をする上で、要求が実現可能か否かの判断は非常に重要です。その理由は、開発工程の後半のフェイズで実現不可能であることが発覚しても、後戻りがきかない場合があるからです。冷静に考えれば誰でも理解できることですが、なぜかこの手の失敗は多く発生しています。では、失敗しないためには、どのようなアプローチをすればいいのでしょうか。今回は、これに対するひとつの考え方をご紹介します。 1．求められていることは何なのか？ “求められていること”、これはソフトウェアを開発する上で非常に重要であると共に、必ず抑えるべきポイントです。これを外してしまうと実現可否以前に、要求通りのソフトウェアを完成させることができなくなってしまうからです。 求められていること＝要求事項です。 この要求事項は、分類すると以下のようになります。 上記の表は、ソフトウェアに対する品質属性モデルとして、米国ヒューレット・パッ
ユースケース図 - Wikipedia
ユースケース図（ユースケースず）とは、UMLで定義されている図のうちの1つである。スウェーデンの計算機科学者イヴァー・ヤコブソンは、エリクソンでソフトウェア機能要求を特定するためにユースケースを考案した（ユースケース図）。 概要[編集] ユースケース図 システムに対する要件を特定するために使用される。 システムには、どのようなアクタ(利用者)が存在するのか、 それぞれのアクタはどういった操作(ユースケース)をするのかを記述できる。 一般的に、ユースケース図はシステムの要求を定義する際に利用される。 関連項目[編集] UML イヴァー・ヤコブソン
ユースケース - Wikipedia
ユースケース（Use Case）は、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能要求を含む振舞を把握するための技法である。各ユースケースは、何らかの目的・目標/機能に関する台本（シナリオ）での主体（アクター(actor)）と呼ぶ利用者（ユーザ）とシステムのやりとりを描いている。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行う。ユースケースを図にしたものがユースケース図であり、両者を厳密に区別すべき根拠はない。 1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの
要求仕様 - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2021年1月） 独自研究が含まれているおそれがあります。（2021年1月） 出典検索?: "要求仕様" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 要求仕様（ようきゅうしよう、requirement、requirements specification）とは、工学分野において特定の製品やサービスがどうあるべきかを記述する文書を指す。主にシステム工学とソフトウェア工学で使われる用語である。単に、要件、または英語の requirement からリクワイアメント（リクワイヤメント）ともいう。 従来からの工学的手法では、要求仕様を入力として製品開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「コンセプトと要件定義」のまとめ