システム開発仕様書
対応範囲（スコープっていうのかな？）も確定させ、新システムの基本的な考え方の整理も終わり、いよいよ個別機能の仕様書を作成するフェイズに突入する訳です。
仕様設計の考え方っていろいろとあると思うのですが、私は、まず個別機能（画面や帳票など）で必要な処理をざくっと洗い出して、共通する部分を抽出し、それを共通処理として定義し、仕様を作成。
共通処理の仕様は、この時点でかなりしっかりと固めた上で、個別機能で必要な処理を、今度は真剣に考えて、個別仕様として作成。
個別仕様が完成したら、それをインプットとして、共通仕様を見直して、抜けが無いかをチェックするっていう考え方で作っていきます。
基本的にはボトムアップでのアプローチですが、最初にしっかりと考えすぎると、穴があった時の対応が却って面倒になるので、最初にサクッと作って、全体像を頭に描きながら詳細を詰めていきます。上って下って繰り返し～。
そして仕様書はExcel方眼紙
もともと、基幹システムを作ってもらったベンダーの仕様書がExcel方眼紙だったので、一貫性を保つために、同じ書式のExcel方眼紙を使う事にしました。
最近では、仕様書から自動的にソースを作ってくれるようなものもあるとは聞くのですが、自動ソース生成ってものに対する強い不信感があるので使いたくないんですよ。
．．．自分でソース書いた方が楽しいからって理由じゃないですよ？
まぁ、Excel方眼紙だと、専用ツールに比べて、図表が書きづらい、記述に一貫性が無い、あいまい過ぎる、くど過ぎる、といった問題が頻発するのですが、これは我が組織では全く問題になりません。
だって、「仕様書の作成者 ＝ プログラマー ＝ 私」なんですもの。
ってことで、仕様書は「何をどうしてどうなるのか」という記述にして、具体的な実装方法はプログラム側で考えることにしました。
後書き
Excel方眼紙は褒められたものでは無いと思うのですが、メリットが無いわけでもないと思います。
専用ツールの場合、使用方法の習得、ソフトの用意（購入、インストール）とかの手間がかかりますし、将来的には、「開発停止で新OSに対応できない」なんて、なんだかなぁって状態になるリスクもあります。
お客さんに提出するにも、データで提供するには別のファイル形式（PDFなど）に変換する必要があったりするでしょうし、便利な反面、リスクもあるとは思います。
一方、Excel方眼紙の場合、Excel（又はExcelを見れるソフト）があれば良いわけで、特別な環境が必要ないってのがメリットですね。
もちろん、そのメリットを打消すだけの機能があるからこその専用ツールなんでしょうけどね。
前回：基幹システムの電子記録債権への対応 Part9 サブシステムの対応範囲
次回：基幹システムの電子記録債権への対応 Part11 本稼働、そして・・・
投稿記事の一覧：目次
--- blog end ---
スポンサードリンク
0
0
