ソフトウェア要求

ソフトウェア要求

顧客からの要求をどのように引き出し、文書化し、管理していくのかを記述した本。

要求とは、スポンサーから出される抽象度の高い要求「業務要求」、ユーザから出される「ユーザ要求」、ソフトウエアが実現すべき「機能要求」の３つのレベルからなり、それぞれに対応するドキュメントが「ビジョン／スコープ記述書」、「ユースケース記述書」、「ソフトウエア要求仕様書（SRS）」となる。いったんベースラインに入った要求はスコープクリープを避けるために変更管理委員会（CCB）で管理される。ユーザの代表者として製品チャンピオンなる役割の人を選出し、その人を巻き込んで要求開発を進めていくようだ。

SRSのテンプレートなどは紹介されているが、実際の仕事にどう適用していくかとなると若干抽象的ではある。

また監訳者あとがきにあるように原書のSoftware Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. (Pro-Best Practices)からはツールの紹介が外れているのもちょっと残念。ただ原書は2003年に出版されており近年流行しつつあるチケット駆動開発の考え方も入っていない。

おそらく高い抽象度の要求と低い抽象度である開発者レベルのタスクをうまくひもづけていけばいい管理ができるだろう。前者が顧客向けの、後者が開発者向けの進捗管理単位となる。

Redmineの場合以下のようにやるのが考えられる

つまり、1つの機能という実体をストーリーカードとタスクカードの別々の観点で進捗管理できればよい。

【4】今僕がRedmineの運用で現実的と考えるやり方は下記の通り。

4-1・ストーリーカード(顧客向け)とタスクカード(開発チーム向け)の2個のプロジェクトを作る。
4-2・ストーリーカードには、顧客向けに報告する単位の機能をチケットへ登録する。
4-3・タスクカードには、開発者が作業する単位、あるいは成果物単位でチケットへ登録する。
↓
4-4・タスクカードの属性に、タスクの発生源であるストーリーカードのチケット情報を登録しておく。
　ストーリーカードには、派生したタスクカードのチケット情報を関連づけておく。
4-5・タスクカードが更新されるたびに、発生源であるストーリーカードの実績工数・ステータスなどが更新される。
↓
4-6・顧客向けの進捗報告は、ストーリーカードのRedmineサマリから集計する。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

ツールの進歩は早い。いままで問題だったものをなんとか改善するための機能がツールにはある。それをいかにうまく活用するかは使う人間次第だ。