くだらん話が9.5割

寝るために頑張るというのは、非常に気に入らない。

頑張って寝るなら、寝ないでいいじゃないかと思えてくる。と思ってたら寝てしまう。
 むかついてくる。

4年になったからこそ、昔話ができるんだなと、今日は思った。
 木陰の下にあるベンチで一年生の思い出を話していると、あの頃の自分がバカだったと思う。今もバカではあるが、あの頃より良いバカにはなったと思う。

さて、
要求仕様書を書いているわけですが、進むところは進むが、進まないところは本当に進まない。

一番重要の要求と仕様が、さっぱり思いつかない。
知識が足りないのと、まだはっきりと決まっていないことがあるから、と言い訳したい。

Ver.1.0を挙げてみたのはいいけど、かなりひどい。
しかし、とりあえず挙げた。

悩んで、もたもたしてもどうしようもない。
出したモノを基に詳しく決めていくか、ズタズタに破いて考えなおすか…

だけど、ベースライン(1はちゃんと制作しておきたいという気持ちもある。
これがあると、改善(要求の)には役たつはずである。
要求仕様がゴロゴロ変化するならなおさらのことかと。

ただ、自分が書いてる奴は、ボロボロのラインになってるから…。

1)　ベースライン：ものが時間的経過を伴って変化をするとき、変化や実験効果の有無を観察するために、決められた判定基準のこと。要求仕様書のベースラインは「進歩」や「達成」を図る基準とも言える。
　

佐○先生の部屋のドアに貼ってある、ミクさんのポスターが気になる

たぶんだが、これのポスターだと思う。
http://antenna7.com/artdesign/2012/04/the_end.html

VOCALOIDの新境地をみたいとかは特にないが、あのポスターの絵が好きだ。ただで天使の（ｒｙ

しかし、なぜ貼ってるのだろうか。この話に参加しているのだろうか。ありえる話ではあるが･･･。

要求仕様を書こうというところに来たわけで、意外とかけそうな気がしてきた。
と、思いたい。

凍結判断ライン(11月9日)も定めたわけで、がんばって走らないといけないなと。

話変わりまして、ここから、全部持論に等しい話。

要求を仕様化する技術・表現する技術(1、を全部読んでいないが、流し見して、(時間あったらきっちり読むつもりです)なんとなく思ったこと。

ざっと見た感じなんですが、この本は要求に関すプロセスで発生する問題とその解決法について、まとめたものだと思った。

今の自分の状況（開発始まる段階）で使えるものだと思うが、読む時間がない。

350ページくらいで、それほど厚くはないが、字と字の間隔が狭く、意外と内容が多いと感じた。それと、見にくい。

この本で、ちょっと特徴的だと思ったことを一つ。

いままで読んできた本では、要求仕様書について話すとき、要求と仕様の関係は平行にあったのだが、この本ではどうも階層になっている気がする。
以下の図が自分のイメージ。

このことは本にも書いてあったかもしれないが、結構特徴的なものだと思う。

というか、IEEE規約(2から外れている気さえする。(IEEEにかならず当てはまる必要はない)しかし、確かにこの考え方は、漏れを少なくすることができるような気がする。（やってみないとわからない）


(1　要求を仕様化する技術・表現する技術
(http://www.amazon.co.jp/%E8%A6%81%E6%B1%82%E3%82%92%E4%BB%95%E6%A7%98%E5%8C%96%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93%E3%83%BB%E8%A1%A8%E7%8F%BE%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93-%E5%85%A5%E9%96%80%EF%BC%8B%E5%AE%9F%E8%B7%B5-%E4%BB%95%E6%A7%98%E3%81%8C%E6%9B%B8%E3%81%91%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B-%E6%B8%85%E6%B0%B4-%E5%90%89%E7%94%B7/dp/4774125237)

(2　IEEE830：要求仕様規格
http://www.bcm.co.jp/site/2004/2004Dec/04-youkyuu-kougaku-12/04-youkyuu-kougaku-12.htm


最後にどうでもいいことが一つ。
　OSの成績がどうなっているのか、気になる。
　「さっさと出せよ」。
　いろいろと決めないといけないことが有るのに･･･。
　

お前の知ってる「○○ックス」の種類を数えな。（仮面ライダーW）

問題を発見する前に、まず問題を発見するための方法に問題がないか、検証しないといけない。

と、思っているのだが、放置したい気持ちでいっぱいだ。

さて、今日は、開発初期段階で、プロトタイプの導入という話がチラッと聞こえて、速攻で否定してしまったけど、良く考えたら、前回の反省を活かすのであれば、今らか使うべきなのであろう。

ただ、プロトタイプを導入する場合、どうすればいいのだろうか。

わからん。

開発の話が進んだけど、これからどうすればいいのだろうか。

抽出と分析を行う必要があるでしょうけど、仕様化はどうすればいいのだろうか･･･

疑問しか出てこない。

ががががが・・・・・

どうでもいいことを一つ。

モノを作るとき、道具確認しないと、本当だめだ。設計図ばかりに気をとられていると、アウトなきがする。

ということは、ツール確認したほうがいいのかもしれない。


以下はアイスブレイクのサイト。これから使うから、忘れないように貼っておこう。
http://icebreak.blog102.fc2.com/

http://www.gshift.com/bgComIcebreak.htm

「月がきれいですね」の「月」を「太陽」に置き換えたら、どういう意味になるんだ？

「太陽」に置き換えたら、「暑いんだよ、あっち行けよ」という意味になると思っている。

つい先日、中秋の名月だったわけで(9月30日)、すでに終わっているが。

月は相変わらずまるい。月見する気分にはなれないけど。

というか、雨降ってないか、今（10月2日）？



まぁ、そんなことはいいや。

前回のCEMPEI開発は、要求に問題があると思っているが、はっきりと指摘できるほど問題追求を行っていないため、ゼミで躓く。

前に進めず、ぐるぐる回ってる。

しかし、問題をはっきりとした場合、果たして本当に前に進めるかどうか・・・そんな一抹の不安がある。

そして、そちらの話を考えつつ、始まった第二回の開発。
今回は、要求のことに注意するつもりだが、テストの話とかもあるなと思い出す。

前回の開発を踏まえると、テストで、まず気をつけないといけないことは、

・テストを行う時期より前にテスト計画を立てる。
・テスト項目と要求（仕様かもしれない）項目を関連付けする。

だと、思っていたりする。

内容とかよりも、やり方の話である。

前回はこれがすでにできていない。今考えたら、何をしていたのやら。

気をつけるからといって、できるかどうかというのはわからないが、この二つを心にとどめておくとしよう。

ただ、少し気になるのは、自分たちがかかわっている開発を自分たちで（俺とか）テストするというのは、どうも違うような気がする。

何が違うのかはいまいちはっきりといえない。

本当、はっきりといえないことが多い。つらい。


どうでもいい話を一つ。
ヘルの兄弟たちの名前が、ヴァナルガンド（フェンリルの別名）、ヨルムンガンドだから、
ヘルにも「～ガンド」という別名があるのではないと思って探したが、ないということがわかってむなしい気持ちになったので、ここで終わりにしよう。

だいたい適当、後ろに要求テンプレ。

とりあえず…何普通に窓から入ってきてんだよ！！

黒光りするGは場にいても役に立たないんだよ！！
墓地にいるからこそ、役に立つんだよ！！
だから、さっさと消えろよ！！

普通に入ってきて、壁に張り付いたまま、なに余裕ぶっこいて、様子を伺ってんだよ。
不法侵入だよ。死刑だよ。
ゴキブリジェット噴射だよ。お前怖ぇんだよ。
最近妙に種類が増えて、ドロー効果とかついてんじゃねぇよ。
除去するよ。本気で。
３秒で即死と書いてあるゴキジェットを３０秒以上噴射したよ。
 死なねぇな。逃げもしなかったけど。

トラップ発動かと思ったけど、そのまま墓地に行きやがったよ。
とりあえず、墓地発動を防ぐために、除外する。
形が残らない程度、潰しておく。

噴射した気体のおかげで、俺もダメージを受けてる気がする。

話変わるが、沸騰ポット（ http://www.sessame.jp/workinggroup/WorkingGroup2/POT_Specification.htm）の要求仕様を見てきたけど、第７版を目指して書くとしたら、…むずいな、これ。でも、これができたら、色々と区切りやすいな。しかし、むずいな…。

ざっと、昨日言っていたソフトウェア要求仕様のテンプレートを載せよう。（だいたいな感じのやつ。これでいいのかどうかは不明。）

1.はじめに
　1.1ソフトウェアの目的
   1.2文書表記規則
　1.3参照文献

2.概要説明
　2.1ソフトウェア概要
　2.2ソフトウェアのユーザー
　2.3ソフトウェアの機能
　2.4設計と実装の制約

3.機能要求
　3.1機能１
　3.2機能２
　　…

4.非機能要求
　4.1インタフェース
　4.2設計および制約（機能要求を反映したもの）
　4.3品質特性

5.イベント

付録
・用語集
・分析モデル
・要求の優先度

開発にもよるので、これが正解かどうかは正直不明。（参考元は特にない）

あとは話をして、どうやって行くかだ。

変動駆動型でこれをやろうとしたら、かなりきついな…。

最後に。
台風中途半端、頑固な年寄り方は面倒くさい！！

そういや、冬虫夏草っていくらなんだろ…？

正直、これを投稿する必要性を感じない。

連続更新し続けているMaxですが、多分、すぐに飽きてくるでしょう。秋だし。

…さて、最近なぜか絶望先生に再ハマりして、マンガを読み直している。昔の時事ネタが出てくるから、なんか懐かしい。
 そして、なぜかギリシャ神話にも再ハマりしている。休憩がてらに調べてると１時間とか普通に潰せる。
気づいたら、ギリシャ神話から悪魔学に飛んでいたりする。
悪魔学というのもなかなか面白い。まぁ、宗教とか絡んでるから、面白いのは当然のようにも思える。

何かを書きたかったが、意外とネタがなかった。

まぁ、これから開発が始まるから、準備できることを早めに準備しよう。

で、寝ることにしよう（？）

これからも、CEMPEIのみなさん、よろしくお願いします。（特に他意はありませんよ）

要求とか（なんか、余計な気もする）

１０月から、また開発をやるかもしれない。
チケット駆動や、アジャイルを使おうとした時に、要求の話が絡むと思う。
それならば、要求について少し話をしたい。書いておいたほうが、後々便利だろうから。

ただ、今からドヤ顔でいろいろと書いていくつもりですが、「そんなこと知ってるし」や「それ、なんかおかしくない？」とか思う方はいるかと。その場合スルーかコメントしてください。では、ドヤ顔を始めたいと思います。

まず、「要求」というと、下流と関係ないように思えるが、実際それは違う。
要求には３つのレベルがある。

ビジネス要求、ユーザー要求、ソフトウェア要求の3つである。
開発チームに属するのであれば、かならずこの３つの要求のどれかと関わることになる。以下に、それぞれの要求について簡略な説明をしておく。（チケット駆動やアジャイルをやる場合、全部関わる可能性もあるのではないだろうか。）

ビジネス要求：企業ではビジネス要求と言ったりするが、要するに、目標の定義、ユーザー層の定義、プロジェクトの長期的計画、高レベルの意図などのことである。
（一般的には、上流とか経営陣などが決める。）

ユーザー要求：ユーザーの視点からソフトウェア要求を定義したもの。ユーザーがソフトウェアを使って行うタスクとソフトウェアに必要な品質特性など。このユーザー要求はビジネス要求とソフトウェア要求の橋渡りになるため、慎重になる必要がある。
（一般的には、マネジャー、ユーザーや設計者が決める。）

ソフトウェア要求：ソフトウェアが実現しなければならない機能要求および非機能要求をすべて詳細に記述したもの。
（一般的には、マネジャーや設計者、プログラマが決める。）

この３つを決めるとき、順番が存在する。
まず、ビジネス要求が定められる。その次に、ビジネス要求を満たすユーザー要求が考えられる。最後にビジネス要求とユーザー要求を満たすソフトウェア要求が定められる。

定められたビジネス要求は、だいたい不変的なものである。ユーザー要求とソフトウェア要求は開発手法によっては、可変である必要がある。

では、ビジネス要求を文書化する場合、記すべき項目をまとめてみる。

ビジネス要求
１０月から始まる開発の話から言えば、最低でも定義しないといけない項目は７つある。
・対象
・ニーズやチャンス
・ソフトウェアの名前
・ソフトウェアのジャンル
・ソフトウェアの利点
・類似するソフトウェアの情報
・類似するソフトウェアとの差別化要因

ユーザー要求とソフトウェア要求については後日。（いろいろ内容があるので）

話が変わります。

要求は「機能要求」と「非機能要求」の２種類がある。
これは種類であって、上で記した３つの要求とはまた違う。混乱するかもしれないが、そういうものだと思ってください。

機能要求：ソフトウェアが行うことの部分であり、ユーザーが使う動作や振る舞いのことである。

非機能要求：ソフトウェアが持つ特性のことである。
　
非機能要求を定義するためには、品質特性、設計および実装の制約、外部インターフェースについて触れる必要がある。非機能要求は、ソフトウェアの性質であり、ソフトウェアの振る舞いの特性や制約である。だから、定量的な言葉で文書化する必要がある。

・品質特性：性能、容量、保守性、移植性、信頼性、使いやすさなどソフトウェアの開発、運用環境の特性のことである。
・設計および実装の制約：ソフトウェアの設計方法を限定する条件のことである。例えば、ソフトウェアを同時に利用可能のユーザー数や使用するプログラミング言語などのことである。
・外部インターフェース：開発とあまり関係ないので、説明省く。

話が変わる。
要求を定める際、要求開発と要求管理（要するに要求工学のことである）が絡んでくるので、少し書いておく。

要求開発：要求開発は新しい要求を探るためにあると考えていい。以下のように、４つのフェーズがある。
1.要求を定義するために、データの抽出
2.データの分析
3.要求の仕様化
4.要求仕様の妥当性確認
要求開発は反復するもので、フェーズ４が終わると、再びフェーズ１に戻る。

要求管理：要求の変化に備えて、ベースラインを確立し、変更管理、要求の追跡を行うことである。
詳しい話は除くが、簡単に言うと、要求が変わってもバグが出ないように備えをすることである。

最後に。
要求にもいろんな手法が存在する。
例えばリスク駆動型や変更駆動型などがある。
リスク駆動型については省略する。

変更駆動型というのは、少人数による開発で使われる方法で、常に新しい要求に合わせて要求仕様を変更し、開発を行う。
要求仕様文書の量は最低限の要求文書を残す。このことによって、短い（１〜４週間）反復で動くソフトウェアを開発する。
また、要求はストーリーシナリオで簡略に表し分析を行う。要求の妥当性確認や各プロセスに対する検証を頻繁に行う。ユーザー受け入れテストやプロトタイプの導入が有効的。

もう少し詳しい例を書きたいが、かなり長いのでやめておきます。


ここまで読んでいただいた方に感謝を。