プロが教える店舗&オフィスのセキュリティ対策術

ある携帯を用いたシステム開発における仕様書を作ってくれと会社の上司から依頼されました。
当方、プログラム経験は少々ですがあります。
(といっても、MS-DOS時代のC、エクセルVBAでのツール作りくらいですが・・)
よって、具体的な仕様書をおこしたことはありません。

一口に仕様書といっても、システムの種類や内容などによって、いろいろあると思うのですが、何か具体的な仕様書フォームとかあれば、ぜひ欲しいです。
どういった項目が必要なのかがわからず、何から手をつけて良いかが、わからないもので・・

ちなみに、仕様書を作成する側(SEと呼ばれる立場?)は、開発する環境(使用するハードやソフト)、開発言語、使用するDB、開発するための規則なども細々と決めなければならない(仕様書に盛り込む必要がある)のでしょうか?

プログラミングは、外部のソフトベンダーに依頼するそうなのですが、そうなると仕様書がしっかり書かれていないとマズいような気がしています・・
しかし、どこまでのことを仕様書を作成する側がやらなければならないかも、ちょっとわからないんです。

また、仕様書を作成する業務=システム設計またはプログラム設計と考えてもよろしいのでしょうか?

A 回答 (5件)

仕様書と言っても色々な種類がありますが、プログラミングを外部に発注するための仕様書であれば、要求仕様書になると思います。


一般的には、なんのためのシステムか、入力データと出力データ、操作方法(GUI)、必要な機能、性能、保守、スケジュール、開発方法、言語、動作環境、耐障害性、データバックアップなどなど。
プログラムを作ってもらうための、必要な要件を記述すれば良いのです。要件を文章や図で記述するか、大変だったら、要件のみ箇条書きにすれば良いと思われます。
もしくは、発注先のSEとの会話で、上記の要件をヒアリングしてもらい、先方に要件定義書ということでまとめてもらうやりかたもあります。ただし、この工程の費用も請求されると思われます。
このプロセスがシステムを作る上で最も基本となる部分ですので、ここが正確に伝わっていないと、希望に添っていないシステムができあがり、トラブルの元となります。
ちなみに、要求仕様(要件定義)のあとに、システム設計、運用設計、プログラム設計、試験設計、導入(移行)設計などという形ですすんで生きます。このような進め方をウォーターフォールモデルといいます。
GUIがメインのシステムの場合(WebAPや業務APなど)、画面デザインや操作性などの決定に非常に時間がかかり、ウォーターフォールモデルは適用しにくいです。その場合はスパイラルモデルを適用します。プロトタイピング、RAPなどがそれにあたります。
なお、要件定義、システム開発プロジェクト管理などを自社でまかなえない場合、発注先に丸投げすることになり、非常にリスクが高くなります。そのため、発注先の立場として、外部にプロジェクト管理を委託するケースもあります。参考URLをどうぞ。

参考URL:http://www.geocities.jp/tk_yosh/index.html

この回答への補足

どうも、詳しくお答えいただき、ありがとうございます!
当方の状況からするに、まさに要求仕様書になるものと思われます。
当方にて、書籍についてもネットでいろいろ探し、早速、以下の書籍を注文してみました。
http://www.dart-books.co.jp/books/739-4.html
要求仕様書サンプルもついているらしいです。
役立ちそうですかね?

携帯(iアプリやおさいふ携帯機能)とWeb系コンテンツ(Flashなど)を連動させるようなシステムなので、GUI必須のシステムになるかと思います。
例)携帯をかざすと、PC画面のコンテンツが動作するなど。

ウォーターフォールモデル、スパイラルモデルなどの存在も、大変、勉強になりました。
プロトタイピングとは、簡単にアプリ画面などを実際に作ってみるということでよろしいのでしょうか?
ちなみに、RAPとは何でしょうか?

参考URLも後で見てみます。

補足日時:2005/02/26 17:02
    • good
    • 0
この回答へのお礼

一度、締め切りさせていただきたいと思います。
進めていくうちにまた疑問点が出てきたら、Qできればと思いますので機会あいましたら、よろしくお願い致します。
どうも皆様、ありがとうございました。

お礼日時:2005/03/08 16:20

えっと、余計なお世話かもしれませんが、一番心配なのはリスク管理です。


後工程での仕様変更や手戻り等発生しないようにする為には、SE側にはそれなりのノウハウが要求されます。
あとは、外注先を本当に技術力のあるところを選ぶのが大事です。
細かい事は任せてしまって良いです。技術的な面も相談しながら進められる相手を選んだ方が良いですね。

この回答への補足

外注先はすでに決まっているところがあるようです。
相談ベースで進めて行ければと思っています。
どうも、ご回答ありがとうございました。

補足日時:2005/03/08 16:15
    • good
    • 0
この回答へのお礼

一度、締め切りさせていただきたいと思います。
進めていくうちにまた疑問点が出てきたら、Qできればと思いますので機会あいましたら、よろしくお願い致します。
どうも皆様、ありがとうございました。

お礼日時:2005/03/08 16:19

仕様書を書くのは難しいですよ。


仕様書の善し悪しで、そのソフトの出来が決まる
のですから。(当たり前のことですが。)

仕様書を読んだこともないのに、仕様書が書けるかなー、
と、非常に心配です。

仕様書に書いてないことでも親切にプログラムを書いて
くれる人に出会えたらいいですね!

私はプログラマでもありますが、よくわかってない人の
書いた仕様書でプログラムを書くと、変更、変更で
プログラムがボロボロになったことがあります。
下手な仕様書は、無い方がマシだったりします。
(大ざっぱな仕様書にして細かいところはプログラマに
オマカセにする---しかし、これで満足できるかは、
プログラマ次第です。)

この回答への補足

仕様書は見たことはあります。
DBのフィールドの定義や入力デバイス図、システムの流れなど。
しかし、実際に作るとなると、どこから手をつけていいかがわからないので、参考になる元があれば、その形を自分用に変えながらできるかな(やってみたい)と思っています。
依頼客先と開発を頼む先の間に入るわけですから、口頭でしっかりとやり取りして、認識のズレがないようにはしたいと思っています。

補足日時:2005/02/27 21:04
    • good
    • 0
この回答へのお礼

一度、締め切りさせていただきたいと思います。
進めていくうちにまた疑問点が出てきたら、Qできればと思いますので機会あいましたら、よろしくお願い致します。
どうも皆様、ありがとうございました。

お礼日時:2005/03/08 16:19

No.1のzzenです。


GUIや、他システムとの連携が必要みたいですが、画面遷移や、データフロー、イベント(アクション)に応じた処理の内容、さらにユーザ入力があるのであれば、文字種や文字数の制限、数値の範囲など、さまざまなものを要求仕様としてまとめていかなければなりません。
お求めになられた本は参考になるとは思われますが、発注者としてそれらを押さえた上で、どこかに委託するのがベストかと思われます。
RUP(RAPは間違え)、RADなどをグーぐるとたくさんでてきます。

この回答への補足

どうも、ありがとうございました。
それらを踏まえた上で、頭を悩ませてみます。

補足日時:2005/02/27 20:58
    • good
    • 0
この回答へのお礼

一度、締め切りさせていただきたいと思います。
進めていくうちにまた疑問点が出てきたら、Qできればと思いますので機会あいましたら、よろしくお願い致します。
どうも皆様、ありがとうございました。

お礼日時:2005/03/08 16:19

見た感じ、SE経験のある方によく相談されたほうが良いと思います。


経験の浅い状態で要求仕様書や外注との交渉を行うのは、リスクが高いです。

この回答への補足

会社内では、SE経験は薄い人ばかりで、その中でも年齢的にも業界経験的にも、私しかやる人がいないんですよ。
上司もそれで、私に依頼してきたんだと思います。
SEとして働いていたことはありますが、運用管理SEだったので、システム開発SEとしての経験は薄いのは確かです。
自分でも力を付けたいので、今回、課せられたこの課題をクリアしたいと思っています。

補足日時:2005/02/27 20:52
    • good
    • 0
この回答へのお礼

一度、締め切りさせていただきたいと思います。
進めていくうちにまた疑問点が出てきたら、Qできればと思いますので機会あいましたら、よろしくお願い致します。
どうも皆様、ありがとうございました。

お礼日時:2005/03/08 16:20

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!