略で、ユーザが開発中のソフトウェアを試用し問題と感じたことを開発者にレポートするものです。ユーザが問題と感じることの原因としては、プログラムのバグ、仕様の不備(または不完全性)、実装が不完全、ユーザの誤解・理解不足の場合などがありますが、これらを区別することは(一般)ユーザには困難で意味の無いことです。(SPR)」とし、それらを同次元で取り扱います。「仕様書とは無関係に」という点に注意してください。ソフトウェアがユーザが期待した通りの動作をしない場合、それが仕様書に明記されているかどうかは免罪符にはなりません。ユーザが問題と思えば、それは問題なのです。ユーザは主観的に問題と思ったことをレポートします。すべての問題が対処できるかというと、そんなことはありえません。ソフトウェア開発は人員、コスト、時間といった有限のリソースを使って行うものなので、出来ることには限りがあります。したがって、ある問題を実際に対処するかどうかは開発側の判断となります。これに対して不満があるユーザは開発コストを負担するか、当該ソフトウェアを使用しないか、いつかその問題が解決されるのを我慢して待つ、という選択肢があります。自分で代替物を開発するというのもひとつの選択肢です。ユーザが開発コストを負担するのでない限り、開発者に対処を無理強いすることは出来ません。このことはしっかり理解しておいてください。いずれかの状態にあります。いずれかの結果になります。問題ではあるけれど工数が膨大・困難なために総合的に判断して対処しないことを表します)が問題を新たにレポートするとSPRが生成され、New状態になります。担当者は新規SPRを確認し、問題が再現するのであればOpen状態にします。再現しない場合はPend状態とし、レポートしたユーザと協議します。協議後に再現するようになればOpen状態に、そうでなければ継続協議またはClose状態になります。報告済みの問題、ユーザの誤解・理解不足でレポートに問題があった場合、対処しないことが決まっている場合は、重複、ユーザエラー、NPTF、仕様という結果でClose状態になります。Openされた問題が開発者により対処されるとFixed状態になります。開発者の判断で問題を対処しない場合があります。その場合は仕様またはNPTFという結果でClose状態となります。Fixed状態のSPRは問題報告者により対処が確認され、問題がなければ結果:対処でClose状態になります。対処が不十分な場合はReOpen状態になります。各SPRはオーナーを持ちます。オーナーとはその時点での当該SPR担当者のことです。オーナーはSPRの内容を判断、調査し、必要があれば何らかの対処を行って次のオーナーにSPRを引き渡します。Close状態の場合はオーナーはいません。優先度(Priority)SPR対処の優先度を示します。優先度B以上は正式リリースまでに対処・実装しますが、C以下はスケジュールの方が優先されます。優先度はもろもろの事情で変更される可能性があります。種類・問題の深刻さを表します。ポイントシステムを採用しています。ユーザは発見した問題をSPRシステムに登録する、有用なコメントを記述することでポイントを取得することができます。vote(投票)に使用することが可能です。問題報告のポイントは以下の目安とします。0ポイント実際の報告がどれにあたるかは管理者の独断と偏見で決定します。10ポイント程度減点します。5ポイントを差し上げます。有用なコメントの場合、10〜30ポイントを差し上げます。10ポイント差し上げます。行うことで、好みの機能実装や問題対処を*せかす*ことが出来ます。値を参考にして作者が独断と偏見で順番を決めます。多いものから優先的に対処します。結果よりも作者の意思が優先します。その場合、持ちポイントは増えるわけではなく、voteしたポイントの絶対値だけ減少します。数であっても、実装工数が少なく副作用の心配が小さい場合は優先的に実装されます。数が多くても、優先的には実装されません。できるポイントは(絶対値の)合計100ポイントまでです。できるポイントの有効期限は、ポイント取得月から3ヶ月間とします。1月中に取得したポイントは3月末まで有効です。するようにしてください。