連載
ミスなくモレなく見やすい「要件定義書」の書き方：ユーザーの要件には「ウソ」がある？（2/3 ページ）
システム開発プロジェクトの成否を決めるといっても過言ではない「要件定義」。連載「エンジニアのためのビジネス文書作成術」、第2回目は「要件の洗い出し方」と、Wordの機能を駆使して「要件定義書」を見やすくするテクニックを伝授します。
「要件定義書」を作る理由
業務要件一覧とシステム要件一覧があれば、システム設計のインプットとなる要件はそろったといえます。これで要件定義の作業は完了でしょうか。
関連記事
開発工程でSEが書く文書の基本
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する
「要件定義書のアウトライン作成」完全マニュアル
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します
要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション
要件定義をスムーズにこなすためには作業に着手する前に綿密な計画を立てる必要がある
もしも要件定義の無いシステム開発の担当になったら
要件定義の無い開発の紛争は、双方の主観的な主張が入り乱れて泥仕合化することが多いようです。しかし双方が協力して要件さえ固めれば、仲直りも再開も可能です
もし要件定義担当者とベンダーが「グル」だったら？
悪意の有る無しにかかわらず、ベンダーと仲が良過ぎるユーザーが要件を担当すると、ベンダーにとってのみ都合の良い要件や、業務知識不足による要件不備を招く危険があります
Copyright © ITmedia, Inc. All Rights Reserved.