要求定義/基本設計/詳細設計の範囲

投稿者

投稿内容

桜緋女: 常連さん; 会議室デビュー日: 2004/09/15; 投稿数: 46

投稿日時: 2005-06-20 22:48

お世話になります、さくらと申します。
最近基本設計に携わっているのですが、どこまでが基本設計だ？と改めて思う日々です。
要求定義は基本設計とは別ですよね？
入出力一覧は詳細設計ですが、基本設計で大体マッピングは決まってしまいますよね。
ごくまれなケースなのかどうか、製品が出来上がってから、
「この画面が業務上どんな役に立つのか考えて」と言われたことも。
私は基本設計は経験が浅いのですが、皆さん、基本設計の範疇はどこからどこまでだと思われますか？
ご意見をお聞かせください。

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2005-06-21 00:54

るぱんです。

個人的に考える基本設計は、
システム全体のINPUTとOUTPUTです。

関わる全てのINPUTとOUTPUT全部。

DBありなら、DBのエンティティ定義まで。
INPUTとOUTPUTレベルでユーザビリティまで考えてあれば
大体何とかなるんじゃないですか？

設計こそ実際に物を作らないから気に入らなければ１から組み立てなおすものと言う
認識です。

そこには試行錯誤しかないと思うんですけどね。

どうやら最近の設計は作ったら作ったでそれで終わりで試行錯誤の後が見られないのが多いですね。

客も試行錯誤を求めてるとは思えませんし。

あ、念のため、あくまで、個人的な主観です。

Anthyhime: ぬし; 会議室デビュー日: 2002/09/10; 投稿数: 437

投稿日時: 2005-06-21 07:49

通常顧客は基本設計ぐらいまでは見ますから、顧客にわかる範囲でお客さんが興味のある事項、契約に重要な事項、制約を私は基本設計としています。
ブラックボックスでいい部分は詳細設計にもっていってます。

桜緋女: 常連さん; 会議室デビュー日: 2004/09/15; 投稿数: 46

投稿日時: 2005-06-21 10:17

さくらです。
ご回答有難うございます。

>個人的に考える基本設計は、
>システム全体のINPUTとOUTPUTです。
>
>関わる全てのINPUTとOUTPUT全部。
>
>DBありなら、DBのエンティティ定義まで。
>INPUTとOUTPUTレベルでユーザビリティまで考えてあれば
>大体何とかなるんじゃないですか？

なるほど。
ユーザビリティまで基本設計に含めるというのは、新鮮な考え方です。
単純に詳細設計ドキュメントで作らないといけない項目に
DBマッピングを含めたコントロール一覧があるので、
入出力は詳細設計、くらいの意識でした。

>顧客にわかる範囲でお客さんが興味のある事項、
>契約に重要な事項、制約を私は基本設計としています。
>ブラックボックスでいい部分は詳細設計にもっていってます。

確かに、顧客がみるドキュメントを基本設計で、という側面もありますよね。
一方で、基本設計は中堅、詳細設計は設計初心者や
プロジェクトに関わったばかりの人間という割り振りも多いと感じます。
私が現在関わっているプロジェクトでも、
詳細設計は最近メンバに加わったばかりの協力会社のかたにお任せすることになっています。

そうすると、基本設計書には載せないけれども、
基本設計のうちに実は考えておかないといけない部分があって、
それを如何に詳細設計に橋渡しするか･･････というのが悩みどころです。

がるがる: ぬし; 会議室デビュー日: 2002/04/12; 投稿数: 873

投稿日時: 2005-06-21 10:23

どもです。がると申します。

最近、そーゆー設計の切り分けをあんまりしてないですねぇ。
自分の場合、
・要求定義
・設計
です。で、設計を色々と切り分けて、まぁ例えばCGI系の場合はおおむね
・画面遷移設計
・DB設計
・プログラム設計
・ネットワーク設計
あたりが必須で、あとはまた必要に応じて色々と設計書を重ねていきます。

で。要求定義と設計の差は簡単で。

要求定義は「素人であるお客様に見せることを前提にした文書」で、
内容は「何をしたいのか」という希望が書いてある。

設計は「技術者に見せることを前提にした文書」で内容は「技術的に
何をどのように実装していくのか」という手段が書いてある。

という差異です。

まぁどんな切り分けにしても、仕様書の類は「誰に見せるものなのか」を
意識するとわりと書きやすいと思います ^^

桜緋女: 常連さん; 会議室デビュー日: 2004/09/15; 投稿数: 46

投稿日時: 2005-06-21 11:18

実際、要求定義と基本設計ってどれくらいきっちり分かれてるんでしょうね？

目的は、がるがるさんの仰るとおりにきっちり分かれるんですけど、
フェーズやドキュメントってプロジェクトによっては混ざっちゃってますよね。

前にいたプロジェクトはかなりきっちり分かれていたんですけど、
今回はAnthyhimeさんの仰る、基本設計がお客さんにも見せるもの、
詳細設計は技術者のみが見るもの、というパターンです。

･･･そうすると、あとは如何に自分でフェーズやドキュメントの切り分け方から
関われるポジションに入り込むかの問題ですねー。

がるがる: ぬし; 会議室デビュー日: 2002/04/12; 投稿数: 873

投稿日時: 2005-06-21 11:35

どもでふ。がるです。

引用:
さくらさんの書き込み (2005-06-21 11:18) より: 実際、要求定義と基本設計ってどれくらいきっちり分かれてるんでしょうね？

でしねぇ。なので、おいらは「分けます」。意識的に。
実際、混ざりそうなプロジェクトは山のようにあるんですが、きっちりと
切り分けます。
ただまぁ「先方の慣習」とかってのとぶつかることも多々あるわけでして。
そういった場合
・名称は先方さんの慣習を大いに利用する
・中身はきっちりと切り分ける
で、相手の体面を保ちつつ実情を「改善」させます :-P

そうしないと「無駄なドキュメント」が増えるんですよねぇ。

桜緋女: 常連さん; 会議室デビュー日: 2004/09/15; 投稿数: 46

投稿日時: 2005-06-21 15:34

先方で、ですか。う～ん、尊敬します。
私は自社開発なので、そういう意味ではもうちょっと
やりやすいハズですね。

今回のプロジェクトは、中途退職者のピンチヒッターとして
一部設計はレビュー済みの時点からのアサインでしたので、
今回はお勉強と割り切ります。

次からはプロジェクト頭からきっちりフル参加して、
きっちり切り分けを行えるように頑張ります。

1|2 次のページへ»

要求定義/基本設計/詳細設計の範囲

スキルアップ／キャリアアップ（JOB@IT）