タグ

要件定義とRDに関するm_pixyのブックマーク (44)

  • 要求交換フォーマット(ReqIF)を調べてみた。(1) - たこはちの「へのかっぱ」日記

    OMGが公開している要求交換フォーマット(ReqIF:Requirements Interchange Format)について調べてみた。以下のURLからダウンロードしたReqIFの仕様書を読んでいるところだ。2011-04-02にリリースされている。 http://www.omg.org/spec/ReqIF/1.0.1/ 以下の記事も参照のこと。 (1) ReqIFの3つのユースケース (※この記事) (2) ReqIFの8つの機能 (3) ReqIFの再利用性、RIFとの差異 (4) ReqIF/RIFの動向 (5) ReqIFフォーマットの構造 (6) ReqIFでの代替IDとアクセス制限 ReqIFは、要求を記述したファイルをXMLの統一規格で定義して、企業間やツール間で扱いやすくしようというものだ。これまで「要求仕様」は、WORDやEXCELで記述したり、リーズナブルなツールな

    要求交換フォーマット(ReqIF)を調べてみた。(1) - たこはちの「へのかっぱ」日記
    m_pixy
    m_pixy 2011/09/22
    まったく聞いたことがなかった。直接的に触れることはなさそうだけど、ちょっと調べてみるか。
  • i* Intentional STrategic Actor Relationships modelling - istar

    November 15, 2010 From MIT Press: "This book offers a new approach to the requirements challenge, based on modeling and analyzing the relationships among stakeholders. The i* framework conceives of software-based information systems as being situated in environments in which social actors relate to each other in terms of goals to be achieved, tasks to be performed, and resources to be furnished. T

  • CSPO 認定スクラムプロダクトオーナーを受けてきた - メソッド屋のブログ

    先日2日間で、CSPO Certified Scrum Product Ownerを受けてきた。 このコースはホンマ凄い。何が凄いっていろいろあるけど ・全てボランティアベース/コミュニティベースで運用されている ・スクラムの父、ジェフ・サザーランドさんとガブリエル・ベネフィールドさんがやってくる! ・CSPOのコースが初めて日で行われる! ・最終日に、スクラムの父「ジェフ・サザーランド」日アジャイルの父「平鍋健児」 スクラムのアイデアの元「野中郁次郎」さんのスリーショットと歴史的ディスカッション なんて夢のようなラインナップが実現したんだけど、参加者がこれまた凄い。 @emersonmillsや、@essense_sや、@ryuzee @miholovesq @kawaguchi @nobiinu_and そして原田さんといった現在のスクラムを牽引する中心メンバー。そして同期メンバ

    CSPO 認定スクラムプロダクトオーナーを受けてきた - メソッド屋のブログ
  • ユーザー要件を引出すテクニック: ユースケースかストーリーボードか

    ユーザー要件を引出すテクニック: ユースケースかストーリーボードか:The Rational Edge(1/2 ページ) 機能はITシステムを成功させるために重要な要因の1つだ(最も重要だとする声もある)。ユーザーは、自分たちの仕事が楽に、早く、確実に片付くよう、ITシステムが支援してくれることを期待している。ユーザーは、ヒューマン・コンピュータ・インターフェイス(HCI)経由でシステムと対話するが、1990年代前半にGUIが台頭したことで、多くのユーザーが自分たちのニーズやシステムとの対話方法に対する希望を明確に示すようになった。ソフトウェアエンジニアリングにおけるHCIに重点を置いた場合、そこには解決しなくてはならない2つの問題がある。a)一般に、ユーザーはユーザビリティの専門家ではないこと、そして、b)ソフトウェアエンジニアはHCIの内側にある機能を特定し、それを構築しなくてはならず

    ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
  • 要求分析に表れるソフトウェア技術者の心

    要求分析に表れるソフトウェア技術者の心:上を目指すエンジニアのための要求エンジニアリング入門(3)(1/3 ページ) 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。 とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステム

    要求分析に表れるソフトウェア技術者の心
  • クリエイティブなエンジニアスタイル5カ条:第4条:要求開発まで踏み込むべし | 豆蔵ソフト工学ラボ

    クリエイティブなエンジニアスタイル5カ条 第4条:要求開発まで踏み込むべし 印刷 株式会社豆蔵 プロフェッショナルフェロー 萩 順三  2009/04/22 [業界への提言] 要求開発とは、ビジネスを"見える化"し、IT化すべき箇所をできるだけ早く定め、そこに必要とされる要求を決めていく活動ことである。要求開発はビジネス開発と言っても過言ではない。クリエイティブなエンジニアスタイルとして、なぜ要求開発まで踏み込むべきなのか説明しよう。 第4条:要求開発まで踏み込むべし エンジニアリングを楽しむという事 クリエイティブなエンジニアは、エンジニアリングを楽しむべきである。そしてエンジニアリングの価値を証明すべきなのである。 エンジニアリングを楽しむためには、納得感のあるエンジニアリングを行うことが必要となる。なぜなら納得感があるからやりがいがあり、楽しめるからだ。 さて、エンジニアは、どのよ

  • 要求は怪物みたいなもの

    Angry Aussie / 青木靖 訳 2007年8月1日 水曜 8歳になる娘と話をすると、自分が何でもわかっているなどとは思わなくなる。 質問が上手なあの子は、私が答えられなかったり、少なくとも真剣に考えなきゃならないようなことを聞いてくる。真剣に考えるというのは重要で、いい加減な答えをしようものならすぐ突っ込まれてしまう。彼女が5歳で母親に日曜学校へ送り迎えしてもらっていた頃のある日、何の前触れもなくこんなことを聞いたことがあ った。 「ねえ、神様が私たちを作って、そして私たちを好きでいるなら、どうして神様は私たちが病気になるのをほうっておくの?」 あなたならどう答えるだろう? 私が最初に思いついたのは「ママに聞いてごらん」ということだった。しかしこれはその場しのぎにしかならない。最終的には「死なないくらいの病気かかると、かえって体が丈夫になるんだよ」という冴えない答でどうにか逃げお

  • PMBOKの次は「BABOK」が来る?

    1987年に「PMI(Project Management Institute)」がプロジェクトマネジメントの知識体系「PMBOK(Project Management Body of Knowledge)」を初めて発行してから,約20年が経過した。このPMBOKに基づくプロジェクトマネジメントは,日でも,ここ10年くらいで広く普及した。PMBOKをベースにしたプロジェクト・マネジャーの国際資格「PMP(Project Management Professional)」の日での取得者も,2万人以上に登る。 PMBOKの登場で,プロジェクト・マネジャーの仕事は,経験とカンに頼った「プロジェクト管理」から,科学的な「プロジェクトマネジメント」へと進化した。そして,その効果は確実にあったと言える。 そして今,PMBOKに続いて,注目され始めているのが「BABOK」である。 BABOKとは,B

    PMBOKの次は「BABOK」が来る?
  • 作るシステムより人に着目--読売新聞東京本社ほか

    唯一、論文形式で受賞したのが、読売新聞東京社を代表とする「ユーザー要求を引き出す分析手法の研究」だ。近年、大きな課題になっているシステム構築の上流工程であるユーザー要求段階で、どうやって真のニーズを引き出すかというテーマ性と実現性のバランスが評価された。 「ユーザー要求を引き出す分析手法の研究」は、富士通のユーザー会であるFUJITSUファミリ会LS研究委員会分科会が、1年をかけた研究をまとめた論文だ。読売新聞東京社制作局技術一部の武田臣司主任をリーダーに、15社15人が参加し、06年3月に発表した。 論文のテーマは、システム構築の上流工程である要求定義をいかに確かなものにするか。システム構築の成否は、上流工程、なかでもユーザー要求をどう定義するかにかかっているとされる。ベンダーへの“丸投げ”体質を改め、当に必要なシステムを作るために、多くのユーザー企業が要求定義力の強化に乗り出して

    作るシステムより人に着目--読売新聞東京本社ほか
  • それでいくら儲けるの? 狩野分析法だけではうまくいかないよ - masayang's diary

    狩野分析法の記事はCertified Scrum Product Owner Trainingで一番印象に残った要件分類手法だったので真っ先に書いてみたが、あれほどの反響があるとは... ブックマークのコメントを見ても「使えそう」という声が多い。 でも、「狩野分析法」は利用者の声をもとに要件(フィーチャ)の優先度をつけるのには役立つかもしれないが、それだけでAgile開発につなげるのは正解とはいえない。利用者が要求するフィーチャ=事業として儲かるフィーチャ、とは限らないからだ。 基は「そのフィーチャでいくら儲けるのか」「そのフィーチャ開発にいくらかかるのか」の分析であろう。 それでいくら儲けるの? フィーチャ毎に「それでいくら儲けるのか」を考える。 簡単なようで、難しい。 自分がお世話になっている日の某お客さんのところでは以前から実行している。経営層の人が「この要件を書いたのは誰? お

    それでいくら儲けるの? 狩野分析法だけではうまくいかないよ - masayang's diary
  • 第6回 RFPの書き方:要件を確実に伝える表現のコツ

    前回「RFPの書き方:どんなインターネットショップなのか?」では、「何を作りたいか」「何を目指すのか」など頭に思い描くシステムの完成イメージをRFPという形で文書にまとめて表現することの大切さや、およそどのようなことを書いたらよいのかという点について話を進めました。今回は、「どのように表現するか」ということについて、書き手の立場で注意すべき点について説明していきます。 どこまで詳細なRFPを作成すればよいか RFPを作成するのに当たり、まずはどこまで詳細に記述すべきかを明確にしておく必要があります。例えば、日曜大工仕事が得意なあなたの元に、友人から「が増え過ぎたので机の横に置く棚を1つ作ってくれないか。必要な費用は前もって払うから」という依頼があったとしましょう。当然、あなたはどのような棚を望んでいるのか確認をすることでしょう。しかし、その友人は忙し過ぎて満足に説明する時間も取れず、

    第6回 RFPの書き方:要件を確実に伝える表現のコツ
  • 狩野さん的なアレ。 - 設計と実装の狭間で。

    迷ったら狩野さん!...狩野分析法による優先度付け と、あります。おお、スゲェ。何となく分り易そうな感じ。 でも、いくつか釈然としない部分が例の表の中にはあったりする。 具体的には、以下の二つ。 # L...Linear(性能) * なくてもよいが、あればあるほど良い。 # E...Exciter(魅力) * いわゆる差別化ポイント。 Lは、ホントに無くても良いの? そもそも、LとEになる為の条件にもしっくりこない感があったり。 と言う訳で、迷ったら原典に当たれと昔の偉い人は言っていた気がする。 で、狩野さんて、どこの狩野さん? Scrumとかそういうコンテキストで、英語だと、どうやら「The Kano Model」とかそんな感じらしい。 で、結局この人なんかな…。 狩野紀昭 カノウ ノリアキ KANO Noriaki でも、Amazonみると、どうも違う様な…。合っている言えば合っている

    狩野さん的なアレ。 - 設計と実装の狭間で。
  • ユーザーが欲しいのはシステムではない ― @IT情報マネジメント

    要求定義の不備で大量の仕様変更が発生、プロジェクトは火の車に……。そんな事態を防ぐため、体系化された要求定義の方法論を提供するのが「MOYA」だ。連載では、MOYAの手法を活用して顧客の「隠れた要求」を引き出す方法を解説していく。 お客さまが当に望んでいるもの 「人はドリルが欲しいのではない、穴が開けたいのだ」 この言葉(あるいは似たような言葉)を聞いたことがある方は多いのではないでしょうか。これはニーズについて語られた有名な言葉で、欲しいのは商品ではなく欲求を満たすことであって、商品はその手段であるというものです。 システムを作る際にも、同じことがいえます。 「人はシステムが欲しいのではなく、業務をより良くしたいのだ」 といったところでしょうか。 つまり、こんな機能が欲しいというお客さまの要求(と思われる発言)は、その機能自体が欲しいわけではなく、その機能が提供している何かの価値が欲

    ユーザーが欲しいのはシステムではない ― @IT情報マネジメント
  • ユーザーの「思い」は、1つだけではない

    顧客側の意見がバラバラなのは、当たり前 前回は、要求定義を行う際に有用な思考ツールとして、XYZ公式をご紹介しました。今回は「リッチピクチャー」というツールを取り上げます。 まずは前回に引き続き、結婚相談所を営む顧客へのシステム提案のケースを用いて説明していきましょう。以下のケーススタディをご覧ください。 あなたはいま、「会員に対するアドバイザーのカウンセリング時間が少ない」という課題に取り組んでいます。適切なシステム要求を抽出するためには、課題をしっかり把握した上でソリューションを提案しなくてはなりません。あなたはこの「カウンセリング時間が少ない」という課題の状況をより具体的に理解するために、関係者にヒアリングを行うことにしました。 まずこの結婚相談所のオーナーである社長に、なぜカウンセリング時間が少ないことが問題であるのかを尋ねました。 「カウンセリングは、わが社のなかでも大切な業務な

    ユーザーの「思い」は、1つだけではない
  • 迷ったら狩野さん!...狩野分析法による優先度付け - masayangの日記(ピスト通勤他

    追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか? まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件(フィーチャ)を開発していく」のが基だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的

    迷ったら狩野さん!...狩野分析法による優先度付け - masayangの日記(ピスト通勤他
  • ワークフローエンジンを欲する前に

  • 要求発明学入門(1)

    顧客の望み通りのシステムを開発したはずなのに,なぜか満足してもらえない。彼らが語った要求はすべて正確に実現しているのに,いったい何が不満だというのだ? そんな割り切れない気持ちを抱いた経験を持つ読者も多いだろう。 その答えは「顧客を喜ばせようと思えば,彼らが望まないものを作ることだ」というパラドックスの中に隠されている。つまり,顧客が想像すらしなかった要求を発明して提供する必要がある。今回はそんな「要求の発明」について考えてみよう。 要求の価値判断基準の把握が難しい 筆者は20年以上にわたりシステム開発に携わってきたが,顧客に心から満足してもらえる価値の高い要求を,どうやれば識別できるのかが未だによくわからない。価値が高い要求だと考えて精魂込めて作り込んだ機能が,こちらが期待するほどには喜んでもらえない。逆に,あまり価値が高くないと値踏みしていた機能が,意外なほど喜んでもらえたりする。そん

    要求発明学入門(1)
  • システム化範囲がぶれていれば失敗する ― @IT自分戦略研究所

    プロジェクトの失敗例で多いのは プロジェクトの失敗で、一番多いのはシステム化範囲(スコープ)がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである。 このようなプロジェクトは昔から後を絶たないのであるが、その対策が十分に取れているとは思えない。今回は、このシステム化範囲がぶれる問題を考えていきたい。 なぜ、システム化範囲はぶれるのか システム化範囲がぶれる理由はいろいろあるが、その代表的なものを挙げてみる。 (1)「xxシステム一式」という契約書は意味があるのか そもそもシステム化範囲は明確になっているのであろうか。最近私が関与した会社で、ベンダから送られてきた契約書を見せてもらったが、そこに記載された委託内容は「生産管理システム一式」という文言が1行書かれているだけであった(図1。この契約書は、一体どういう意味を持っているのであろう。確かに金額や一般的な責任は

    システム化範囲がぶれていれば失敗する ― @IT自分戦略研究所
  • 第2回 成否のポイントは上流にあり:要求を洗い出す四つの工夫

    リッチクライアントはインタラクティブな操作が可能で,表現上の演出をする余地が大きい。自由度が高いだけに,利用者はどのようなユーザー・インタフェース(UI)を実現できるかについてのイメージを持ちづらく,「使い勝手に対する要求は,具体的にモノを見ないとほとんど出てこない」(SIベンダーのクオリテック コンサルティング部 シニア・システムエンジニア 藤原誠氏)という。 しかし,いざモノを見ると,一転して利用者のイメージは広がり,あれもこれもと要求が噴出してしまいがち。「リッチクライアントを利用した開発プロジェクトにとって,最大のリスク要因は使い勝手に関する要求の管理」(日立システムアンドサービス 金融ソリューションサービス部 技師 境丈利氏)である。 つまり,リッチクライアント・プロジェクトの成否は,システム構築の上流工程にあるというわけだ。従来のシステム開発よりも,要求管理や要件定義が重要にな

    第2回 成否のポイントは上流にあり:要求を洗い出す四つの工夫
  • 「要求分析ツリー」を使って要求の構造をとらえる

    システム構築プロジェクトの開始段階では,課題や要求を獲得する手段として,インタビューやヒアリングを使用するケースが多くあります。 企業活動のシステム化に際しては,オーナーである経営層から,実際にシステム操作をする現場の担当者まで,多くのステークホルダーが存在します。経営層と現場担当者では,当然のことながら視点や価値観が異なるので,同じ質問をしても聞く相手によって様々な回答が返ってきます。 例えば,現状の課題や新システムへの要望を質問した場合,経営者からは,「売上増加(3年後に年商120億にする)」とか「パート比率を上げることにより,人件費を削減したい」など,財務的な視点からの抽象度の高い要求が多くあげられます。一方,現場担当者からは,「在庫管理画面で他店の在庫を表示して欲しい」とか「××システムのレスポンスが遅いので速くしたい」など,自分の担当する業務に直結した具体的な機能要求があげられま

    「要求分析ツリー」を使って要求の構造をとらえる