＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
要求定義/基本設計/詳細設計の範囲
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-06-22 13:21
業務アプリとツールや組み込み系ではかなりちがうし、流行のＵＭＬと
なるとまた違うのでしょうけど．．． 業務アプリの場合、 ■要件定義 ・業務要件：現状、新業務フロー等 ・システム要件：インフラ系を中心にネットワークやプロダクト等 ・セキュリティー要件：セキュリティに関しての要求事項等 ・機能要件：大まかな機能や、「これを実現して欲しい」等の要求 ・運用要件：運用まわり、バックアップ、容量見積等 ・その他：ケースバイケースで他に何かあれば ※昔はレスポンス要件等もあったんですが、ＷＥＢ等は保証できないですからねぇ ■基本設計 ・システム設計：インフラ、ネットワーク、機器構成、プロダクト構成等 ・画面設計：デザイン、項目定義等 ・ＤＢ設計：論理／物理設計、ＥＲ図等 ・処理設計：ＤＦＤ、ＩＰＯ、ＵＲＵＤ、コード設計等 ・業務・運用設計：サービススケジュール、バックアップ、リカバリー方法 新業務フローの詳細等 ・テスト設計：テスト方法、ツール等の設計 ・その他：補足資料他 ってこんなもんでしょうか？ 基本的には、要件定義と基本設計って大まかなタイトルだけあげると同じような ことなんですが、内容がちょっと違うということでしょうかね。 要件定義は概ね「（求める）結果」が中心ですが、基本設計は「方法」が中心 になっているということで．．． | ||||||||
|
投稿日時: 2005-06-22 14:29
かなり網羅されている感じですね。->Beatleさん
組み込み系だとハードウェア要件とかが追加されるのでしょうか。 この場合も、基本設計と詳細設計という切り分けはしない感じでしょうか。 詳細設計はリバースエンジニアリングツールで出力するだけとかが多いのかな？ ちなみに、要求定義と基本設計って、フェーズは分かれてます？ 要求定義を掘り起こしつつ、平行して基本設計って感じですか？ たとえば基本設計のレビューを行ったときに、 「この画面って何に使うの？」という質問とか、 「ここの動きはこうして欲しい」という要求が出たとして、 その対応は要求定義（仕様固め）と基本設計とどちらに属するのでしょう。 担当するのが同一チームの場合は、あまり気にならないのかもしれないですね。 | ||||||||
|
投稿日時: 2005-06-22 18:41
基本設計もある意味要求定義の一部だと思います。
細かい要求は基本設計に書いとけばいいと思います。 | ||||||||
|
投稿日時: 2005-06-23 09:20
規模や発注者側との関係によってケースバイケース的なところもあるの ですが．．． とりあえず、私がこれまでやってきたPJの標準としては、フェーズを完全に 分ける方が多いです。 フェーズを分ける理由としては、見積の関係とスケジューリングの関係が 最も大きい要因です。 要件定義書から、 ・見積レベルですべての要件を満足できるかを見積もる ・要員をどれくらい確保するかの最終決定 ・プロダクト製品やらハードウェアやらの候補選定（検証も入る場合有り） というような吟味があるので、ここでやっとプロジェクト計画書のような ものが出来上がるという場面ですので、要件定義終了と基本設計開始と いう間にはある程度日程の空き（検討、交渉等）を考慮してます。 もちろん最初から要件も環境もピシッと決められているような場合には 形だけの要件定義書になり、そのまま基本設計に進むこともありますけどね。 （基本設計からはじまることもあります。）
要求に関しては要件定義書に必ず必要でしょうね。ただ、画面そのものや 仕様詳細の要求については、要件定義書には「ここの動きはこのように」 というようにイメージ的な表現で、「実現方法、処理方法等は基本設計書 にて記述する」のように補足を入れておきますね。 | ||||||||
|
投稿日時: 2005-12-01 10:43
はじめまして。セラフです。
もう半年近く放置されているスレッドですが、結局まとまっていない ようなので、意見を書かせていただきます。 このスレッドで発言されている内容を見ると、どこで区切るか？とい う作業に主眼がおかれており、なぜそれらが必要となるのか？が無視 されているように感じます。 それぞれの定義書、設計書がなぜ必要なのか？、誰がそれを必要とし ているのか？をきちんと整理すれば、どこで分けるべきかがおのずと 見えてきませんか？ [ 要件定義 ] ・誰が必要としているか 開発側 ・なぜ必要なのか 見積（工数）を作成するため。 お客様の要求を視覚化し、共有するため。 [ 基本設計 ] ・誰が必要としているか お客様 ・なぜ必要なのか 要求が反映されたシステムになっているか確認するため。 [ 詳細設計 ] ・誰が必要としているか 開発側 ・なぜ必要なのか システムの詳細な動作を機能の製作者に伝えるため。 私の場合は上記のような感じですが、どうですか？ わかれてきませんか？ | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.