システムエンジニアの部屋コミュの要求仕様書の書き方についてのアドバイスをお願いします。

はじめまして
現在、ユーザーの代わりに要求仕様書を作成しているんですが
初めて書くため悪戦苦闘しながら書いているところです。

イロイロと勉強のために本を探してるんですが
オススメの本があればアドバイスをお願いします。

現在、読んでいる本はこんなんです。

『要求を仕様化する技術、表現する技術』技術評論社

要求と仕様の考え方はある程度参考になったのですが
いかに仕様をまとめるか？が、不明瞭と感じています。
どうやって仕様化すると良いか？
コレが書かれている本があるとうれしいです。
よろしくお願いします。

コメント(17)

最初
全て
最新の40件

[1] mixiユーザー 11月03日 21:21

当たり前のはなしですが、まずユーザーが何を要求しているのか、システムの存在理由をとことん明確にする事です。コミュニケーションをここでさぼると、後々厄介ですね。仕様書のアウトラインはそうやって固めましょう。形式はその次です。

[2] mixiユーザー 11月03日 21:27

形式だけであればどこかのサイトでダウンロードできたような(アドレスは失念)
ハムレットさんが書かれているようにユーザの要求を形にするのがRFPなので
ユーザの要求を聞き出すファシリテーションなどの技術も必要になりますね。

[3] mixiユーザー 11月03日 21:38

どうやって仕様化するか…
正解のない迷宮、な感じがします（汗）

敢えて言うとすれば、
利害関係者に徹底的にヒアリングをかけて
それを四苦八苦しながらでもつなぎ合わせていく作業というのが
要求仕様書の作成なんじゃないかと思います。

[4] mixiユーザー 11月04日 18:54

いっちゃんです。
まず処々の目的を明確化すること。
要求仕様においては、まず、以下の３点を念頭においてみてはいかがですか？
・当該システムのそもそもの目的は何で、
・稼動することによって何が達成させないといけないのか。
・費用対効果の観点から、現状、どうだから、システム化によ　ってどのようなコスト低減を図れるか

[6] mixiユーザー 11月05日 06:46

皆さん、アドバイスありがとうございます。
参考にさせてもらいます。

ワタシも、イロイロと調べてはいるのですが
やはり要件定義はこうだ！ってのはないようで
書いている本によって、内容はまちまちってのが多いようです。

ワインバーグ氏の本を読んでみたりもしてるのですが
なかなか難しいです

アドバイスして頂いた事を参考に
苦しみながら経験してレベルアップしていくよーにがんばります。
ありがとうございました。

[8] mixiユーザー 11月05日 18:28

本ではないのですが・・・。
私が意識していることは逆説的なものです。

「これがないと何が困るのか？」
ということを意識しています。

[9] mixiユーザー 11月10日 23:16

始めまして。
駆け出しのＳＥなのでまとはずれだったらごめんなさい。

要求仕様書、外部設計書、内部設計書、、、、etc
ＰＪやってくといろいろドキュメントが必要となってくると思いますが、僕の思うところ、お客さんとのキメなのではないでしょうか？

ドキュメントのレベルはＰＪによってばらばらだと思います。
なので、「要求仕様書をどのようなフォーマットで作りましょう。」という風に決めてみてはどうかと思います。

で、問題なのは内容になるかと思いますが。
そこは、最終的に作ることが目的だと思うので、
逆算というのもありなのかなと。
例えば、作るドキュメントが要求仕様書、外部設計書、内部設計書、プログラミング設計書とすれば、（現実的かどうかは別としてください。）

プログラムを書くためにはプログラミング設計書が必要なわけで、プログラミング設計書は読めばプログラムが書けるレベルに落とされている必要があります。
同様に、プログラミング設計書を書くためには内部設計書が必要で、内部設計書からプログラミング設計書が書けるレベルで記述されている必要があります。

って、考えていくと、要求定義って何が必要？ってのが見えてくるのではないでしょうか？

駄文・乱文・長文失礼しました。

[10] mixiユーザー 11月10日 23:39

RFP これは難解ですがこれをやらないと商談進まずといったところでしょう。

http://www.it-planning.jp/It110/faq143.htm

が概要項目で（あくまで参考ですけれど)

MS がテンプレートを出してるみたいです。（試してませんが)

http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2439

ご参考まで

[11] mixiユーザー 11月10日 23:39

いくさん：
はじめまして。

言い方はいろいろあるかもしれませんが、要求仕様書はきっとお客様向け、業務要件を纏める文書だと思います。
例えば、業務フローとか、システム構成概要とか

--------------------------------------------------------
フリーランスS&Cの部屋：
　http://www.busi-sate.net/

[13] mixiユーザー 11月12日 10:37

要求仕様書ってむずかしいですね。
なかなかうまく書けないと思います。

わたしが一番こころがけてることは「○○の処理は不要」とか「○○機能は対象外」という「やらない部分」をきっちり書く、ということです。そうするとレビューのとき、お客さんも真剣に読んでくれますし、あとで揉めたときに落としどころをつけやすいです。

参考になれば幸いです。

[14] mixiユーザー 11月12日 18:36

ユーザさんの変りに要求仕様書を書くということは
そのユーザさんがシステム化する業務の内容とその上流・下流
まで知っていて後で摺り合せをしないと、ユーザさんの求めて
いる内容（ITシステムは魔法ではないので）がシステムだけで実現できるか、納期・予算は自社で実現可能なものか
等をはっきり納得してもらい、かつ社内のコンセンサスを得て
いるかまで確認しておかないと後で大変なことになりますよ

システムで業務のどの部分を処理するか、その時にユーザ側の
作業はどうなるかを記述するのがユーザ側の要求仕様書だと思いますので

[16] mixiユーザー 11月13日 21:00

この手のドキュメントの書き方は，建前が多いので，本に書いてあることや，人のいうことは鵜呑みにせず，現物にあたってマネするのがいいですよ。

[17] mixiユーザー 11月13日 23:21

Doubleさんの意見だけを読むと上流工程の経験は少ないようですね。

要求定義の問題は、自分の仕事を改善するための要求定義を書くと良く理解できると思います。

要求定義では、分析対象が人の欲求である事を忘れてはなりません。人の要求は図式化し公開した瞬間に変わります。この変わる意味には、一旦承認された要求に固執する状態も含みます。これを理解せずにソフトウェア工学理論を全面に押し出し、図式化に重心を置いて作業をすると理解に苦しむ結果を生む恐れがあります。

また最近、要求工程のドキュメント技術が流行っていますが初心者であるならば机上の勉強としてとら現場に持ち込む事は避けて方が無難でしょう。道具は道具でしかなく道具を使える基礎能力が身につかない状態で適用する事は危険です。

まず最初に理解すべき事は、自分が世話になっている組織のやり方であり真似る事です。

ログインすると、残り4件のコメントが見れるよ