![[ARK-Web SandBox]](image/sandbox.gif "[ARK-Web SandBox]")
- バックアップ一覧
- ソース を表示
- 要求仕様化手法のWikiエントリー記述への応用 は削除されています。
- 1 (2006-07-20 (木) 13:38:02)
- 2 (2006-07-20 (木) 16:43:45)
- 3 (2006-07-21 (金) 14:47:29)
- 4 (2006-07-21 (金) 16:35:36)
- 5 (2006-07-21 (金) 18:23:34)
要求仕様化手法のWikiエントリー記述への応用?
要求仕様化手法のWikiエントリー記述への応用?
目次 †
このドキュメントは？ †
要求を仕様に分割して整理する要求仕様化手法の練習がてら、Wiki(またはブログ)に週一回単位でエントリーを投入することを一つの要求とみなして（実際会社から自分に投げられた要求には変わりありません）これを仕様として具体化してゆくことで、要求の実現性を高め、要求仕様化のスキルアップもはかる為に記載したドキュメントです。
自身の習熟もさることながら、要求仕様化手法の周知も目的に兼ねています。
要求とは？仕様とは？ †
後の混乱を避けるためにも、要求と仕様の定義、そしてその違いを明確にしておきます。
- 要求
- 依頼者が作業者に対して、作って欲しいこと、達成して欲しいことをあらわしたもの。何(What)を望んでいるのかを明示する。モレ、重複を防ぐために要求には必ず時間的、空間的、機能的な範囲をもたせる。また、範囲そのものがブレることを防ぐために必ず理由も定義する。
例）
要求：３ヶ月間で月次売り上げ1.2倍増を達成する
理由：３ヶ月後に四半期の決算発表があり、株主に対して業績向上をアピールする必要があるため - 仕様
- 要求を実現するために抽出される具体的な機能、行動、措置。要求をいかに(How)実現するかを明示する。仕様は要求の範囲を出ないこと、そして要求の範囲の隙間をモレなく埋めるものである必要がある。また、仕様は検証可能性を持つ。これは仕様とは作ること、達成することに関する関係者が記載内容に関してSpecify（特定）できるように表現されるものであり、特定できるとは検証可能であるということで担保されるため。
要求の定義 †
今回の直接指示された要求、理由は下記の通りです。
| 要求 | Wiki（またはブログ）に週１ペースでエントリーを書く |
| 理由 | Wiki（またはブログ）に記事を書くことは、営業上も非常にコストパフォーマンスの高いActionであり、また、自分達のやれるコト、興味を持っているコトを示すことで、これに共感してくれる顧客と仕事ができる可能性が高まるため |
しかし、この要求が外界との間に持つ境界線がこのままではまだ曖昧であり、また、この要求が含む範囲自体がまだまだ大きいため、仕様抽出時に仕様が拡散してモレてしまう可能性が高いです。そこで、この要求の外界との境界線の特定と分割、階層化を実行します。
要求の境界線の特定 †
要求とそれを取り巻く境界、外界とのやりとりを明示するためにコンテキスト図（概要図）を使って表現し、要求の「内」と「外」を明確にします。
要求の分割と階層化 †
要求の分割と階層化を実施するためには紙上に要求全体を示す領域を表現し、それを分割する形で一段階層を降りた要求を表現する方法があります。
今回の要求を分割してみます。
厳密には紙上に拘る必要はなく（実際上記でもPPTで表現した後、画像化しています）、Excelなどのテーブル形式を利用した表現でも問題ありませんが、最初にざっと分解する際には手書きで紙上で作業するのが分割作業そのものに注力できますし、視覚的にも要求の範囲の間隔をつかみやすいのでオススメです。
分割、階層化したといっても要求に変わりはありませんので、各要求には理由が記述できます。実際には分割、階層化する中で理由を書くことが困難になっていくのが一般的です。が、理由を安易に省略するようにすると、安易に階層化するようになっていき、要求の範囲のぶれ、重複、抜けを発生させてしまうので、理由は必ず記述するように心がけます（ただし、どうしても無理なケースにおいては空欄にしておきます）。理由を各要求に対して書くためにはテーブル形式の方が都合がよいので、テーブル形式にまとめなおします。
| 要求 | WIKI001 | Wiki（またはブログ）に週１ペースでエントリーを書く | |
| 理由 | Wiki（またはブログ)に記事を書くことは、営業上も非常にコストパフォーマンスの高いActionであり、また、自分達のやれるコト、興味を持っているコトを示すことで、これに共感してくれる顧客と仕事ができる可能性が高まるため | ||
| 要求 | WIKI001.1 | Wikiに書くテーマを見つける | |
| 理由 | あらゆるエントリはテーマを伝えるために存在するため。また、テーマを決めない状態では調査、記述にもゴールが見えず時間が必要以上にかかってしまうため。 | ||
| 要求 | WIKI001.2 | テーマに関する調査、自分なりの検証を行う | |
| 理由 | 自分は社のWiki/ブログでは技術的な動向を伝えたり、取得した知見、検証結果を提示することによって自社の技術力、関心度、アンテナの高さをアピールすることで営業に寄与することに求められているという理解から、技術動向、興味のある技術周りの件に関する学習、検証が求められていると判断されるから | ||
| 要求 | WIKI001.3 | 調査、エントリー記述の時間を１週間の中に定期的に確保する | |
| 理由 | 定期的なエントリーの提供を行うためには、定期的な調査、記述の時間が必要であり、その時間は明示的にとらなければ日々の業務にとって変わられてしまうから | ||
| 要求 | WIKI001.4 | エントリーの段落分け、構成を考える | |
| 理由 | 段落に分割することで、段落単位の記述が可能になり、まとまった時間の確保ができなくても記述が可能になる可能性が高まるから。また、構成を考えてエントリ全体の流れをまず把握することで、不必要な情報収集を避けられ、調査、執筆時間の見積りも行いやすくなるから。 | ||
| 要求 | WIKI001.5 | 文章を書く | |
| 理由 | |||
| 要求 | WIKI001.6 | 必要な図、表を用意する | |
| 理由 | |||
| 要求 | WIKI001.7 | 書いたエントリーをアナウンスする | |
| 理由 | 自社Wiki（ブログ）に記載するエントリーは自己の研鑽、社内での知見の共有だけではなく、潜在顧客へのアピールも兼ねているため、適切なアナウンスが必要 | ||
「文章を書く」、「必要な図、表を用意する」に関しては理由が書けませんでした・・・降参です。これらは要求に配置するのではなく、最上位の要求「Wiki（またはブログ）に週１ペースでエントリーを書く」に対する仕様と捉えるべきだったかもしれません。
要求から仕様を導く †
プロセスを設計する †
スケジュールに配置する †
