機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
ダメシステムでいいじゃないか
日経コンピュータ2008年8月1日号で「ダメシステムでも使わせたら勝ち」という特集を書いた。ダメシステムという言葉は，仕様面や品質面に何らかの欠陥があるシステムという意味で使った。こういう言葉をタイトルに据えるのは，がんばってシステム構築されている方々に失礼ではないかとも考え，一度は取り下げようと思ったが，結局採用した。誤解を恐れずに言えば，今作られている情報システムはおしなべてダメシステムと言える，と思ったからだ。 考えてみてほしい。仕様面で完ぺきを目指すのはどんどん難しくなってきている。システムに会計処理しかさせていなかった大昔ならいざ知らず，今は事業の最前線でシステムを使うのが当たり前。受注が確定する前の見積もりや引き合いなども管理する。そんな領域は非定型業務だらけでシステム化しにくく，どうがんばって作っても，ユーザーから「使いにくい」と言われてしまう。 品質面でいえば，バグがないシ
上流工程-要件定義---目次：ITpro
NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19
【考察】要求と品質の関係性 - プログラマの思索
「成功する要求仕様 失敗する要求仕様」を興味深く読んでいくうちに、「要求と品質の間にはどんな関係性があるのか？」が疑問として上がってきた。 要求と品質について考察してみる。 【要求エラーの種類】 「成功する要求仕様 失敗する要求仕様」では、いわゆる要件定義のプロセスを要求マネジメントと呼び、その重要性を強調している。 成功したプロジェクトでは開発コストの10～20%、失敗したプロジェクトでは5%以下という統計があるらしい。 「成功する要求仕様 失敗する要求仕様」では、要求マネジメントを下記のプロセスと定義している。 但しシーケンシャルとは限らない。 1.要求の導き出し ↓ 2.要求のトリアージ ↓ 3.要求の仕様化 そして、要求マネジメントで発生する要求エラーを下記として定義している。 【A】認識エラー 要求の導き出しプロセスで発生する「要求として認識されなかった」エラー。 いわゆる要求漏
作るシステムより人に着目－－読売新聞東京本社ほか
唯一、論文形式で受賞したのが、読売新聞東京本社を代表とする「ユーザー要求を引き出す分析手法の研究」だ。近年、大きな課題になっているシステム構築の上流工程であるユーザー要求段階で、どうやって真のニーズを引き出すかというテーマ性と実現性のバランスが評価された。 「ユーザー要求を引き出す分析手法の研究」は、富士通のユーザー会であるFUJITSUファミリ会LS研究委員会分科会が、1年をかけた研究をまとめた論文だ。読売新聞東京本社制作局技術一部の武田臣司主任をリーダーに、15社15人が参加し、06年3月に発表した。 論文のテーマは、システム構築の上流工程である要求定義をいかに確かなものにするか。システム構築の成否は、上流工程、なかでもユーザー要求をどう定義するかにかかっているとされる。ベンダーへの“丸投げ”体質を改め、本当に必要なシステムを作るために、多くのユーザー企業が要求定義力の強化に乗り出して
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
ITアーキテクトとして最も面白く感じること
システム開発は，「ナイスショットを連発する」ことではなく，「ミスを最小限に食い止める」ことが大事です。では，どうすればミスを最小限に食い止めることができるのでしょうか。また，そこにおいて，ITアーキテクトの果たす役割とはどのようなものでしょうか。筆者なりの考えをまとめたいと思います。 複雑さがミスを生み出す 考える材料として，「ITシステム」を取り上げます。ITシステムを単純にとらえれば，入力された情報を加工した後で出力します。こうとらえると，システム開発という作業も同じようなものといえるでしょう。入力に当たるのは，顧客が考える“欲しいシステム”。それをプログラミングという加工を施し，実際に稼働するシステムという出力を作ります。 ただ，システム開発とITシステムでは，入力・加工・出力の複雑さに大きな違いがあります。ITシステムは，決められた入力情報を決められたルールで加工し，決められた出力
【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む----積水化学の寺嶋氏がベンダーに苦言
「今のITベンダーはプログラミングを軽視しすぎている。全員がプログラマでありSEでなければ企業が喜ぶシステムは作れない」。積水化学の寺嶋一郎コーポレート・情報システムグループ長（写真）は、11月27日に開催した「IT Service Forum 2007」の講演「ITベンダーに望むこと」で、ITベンダーにこう苦言を呈した。 「システム開発でどんな技術や開発手法を使うかはアーキテクトが決める。経験上、良いアーキテクトが設計すると、開発と運用のコストを段違いに削減できる。良いアーキテクトとは、業務とプログラミングをよく知っている技術者だ」と寺嶋グループ長は話す。だが、今は「プログラミングを知らないSEが“売らんかな”でツールやパッケージの導入を目的に設計し、オフショア開発などで業務の分からないプログラマが実装している」（同） この状況を改善する策として寺嶋グループ長は「内作型開発モデル」を提唱
SIで競合する大手ベンダー同士が「共同作業」。その理由とは
NTTデータ，富士通，日本電気，日立製作所，構造計画研究所，東芝ソリューションの6社が，2006年4月に設立した「実践的アプローチに基づく要求仕様の発注者ビュー検討会」が，2007年9月18日に最初の成果となる「発注者ビューガイドライン(画面編）」(以下画面編）を公開した。 同検討会は，発注者(ユーザー企業）側から見て分かりやすい設計書(外部設計フェーズの成果物）を書くための工夫や留意点をまとめたガイドラインを作成・公開するのが目的。9月には，新たに日本ユニシス，沖電気工業，TISの3社が加わった。 第1弾の画面編は，画面に関する外部設計書(画面一覧，画面遷移，画面レイアウト，共通ルール，入出力項目，アクション明細，成果物間の関連）の書き方のコツやサンプル，注意点のチェックリスト，発注者と開発者の間で行うレビューの考え方やコツなどを，かなり詳細に記述している(PDFで293ページにも及ぶ）
[設計編]ユースケースに詳細を書いてはいけない
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
ソフトウエア規模の単位は何にする？
今回は規模見積もりの単位の話をしましょう。「このプロジェクトは何人月」とか「何億円規模のプロジェクト」といったプロジェクトの規模ではありません。これから開発しようというソフトウエアのサイズの話題です。 皆さんが規模見積もりで最もお困りなのは，「規模の単位を何にするか」ではないでしょうか。規模の単位を選ぶのは簡単ではありません。なにせ相手は，形のない論理の集合であるソフトウエアだからです。 今まで，多くの単位が提唱されてきました。ステップ数（LOC：Lines Of Code）や画面/帳票数，ドキュメント・ページ数がその代表です。ファンクション・ポイント（FP）数，ユースケース・ポイント数といった論理的に考案されたものもあります。これら複数の単位を組み合わせて見積もる人もいるでしょう。それ自体はよいことですが，軸になる単位は一つに決めておくべきだと思います。見積もり精度を高めるには，実績値や
要求工学の概要（要求工学：第1回）
概 要 要求工学はソフトウェア開発における要求仕様化プロセスを工学的に定式化する技術として注目を集めている。今年は第12回の要求工学国際会議（International Conference on Requirements Engineering,ICRE）が日本の京都で９月６日から11日まで立命館大学の衣笠キャンパスで開催される[１]。本稿では、要求工学の概要と要求工学の本質的な要素を明らかにするとともに、要求工学の価値について述べる。最後に要求工学の課題を紹介する。 要求工学の必要性 要求工学（ Requirements Engineering）は新しい技術ではなく1970年代から議論されている。ソフトウェア危機が1960年代に認識されたときに、ソフトウェア開発プロジェクトが失敗する主要な原因が要求の欠陥にあると報告されている[２]。 開発したソフトウェアが納入され変更することなく使わ
「要求工学」のエッセンスを吸収する
読者の皆さんは，ソフトウエア工学（ソフトウエア・エンジニアリング）をご存じだろうか。これは，ソフトウエア開発に関する先人の知恵と研究者の研究結果，言い換えれば「ベストプラクティス」を体系的にまとめたものである。 「要求工学」注1）は，このソフトウエア工学を構成する重要な領域の1つだ。実際，ソフトウエア工学としてどんな領域があるのかを米IEEE Computer Societyがまとめた「SWEBOK」（Guide to the Software Engineering Body of Knowledge）注2）でも，序章に続く第2章で要求工学を取り上げている。 もっとも，要求工学はまだ発展途上であり，PMBOKなどのように全体がきれいに体系化されているわけではない。様々な研究者やエンジニアが日々新たな考えを示したり，良いプラクティスを紹介したりしている状態で，用語の統一もまだ不完全だ。つま
業務システムにおける要件定義からのデータ分析
要件定義におけるデータ設計は、一般的にその工程内のタスクとして存在することはありません。それは、データ分析の結果は論理テーブルのスキーマ定義だけではなく、「作るべきシステム」の基本設計のすべてに反映されることになるからです。したがって、データ設計だけを抽出してこのコラムで紹介していくのは、大変難しいため、今回は業務分析内で特にデータ分析が関わるポイントについて述べていきたいと思います。 また、当然ですがこのコラムの内容は、システムにリレーショナルデータベースが存在することが前提です。 ○ トップダウンアプローチとボトムアップアプローチ 業務分析でのデータ分析は、トップダウンアプローチで業務エンティティを抽出することから始まります。多くのシステムでは、要件定義の段階で属性項目が洗い出されていることはあまりないため、ボトムアップアプローチによる、関係(リレーション)の抽出からのテーブル定義につ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ロングテール時代のSI
http://d.hatena.ne.jp/habuakihiro/20071128
はてなブログ | 無料ブログを作成しよう
http://d.hatena.ne.jp/habuakihiro/20050414
NAIST 情報科学研究科 ソフトウェア工学講座 - 要求工学
要求工学:Requirements Engineering(月刊ビジネスコミュニケーション)