要件定義について別トピで議論になったので立てます。このトピのテーマは要件定義の正体を明らかにする事です。
次の観点でコメントしてもらえると嬉しいです。
１）要件定義の意味、目的は何か。
２）成果物にはどの様な文書があるのか。
３）要求定義との違いは何か。
４）外部設計（基本設計）との違いは何か。
５）ヒアリングでSIerとクライアントが知らなければならないポイントは何か。
６）レビューでSIerとクライアントが知らなければならないポイントは何か。
７）文書作成でSIerが知らなければならないポイントは何か。
８）要件定義において発生しがちなトラブルとは何か。また其の解決はどの様にすれば良いのか。
９）その他。
出来るだけ番号を添えてコメントしてください。
次の観点でコメントしてもらえると嬉しいです。
１）要件定義の意味、目的は何か。
２）成果物にはどの様な文書があるのか。
３）要求定義との違いは何か。
４）外部設計（基本設計）との違いは何か。
５）ヒアリングでSIerとクライアントが知らなければならないポイントは何か。
６）レビューでSIerとクライアントが知らなければならないポイントは何か。
７）文書作成でSIerが知らなければならないポイントは何か。
８）要件定義において発生しがちなトラブルとは何か。また其の解決はどの様にすれば良いのか。
９）その他。
出来るだけ番号を添えてコメントしてください。
|
|
|
|
コメント(184)
SIerに基本設計以下を投げると同時に、私の方で要件定義で作った画面デザイン＆機能一覧を元に運用（受入）テスト仕様書を作り始めます。
要件定義の前に業務分析＆業務フローの作成は終わっているので、「この部署のこの担当者（権限）の人が使う場合」などパターン分けしてテストデータを考え、タブレットでパワポに載せた画面デザインを開いて、エア入力テストしながらテスト仕様書を作っていくと…
そこで設計漏れを発見するので、SIerと共有しています。だから、製造を始める前…設計段階でテスト仕様書を考えるようにしています。
要件定義の機能一覧 → 運用（受入）テスト
基本設計書の機能一覧 → システムテスト
外部＆内部設計書の機能一覧 → 結合テスト
でもSIerさんは、システムテストを「結合テスト」と呼んでいて、本当に結合テストレベルのテストしかやっていませんでした（涙）
※ここでも「結合テスト」のイメージが千差万別のようですね。
私の場合は、プログラムとプログラムの結合を見るのが結合テストで、複数プログラムを含むシステムとシステムの結合を見るのがシステムテストです。
要件定義の前に業務分析＆業務フローの作成は終わっているので、「この部署のこの担当者（権限）の人が使う場合」などパターン分けしてテストデータを考え、タブレットでパワポに載せた画面デザインを開いて、エア入力テストしながらテスト仕様書を作っていくと…
そこで設計漏れを発見するので、SIerと共有しています。だから、製造を始める前…設計段階でテスト仕様書を考えるようにしています。
要件定義の機能一覧 → 運用（受入）テスト
基本設計書の機能一覧 → システムテスト
外部＆内部設計書の機能一覧 → 結合テスト
でもSIerさんは、システムテストを「結合テスト」と呼んでいて、本当に結合テストレベルのテストしかやっていませんでした（涙）
※ここでも「結合テスト」のイメージが千差万別のようですね。
私の場合は、プログラムとプログラムの結合を見るのが結合テストで、複数プログラムを含むシステムとシステムの結合を見るのがシステムテストです。
新規システムをゼロから作ることはあっても、全社システムリプレースどころか情シスを作り直しという機会は最初で最後だと思うので、凄く楽しい。
ユーザー系子会社や大規模SIerでは当たり前のように標準化されているものは、エライ人々が若かった頃に同じように苦労して作り上げたものなんだろうな〜と思ってます。
今のスタートの段階で仕事をもらえれば、今後構築されていく全システムの仕事に関われるので、SIer間で火花が散ってます。
私の案件担当のSIerさん、最初からPLではなくPMを出して完璧に要件定義〜システムテストをこなしてくれれば、今後の案件もプライムになれたのに。ご存じの通り私が「あのSIerはダメ」と上司に言ったせいで、彼らは他の案件は全てアンダーに。
プライムはプライムで「全てうちで内製化する！」とアンダーに全く情報を共有しないので、PLに代わって頑張っているPMが気の毒になって私から情報を流したり、私の次の案件では要件定義からやってもらったりと、リベンジの機会を提供しています。
トピのテーマに話を戻すと…
利用部門とのヒアリングにSIerを同席させるのは、ヒアリング力&要件定義力を見て「この人が担当なら、この会社をプライムにしてもいいか」と評価するためなんです。上司はプライム、私はアンダーを評価中。…なんて恐ろしい！(笑)
ユーザー系子会社や大規模SIerでは当たり前のように標準化されているものは、エライ人々が若かった頃に同じように苦労して作り上げたものなんだろうな〜と思ってます。
今のスタートの段階で仕事をもらえれば、今後構築されていく全システムの仕事に関われるので、SIer間で火花が散ってます。
私の案件担当のSIerさん、最初からPLではなくPMを出して完璧に要件定義〜システムテストをこなしてくれれば、今後の案件もプライムになれたのに。ご存じの通り私が「あのSIerはダメ」と上司に言ったせいで、彼らは他の案件は全てアンダーに。
プライムはプライムで「全てうちで内製化する！」とアンダーに全く情報を共有しないので、PLに代わって頑張っているPMが気の毒になって私から情報を流したり、私の次の案件では要件定義からやってもらったりと、リベンジの機会を提供しています。
トピのテーマに話を戻すと…
利用部門とのヒアリングにSIerを同席させるのは、ヒアリング力&要件定義力を見て「この人が担当なら、この会社をプライムにしてもいいか」と評価するためなんです。上司はプライム、私はアンダーを評価中。…なんて恐ろしい！(笑)
>ユーザー系子会社や大規模SIerでは当たり前のように標準化されているものは、エライ人々が若かった頃に同じように苦労して作り上げたものなんだろうな〜と思ってます。
そのエライ人々が若かった頃作り上げたものなら、使い物にはならないだろうね。
オブジェクト指向開発ならUPとかXP、SCRUMが有名だがUPがいいんじゃないかなぁ。どれも公開されているからただで手に入る。
オブジェクト指向開発以外の開発標準で有名な奴だと富士通のSDEMってのがある。是も本になっているしサイトでも公開されている。
おれが君の立場なら、先ずはメジャーな是等の開発標準を調べ、次に其れを如何にカスタマイズすれば自社に最適な標準ができるかを検討するね。其の過程で必ず「所でうちの会社はどういうビジネスドメインやソリューションドメインがあるのだろう」と疑問がでる。其処で過去にどんなシステム化して来たかを調べると、ソリューションパターンと云うのがあると分かってくる。
そしたらうちの会社のソリューションパターンを纏めてコンポーネントライブラリを作り、其れをフレームワークにする。
それって…流行りのITアセットマネジメントじゃないか！
妄想は膨らむよね（笑
そのエライ人々が若かった頃作り上げたものなら、使い物にはならないだろうね。
オブジェクト指向開発ならUPとかXP、SCRUMが有名だがUPがいいんじゃないかなぁ。どれも公開されているからただで手に入る。
オブジェクト指向開発以外の開発標準で有名な奴だと富士通のSDEMってのがある。是も本になっているしサイトでも公開されている。
おれが君の立場なら、先ずはメジャーな是等の開発標準を調べ、次に其れを如何にカスタマイズすれば自社に最適な標準ができるかを検討するね。其の過程で必ず「所でうちの会社はどういうビジネスドメインやソリューションドメインがあるのだろう」と疑問がでる。其処で過去にどんなシステム化して来たかを調べると、ソリューションパターンと云うのがあると分かってくる。
そしたらうちの会社のソリューションパターンを纏めてコンポーネントライブラリを作り、其れをフレームワークにする。
それって…流行りのITアセットマネジメントじゃないか！
妄想は膨らむよね（笑
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
