タグ

要件定義に関するymkz303のブックマーク (11)

  • 画面設計とか外部設計とか、もうやめようよ - masayang's diary

    昨日は特徴(Feature)、粗筋(Story)、脚(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう? 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え

    画面設計とか外部設計とか、もうやめようよ - masayang's diary
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • はてなブログ | 無料ブログを作成しよう

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    はてなブログ | 無料ブログを作成しよう
  • 企業の業務システムにUIはいらない - これ僕.com:行動分析学マニアがおくる行動戦略

    とあるEAI製品の仕様システムを聞いていて、もう業務システムにUIっていらないんじゃね?と思った UIがいらないというか、従来のWeb画面やデスクトップアプリで作りこむ必要はない、と感じた。Excelやテキストファイルでいいよ、と。 EAI製品について詳しく知っているわけではないけど、私が聞いたものは、例えば以下のようなことができる。 営業担当者は、自身の案件に関する進捗レポートをExcelで書いてメールに添付して送信 システムは、メールの受信を検知したら、添付されたExcelファイルからデータを取り出し、DBへ登録 管理者は、毎週、週間レポートを要求するメールをシステムへ送る 文に期間や部門コードをCSV形式で記入すれば、検索条件になる システムは、メールの受信を検知したら、DBからデータを取得し、Excelを生成。それをメールに添付し、依頼者へ返信する このくらいのシステムなら、GU

    企業の業務システムにUIはいらない - これ僕.com:行動分析学マニアがおくる行動戦略
  • 要件定義をロジカルシンキングで解析する - プログラマの思索

    「30の「勝負場面」で使いこなす ロジカル・シンキングの道具箱」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。 要件定義と問題解決、ロジカルシンキングについて考えたことをメモ。 【1】業務系システム開発のリスクは、Railsのような最新技術の習得、TiDDのようなプロジェクト管理、TestLinkのようなテスト管理など色々あるが、一番のネックは要件定義だ。 元々の要件が顧客の認識とずれていたら話にならない。 しかしながら、新規顧客の場合、顧客と一緒に開発してリリースして運用しなければ、顧客の来の要求が何だったのか、が分からない時はすごく多い。 だから、SIerのビジネスモデルとしては、1次開発は赤字だったとしても2次開発や運用保守で黒字になるように仕向けるのが普通だろう。 特に大手SIerが政府の公共システムを受注する場合が当てはまるだろう。 だが、そういうリスキー

    要件定義をロジカルシンキングで解析する - プログラマの思索
  • 「要件定義ではなく、要件開発」と唱えてみよう

    過去の仕事の延長線上での工夫や改善も大切だが、仕事に対する考え方を根から変える発想はいつか必ず出てくる。過去にとらわれず、虚心坦懐にこれらの思想、アイデア、メソドロジーに触れ、思考パターンを変えていく必要がある。 競争に敗れる落とし穴 企業人は、あるいは中間管理職は、不断の勉強をしなければならない。 ものの考え方や問題解決へのアプローチの仕方など、経営手法はどんどん進化している。 旧来のやり方に固執していると、時代の流れに置いて行かれ、競合他社の後塵を拝することになり、思わぬ落とし穴にはまりかねない。 例えば、IT導入を成功させるための重要な条件の1つに、「要件定義」がある。「要件定義」の考え方や方法も変化してきている。いや、変化させなければならない。 その他にIT導入成功の条件として、トップの適切な関与、目標の定量表示、プロジェクトメンバーの人材確保、意識改革、人材教育、BPRなど挙げ

    「要件定義ではなく、要件開発」と唱えてみよう
  • 要求開発アライアンス openthology

    マーケティング アフィリエイトとは何ですか? アフィリエイトは、企業が第三者の出版社に報酬を支払い、その企業の製品やサービスへのトラフィックやリードを生成する広告モデルである。第三者であるパブリッシャーはアフィリエイターであり、報酬を得ることで、企業を宣伝する方法を見つけるインセンティブが得られます。 アフィリエイト・マーケティングの理解 インターネットの普及により、アフィリエイトマーケティングの存在感は増している。アマゾン(AMZN)は、ウェブサイトやブロガーがレビューや話題の商品のアマゾンページへのリンクを貼り、購入があった場合に広告料を受け取るというアフィリエイトマーケティングプログラムを作り、普及させた。このように、アフィリエイトは、販売行為を広大なネットワークに委託して行う成果報酬型のマーケティングプログラムである。 アフィリエイトはインターネットが普及する以前から行われていたが

  • Í×·ïÄêµÁ¡¦´ðËÜÀß·× - µ»½Ñ¾ðÊóWiki

    ´ðËÜÀß·× † ¥·¥¹¥Æ¥à¤Î¥ê¥×¥ì¡¼¥¹°Æ·ï¤¬ºÇ¤â´í¸±¤ÊÍýͳ 2008.2.24 ±¿ÍѤ·¤Æ¤¤¤¯¤¦¤Á¤Ë¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤äµ¡Ç½Äɲäǡ¢¶²Îµ¤Î¤è¤¦¤ËÇϼ¯¤Ç¤«¤¯¤Ê¤Ã¤¿Ãæ¿È¤Ï¡¢ºÇ¿·¤Î¥ª¥Ö¥¸¥§¥¯¥È»Ø¸þ¸À¸ì¤Ç¡¢Æ±¤¸¤è¤¦¤Ë¤¿¤¯¤µ¤ó¤Î¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½Å¤Í¤ÆÀѤ߾夲¤¿¤â¤Î¤ËÊѤï¤ë¡£ Ʊ¤¸¥½¡¼¥¹¥³¡¼¥É¤ÎÃÇÊҤϰì¤Ä¤â¤Ê¤¤¤Ï¤º¡£ ¥×¥í¥°¥é¥à¤ÎÊݼéÀ­¤ä°Ü¿¢À­¡¢ºÆÍøÍÑÀ­¤¬¡¢¤É¤Î»þÂå¤Ë¤Ê¤Ã¤Æ¤â¡¢¸À¸ì¤¬¤¤¤¯¤éȯŸ¤·¤Æ¤âÆñ¤·¤¤¤³¤È¡£ Æä˺ÆÍøÍÑÀ­¤Ï¡¢¤½¤Î¥

  • 要求定義の方法論を知る【前編】:DOA型要件定義の実際

    IBMのシステム開発プロジェクトで多くの実績を持つDOA(データ中心型アプローチ)型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし,DOAはあらゆるプロジェクトに応用できる極めて基的なアプローチである。基をしっかりと押さえて欲しい。 「いつまでたってもユーザーインタフェースが決まらない」,「設計の段階で機能が追加され,開発範囲が膨れ上がった」,「テスト段階に入ってからも仕様変更が多発する」,「システム・テストの中盤でデータベースが変更され,すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば,これは要件定義のやり方にそもそもの問題がある。 来システム開発プロジェクトでは,予算,期間,開発の優先順位に見合った最適なスコープ(開発範

    要求定義の方法論を知る【前編】:DOA型要件定義の実際
  • 橋本正徳の「あなたのためのシステム開発」 : 「要件定義」について - livedoor Blog(ブログ)

    「要件定義」については、「顧客からヒアリングなどを行いシステムの仕様を決定する作業」だとか、「ビジネスやシステムの課題を明らかにし、あるべき姿(要求仕様)を列挙すること定義します。」だとかって書かれていたりします。 ・システム化のための要求定義の品質向上 ・「見える化」でソフトウェア開発! まぁ、そんなニュアンスのものです。 「要件定義」という作業は、とても大事で、じっくり検討しなければならないところだと思います。 この「要件定義」の仕上がり次第で、実際の開発のときのコストとスピードが大きく変わるので、さらに重要度は高くなります。 また、システム開発の担当としても、お客様との初めての共同作業の場です。 とても大事に思います。 インターネットに公開するタイプの、いわゆる「Webコンテンツ」は、「Web制作会社」というデザイナ寄りの会社、もしくは、うちのような、プログラマ寄りの

  • いまさら聞けない要求管理の基本

    なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか? 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか? プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな

    いまさら聞けない要求管理の基本
  • 1