takeda-soft.jp - takeda soft リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
プロジェクトで要件変更の発生を避けるには
ほとんどのプロジェクトでは、「要件のクリープ（確定したはずの要件の変更）」が発生する。クリープは、予算やスケジュールの超過を招く大きな原因であり、これらの問題はストレスやミスにつながるほか、評判を傷つけてしまう。では、どうすれば要件のクリープとその影響を避けられるのか。 数十年にわたって要件定義が重要視されてきたにもかかわらず、クリープは依然としてプロジェクトトラブルのもととなっている。「システム分析」「構造化分析」「オブジェクト指向分析」「ビジネス分析」など、呼び名が何であれ、こうした「要件」分析手法は、要件定義を多少改善させただけであり、要件のクリープを大幅に減らすには至っていない。 クリープが相変わらず発生しているのは、こうした従来のアプローチでは、わたしが「本当の」ビジネス要件と呼んでいる重要な要素が見落とされているからだ。おなじみの例を見てみよう。 ATMの例 要件について講演し
戦場ヶ原の稲妻（１）
以下はＲ３０の開発時に、主要スタッフのベクトルあわせを行うために、コンセプトリハーサルで櫻井眞一郎氏が自ら執筆し、朗読したストーリーである。 一人の男がいます。一人の女がいます。二人は恋人で、つきあって５〜６年でしょうか。男は３０歳を越えており、女はその２〜３歳下です。それだけの年齢とつきあい歴ですから、二人になった時のハーモニーは落ち着きと新鮮な感覚が同居しています。 男は、どうも友人と一緒に５〜６人で会社を経営しているように見える。お金をかけた、という印象でなく、いかにも小ざっぱりとした身なりから、どうもそうらしい。デザイン会社だろうか。雑誌社だろうか。それとも、数年前まで勤めていた商社を退社して、自分で貿易会社を設立したのだろうか。いずれにしても小規模な会社のオーナー。一般的なサラリーマンとはいえないサラリーマンふうである。ことさら経営感覚に鋭いわけでもなく、趣味人間ともいえない。若
要件定義の定義 (mark-wada blog)
悲喜子さんのブログで「要件定義に関するモヤモヤまとめ」というエントリーがありました。そのモヤモヤが、「要件定義は業務知識がないとできない？」というのと、「お客様自身は、本当に必要なものを気づけない？」です。このモヤモヤはよく分かるし、いろいろな議論があると思います。 ただ、｢要件定義｣（要求定義でもいいのだが）といった場合、それが何を意味しているのかをはっきりさせておかなければいけない。「要件」とは文字通り“必要な条件”のことだが、では“誰が必要としている”ことなのか、あるいは“どうしたいから条件を決めなくてはいけないのか”ということです。 ここの定義でぜんぜん変わってしまいます。すなわち、ユーザ側のもつ要件なのか、システム側の要件なのかです。それによって、条件も違ったものになります。 例えば、ユーザ側の要件であれば、ビジネス上あるいは業務遂行上でこんなことをしたい、あんなことができたらと
要求定義と要件定義
情報システムを開発する際にはいろいろな課題、問題等が発生します。そんな時、どんな風に考えて、行動したら良いかなんてことの参考になればいいなということを書きたいと思います。いわば、システム開発を成功させるためのセカンドオピニオンを提示したいと思っております。 要求定義と要件定義の違いは何かと時々質問されます。で、実際それは何でしょう。 ほとんどの方は、ほぼ同じ意味で使っています。でも実際には、次のような違いがあると認識するのが適切ではないかと私は考えています。 要求：「～したい」と表せるもの要件：「～でなければならない」または「～である必要がある」と表せるもの という区分です。要求定義は、「画面から氏名を入力したい」と画面を定義づけるもので、要件定義は、「画面には氏名の入力欄がなければならない」となります。要求定義は利用者側の希望、要件定義はシステムの仕様書なのです。 「何だ同じじゃないか」
技術メモ [それはBooks]
技術メモ用のエントリ 技術者の宝石箱の続きエントリ インデックス DOM で複数選択可能なリストボックスを作成する（IE） 2007/4/28追加 要求と要件の違い 2007/5/22追加 Maven2のpom.xmlのXMLスキーマ 2007/10/23追加 Excelでファイルの最終更新日を取得する 2007/10/24追加 Ruby on Rails2.0で、NoMethodError in AdminController#index 2007/12/30追加 WebLogicでAPP-INFを使って共通Jarを配置するときは、ClassLoaderに注意する 2008/5/27追加 WebLogicが発行するSession Cookieのパスはデフォルトで / （スラッシュ） 2008/6/19追加 FFFTPでシンボリックリンクを削除する方法 2008/6/24追加 Railsを
上流の技術者はSQLを高いレベルで習得すべき：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 まともな議論になっています。炎上というのはコメントをつけてくれた方々に失礼かもしれませんが、何回も炎上してきたし、何回も同じことを書いてきたし、それどころか10年言い続けてるし……。 がしかし、この業界のお客様から、このようにご意見を頂戴した（わたしが猛烈に望んでいたコメントなんですけど自作自演じゃないからね）。 http://el.jibun.atmarkit.co.jp/g1sys/2009/06/vb6-8111.html#comment-24715757 そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。 その前に余談ですが、VB6と.NET（とSQL）について。 どっかでコメントしまし
システム企画に役立つ概念データモデル作成の基本
概念データモデルの構成要素 概念データモデルは、システム化対象範囲にある業務プロセスをモデル化したもので、これを見ただけで企業のビジネス活動が分かるという大きなメリットがあります。図1の販売活動に焦点をあてた概念データモデルを例に、この企業の販売活動を読み解いてみましょう。 概念データモデルは「ハイレベルエンティティ」（図1緑色枠）、「識別子」（図1青色枠）、「リレーションシップ」（図1赤色枠）の3つから構成されます。 エンティティとそれを捕捉する識別子 まず、概念データモデルは企画段階で作成するものであるため、システム化対象範囲にあるデータ群を簡易的なレベルで表します。このデータ群が「ハイレベルエンティティ」（本稿ではエンティティと略記します）です。 これらエンティティを顧客コードや商品番号のような「ｘｘコード」、「ｘｘ番号」という「識別子」から捕捉します。 イベント系エンティティ、リソ
いまさら聞けない要求管理の基本
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
ソフトウェア開発の革命
前回（第4回 アジャイル開発と反復開発の落とし穴）は、ウォーターフォール開発に代わるべく登場した、反復開発（*1）やアジャイル開発の問題点、課題、そして落とし穴についてお話しした。最終回は、ここまで説明してきた問題について、IT企業やITエンジニアたちがどう立ち向かうべきなのか、自分なりの考えを述べることとする。 ユーザー企業とIT企業の不幸な関係 ユーザー企業の求める真の要求は、業務要求がその根拠となる。業務をどのようにデザインするかでシステム要求が決まり、また、システムをどのように活用するかによって、業務に新しいイノベーションを起こせる。業務とシステムの有機的な結びつきが企業の業績に大きな影響を及ぼすのである。しかし、現状は、業務とシステムが分断されたままである。 ユーザー企業とIT企業の契約の仕方を観察すれば、業務とシステムの不幸な分断状況を俯瞰できる。 通常、ユーザー企業はIT企業
非機能要求
1 はじめに システム開発における要求分析モデルとして、ユースケースを中心に説明してきました。 ユースケースはユーザの目的をモデル化したモデル要素であり、システムがユーザに提供する機能を表現するという意味で機能要求のモデルといえます。第1回では、図1[営業社員のシステム・ユースケース]に示すユースケースを用いた要求モデルを作成しましたが、これは機能要求ということになります。 しかし、要求仕様は機能要求だけで構成されるわけではありません。実際のシステム開発では「ユーザの目的」とは別の観点でさまざまな要求を定める必要があります。このような機能外の要求のことを非機能要求と呼びます。 今回は、この非機能要求について説明します。 2 ISO/IEC 9126(JIS X 0129) 非機能要求を考える上では、システムの品質という切り口が重要です。 ISO/IEC 9126は、ソフトウェア開発における
開発の初めから順番に書いていってみる その１５：要求分析（１）要求仕様書 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） シリーズ「開発の初めから順番に書いていってみる」の続きです。 前回までで、立ち上げの成果物にあたる「プロジェクト計画書」について書き、その中で、スケジュールの元となるアクティビティは、開発標準に基づくことを書きました。 で、開発標準は、各社各様ありますが、初めに、要求分析が来るっていうことは書きました。つまり、次にやることは、要求分析です。 ということで、今回は要求分析についてです。 ■要求分析とは これからシステム開発を行うにあたり、何をつくるのかを定義することです。 何の部分が、要求に当たります。 この要求には２種類あります。 １種類は、システムっていうのは、情報処理、すなわち、何かのデータを入力し、処理を行い、出力を出すことです。 この入出力(データ）と、処理＝業務について
IPAX 2009～日本の元気を、ITで！ (mark-wada blog)
一昨日、IPA（情報処理推進機構）主催の標記のイベントがあったので出かける。当初インフルエンザの影響で来場者はマスク着用とのことで、もし持参していなかった場合は入場をお断りする場合もありますというお達し。ところが、会場ではマスク姿もまばらで、まあそんなものだろう。 一昨日のお目当ては、特別講演「「信頼性に関わる実証的な試みの提言～重要インフラ情報システム信頼性研究会報告書から～」とパネルディスカッション「要求プロセスの実践と追跡性」である。 前者の特別講演は、東京大学大学院の中尾 政之教授による失敗学の話である。この人のことは以前「失敗は予測できる」（光文社新書）という本について書いているので、実際にお話を聞けるということで期待していた。 演題のポイントは、機械のようなハード的な失敗とソフトウエアの世界のものとの比較あるいは応用についてであったが、ぜんぜん違うという話である。 何が違うかと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SYSTEMSGUILD.COM
要求仕様の美学 | IT Leaders
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
パスワード認証
パスワード認証
要求工学なんでも相談室 - 要求工学コミュニティサイト
ビジネス要求の急激な変化に対応する開発プロセスとは？
