要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
第6回 提案力を高める要求開発のススメ
ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第6回は、第5回に引き続き提案について旅をしてみようと思います。次回は人間の活動における普遍的な成功パターンについて一般常識を超えて追求していきます。今回と次回の旅をするうちに、人間の内なる力を信じることの重要性が見えてくると思います。それでは今日も、常識の世界とは異なる不思議な思考の旅へ出発します。 僕の要求開発実践では、体験をそのまま形式知として手法化したり、手法化とまではいかないけれど図に起こしたりしながら、できるだけ形に残そうとしています。 言葉を発明する 手法化や図式化は、暗黙知を形式知に変える際の、とても重要なツールであると考えています。でもそれ以上に効果的な形式知への変換方法があります。それは、言葉を発明することです。 言葉を発明するというと大げさかもしれませんが、人は言葉によって気づき、動かされる
エンジニアがはまりやすい要件定義の失敗パターン
少し前のことだが，あるシステム・インテグレータの社内研修に1日だけ参加させてもらった。研修のテーマは要件定義。ユーザー企業の利用部門からヒアリングした業務上の問題や要望を分析し，解消すべき根本的な課題を見いだす要求分析の進め方を学ぶのが目的である。 その研修は，講義より演習が主体だった。素人の記者にはハードルが高かったが，無謀にも「ほかの方と同じように受講させてください」と頼み込んだ。要件定義の記事は何度か書いたことがあり，ちょっとした自信を持っていたのである。 演習の手始めに，架空の利用部門からヒアリングした結果という10数個の業務上の問題が題材として与えられ，他の参加者と同じく記者もその分類を試みた。「すべての問題をカバーする“巧みな分類”を考えなくては」と記者は思った。問題が起こっている場面や原因が共通する問題同士をくくり，「○○系」「××系」という具合に分類名を付けた。「これでなん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
