第1回 要件定義作業を容易にするシステム化企画書の意義 | IT Leaders
「ユーザー企業が必要としているシステムはどのようなものか」を定義する要求仕様書。実際に作成する上では、まずはきちんとしたシステム化企画書をまとめることが肝要となる。システムに求める機能はUML（統一モデリング言語）で定めるユースケース図を用いると分かりやすい。 要求仕様を取り巻く議論が活発だ。書店には要求仕様を冠とする書籍が立ち並ぶ。どれを手に取ってもなるほどという内容だが、これらの本に1つだけ欠けているものがある。それは、要求仕様を書く側の技術力について言及されていないことだ。 それだから本を読めば要求仕様書が書けると勘違いしてしまう。要求仕様書を書くには深い業務知識と経験が必要である。さらにITについても造詣が求められる。ことはそう簡単ではない。 しかしながら要求を仕様化する方法や手段は「要求仕様技術」として少しずつ確立されつつある。技術であれば習得することができる。 この連載では、シ
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
L'eclat des jours(2008-11-12)
_ なぜなぜ仕様 要件定義−基本設計−詳細設計（または直接実装）というような、段階別のシステム設計を考える。 たとえば、数10年前にこんな要件があったとする。 ・プリペイドカードの導入効果を知りたいのでプリペイドカードでの売上合計を簡単に知りたいね というわけで、プリペイドカードを利用した売上を調べられるようにしたとしよう。 それから幾星霜、システムの更改時期がやって来る。 基本は単純移行＋最新鋭のいろいろ と決まる。 その時に、現行のプログラムを眺めながら、当時の基本設計も参照しながら、移行プランを練ったり、移行プログラムの仕様を切ったり実装したりすることになる。 そこで誰かが気づく。この「プリペイドカード売上レポート」とか「プリペイド売上計上サブシステム」ってなんだ？ 「はて？」 そこで相談することになる。「これ、使ってるのか？」 こういうとき、お客さんと相談するのはあまりうまくない。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
