※この記事では「詳細設計」についてざっくりとまとめています※

 

前回までの記事で、システム化にはステップがあり、要件定義ではクライアントの要望について記載するとご説明しました。

では、詳細設計とはどのように行うのでしょうか。

 

要件定義の段階で決まった内容をさらに詳細に記載したものを「詳細設計書」と呼びます。

詳細設計書には、どんな機能を持ったプログラムを作成するのか、またどのようなロジック(方法)で作成するのかについて記載する必要があります。

要件定義と同様に消費税込みの計算をするシステムを例に考えていきましょう。

上記システムに必要な情報は何だったか覚えていますか?

それは次の3つです。

商品の値段
商品個数
消費税率

それに加え、大事なことがもう一つありました。

そう、リスクを考えることです。

では、ここでのリスクについて少し考えてみましょう。

さて、リスクとなるものは何か思い当たるでしょうか？
(ヒント:皆さんは、インターネットなどで買い物をする時にどのような項目を選択するでしょうか。)

上で示した3つの項目の中で、クライアントが自分で「入力できた方が良いもの」と「容易に変更されては困るもの」と言う視点で考えてみましょう。

項目内容の整理
商品の値段	割引や新商品の販売によって変動することがある。
商品の個数	単品・まとめ買いによって変動する。
消費税率	変動することはあるが、為替（円高・ドル安）のように日々変動するものではない。

 

つまり、クライアントにとって容易に変更できた方が良いものは、「商品の値段」、「商品の個数」となり、容易に変更されては困るものは、「消費税率」となります。

 

では次に、この3つの項目で取り扱うデータについて考えてみましょう。
※ここでのデータとは、ひらがな、カタカナ、英数字などです。

 

上記3つの項目で取り扱うと予測されるデータは数字だと仮定できます。

なぜなら、消費税率について「計算」するからです。

しかし、本当に数字しか取り扱わないのでしょうか。

では、念のために数字以外のデータについても考えてみましょう。

問1
ひらがなの「あ」と「100」を足し算してみてください。

問2
次は、「イ」と「う」を掛け算してみてください。

(少し意地悪ですが、ちゃんと答えはありますよ。)

 

 

 

 

 

 

皆さん、計算できたでしょうか？

 

 

 

 

 

 

 

答えは、「計算できない」です。

 

 

えっ？ふざけるなって？

 

すみません。

でもこれも大事なことです。

なぜなら、問１、問２のようなことができてしまっては「困る」のです。

 

つまり、消費税計算システムで使えるデータは、「数字のみ」にしなければ「困る＝リスクがある」ということです。

 

最後に、これらの情報をまとめてみましょう。

システム名：税込み計算システム

システムの内容

1. 「商品の値段」、「商品の個数」を入力できるようにする。
2. 「消費税率」については、固定値を設定し、入力不要とする。
3. 取り扱う項目については「数字のみを取り扱う」こととする。

あっ、大事なことを忘れていました。

計算した結果についての取り扱いを決めていませんでした。

 

では、今回は計算した結果については、表示させるだけにして、入力や変更はできないと言う取り扱いにしておきましょう。

値を加算して表示させる取り扱いとしましょう。（2018.10.21追記）

 

これで、詳細設計書は作ることが出来ました。

（分かりやすさを優先したため、設計上抜けている部分があるかもわかりませんが、、、）

 

今回の記事は以上となります。

よろしければ、他の記事についても読んでいただければと思います。