要件定義
テンプレートは以下からダウンロード可能http://k-method.jp/temp/temp.htmlこのテンプレートはこの手法にそって予めパッケージが用意されており、そのパッケージに従ってモデルを作成していくことで要件定義用のモデルを整理出来るようにしたものである。特…
この夏休みを利用して要件定義検証ツールを何とかまとめ上げた。まだバグも残っていると思うが一応の機能は実装した。このツールは「かんざきメソッド」【RDRA】リレーションシップ駆動要件分析で作成したモデルの検証用ツールである。 「かんざきメソッド」…
今日やっと原稿があがった これから校正が入るが やっと一息付けるここ３ヶ月、ほとんど土日なしで原稿書きをしていたので このブログも滞ってしまった。内容は「リレーションシップ駆動要件分析（http://k-method.jp/）」を扱ったものである。私の２７年の…
２回に渡って設計書はいるのかという視点で書いてきたが 私は設計書はいらないと考えている。その代わりアーキテクチャ設計書やキーメカニズムの説明書は必須だと考えている。それと機能仕様（これも議論の余地が沢山あるが...）があれば充分であると考えて…
前回（http://d.hatena.ne.jp/good_way/20080416/1208357141）のWhatとHowでは実装者に伝えている情報がまったく違います。Whatではやりたいことが伝わっていますので、テストは条件として示されていることが実現されているかをテストすればいいことになりま…
古くからプログラム仕様書、機能仕様書と呼ばれるものが、この設計書にあたる。プログラムのロジックに焦点をあて、プログラムの流れを模倣して書かれたものである。フローチャートなどはその代表例である。HIPO、PADなど現在はあまり使われなくなった書法も…
このケースはパッケージベンダーなどをイメージしているが、一番一般化して語るのが難しいものである。ここでの想定は要件定義者とその開発者が同じ会社であるという想定で述べる。この場合要件定義者と開発者の間には契約関係が存在しないので要件定義とし…
システムを開発する側の立場に立つと二つの側面が要件定義書に求められる。 ・見積もり可能な情報があること ・実現する機能範囲が明確になること■見積もり可能な情報があること 見積もりを作成するにあたっては戦略的な価格設定、もしくは内部工数を積み上…
A.システム開発を発注する立場（ユーザ企業など）この場合システム開発を発注する立場から、見積もり可能な内容が記述されたものがユーザ企業にとっての要件定義と考えることができる。これは正式な発注まではユーザ企業主導の要件定義で、SIerなどのシステ…
先(http://d.hatena.ne.jp/good_way/20080221/1203601549)に見てきたように要件定義は様々な目的で使われる。その各々のプロジェクトにおいて最適な要件定義となるためには次のような考え方がある。「要件定義書をもとに要件を説明でき、聞き手がそれを理解…
要件定義は大きく分けて３つの立場から使われる。 A.システム開発を発注する立場 大手ユーザ企業など B.システム開発を受注する立場 SIerなど C.上記両方の立場を併せ持つ パッケージベンダーなどこの３社の各々の立場で要件定義の内容は微妙に変わる。（A）…
昨年の夏からコツコツとまとめていた要件分析の資料「リレーションシップ駆動要件分析」がまとまった。また、それに合わせて専用サイト（http://www.rdra.jpn.org）も準備ができた。モデルを使った要件定義に興味のある方は是非一度目を通して頂けると幸いで…
通常システム開発後のドキュメントと言えば設計書が一般的ですが、その設計書はキングファイル数冊分になるのが普通です。それはそれで保守の時に使用できますが、大手ユーザ企業のシステム部門は、実際に保守作業を自分たちで行うことはまれで、それらの設…
ユーザ企業のシステム部門の役割はその会社のビジネスをＩＴの技術を使って支援することです。 もしくはもっと積極的にＩＴを使ってビジネスを成功させることです。 ユーザ部門と一緒にビジネスにＩＴをどのように使用するか検討する必要があります。 ユーザ…
大手のユーザ企業の場合は継続的にシステム開発案件があります。そして、システム部門はシステム保守や開発などの現場作業は、パートナー会社に委ねているのが一般的です。そのようなシステム部門においては、稼働しているソフトウェアだけではなく、要件定…
要件定義フェーズの成果物はそのままSIベンダーへの見積もり用の資料(RFPなど)になるのが普通です。 このことがまた要件定義の混乱のもとになります。発注者としてのユーザ企業の立場では予算取りがあるので「システム開発費を全額決めてしまいたい」という…
大手ユーザ企業での要件定義は、通常従来その会社が独自に行っていた方式を踏襲するか、もしくは担当者の経験の範囲で独自の方式で行っているのが普通だと思います。また、ユーザ企業のシステム部門で要件定義が難しい場合はSIベンダーがその要件定義から参…
要件定義をスムーズに進めるためにはいくつかの視点が必要がある。上流工程の作業というものは明確な達成点が無いことから、どうしてもスケジュールが延びてしまうことや、成果物の品質が担当者によってばらばらになってしまう傾向がある。これらをうまくコ…
要件定義においてAs-ISとToBeの資料がごちゃ混ぜになっているケースを多く見かける。現状調査などで業務フローをつくりそれをベースに新システムを考えることが多いが、そのAs-Isとして作製した業務フローがいつしかTo-Beの業務フローとして認識されてしまう…
システム開発の上流工程において、よく以下のようなことが強調されている。 ・ゴールを明確にすることが大事だ。 ・システムのビジネス価値を明確にする必要がある。これは私もコンサルティングの場でよく口にするが、本当に重要なことはどこまでそれを突き…
要件定義や要求仕様などの上流工程について書かれた書籍は近年沢山出版されている。 その中で体系的に書かれている本は沢山あるが、具体的にどのようにどこまで書くかということに触れている本は少ない。システム開発には様々なものがあり、一概に言えないの…
要件の定義、要求の定義にはいまだに定まった方式は無い、要求管理ツールとして以下のようなシステムがある。 ・Telelogic：DOORS ・IBM Rational：RequisitePro ・Borland：CaliberRM ・スパークスシステムズ：RaQuestこれらのツールは要求そのものをだす事…
ユーザ企業においてシステムを構築する場合、そのシステムの要件定義はユーザ企業の情報システム部門でとりまとめるのが、本来の姿だが現状はなかなかそうなっていない。１０年以上前から大手ユーザ企業の情報部門は情報子会社として独立させた企業が多く。…
