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

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

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

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

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

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

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

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

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

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

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

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

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

話が変わります。

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

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

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

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

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

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

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

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

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

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


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