要求仕様定義ガイドライン（UVCプロジェクト報告書2007）
編著: 社団法人 日本情報システム・ユーザー協会
商品: A4判 166ページ
発行: 2007年6月下旬
書籍としての販売は終了いたしました。
下記より本文をダウンロードのうえ、ご覧ください。
システム開発についてユーザーとベンダーの間には深い溝がある。
発注する側は、「こんなものが欲しい」と言って欲しいシステムができてくるのが理想ではあるが、それだけでは受注する側のSEには、「こんなもの」の意思、内容は伝わらない。ユーザー側（発注側）は明確な仕様情報をベンダー（開発を受注する側）に伝える必要がある。
では、要求仕様はどのように書けばよいのか。ユーザーとベンダーは協力してこの要求仕様書の明確化に挑戦せねばならないので、このプロジェクト名をUVC（User Vender Collaboration Project）と名づけた。RFPプロジェクトと普通の名前にしなかったのは、今までの殻を破った発想をして欲しいとする願望の表れである。結論的にはこのプロジェクトにより以下の知見が得られたと思っている。
①機能、
②非機能
③データ属性の記述
④ユーザビリティ
の4種類の情報を、要求仕様書に盛り込むこと。
機能は機能仕様と理由を分けて書くこと、機能仕様には追い番号をつけ機能階層図を作成する。理由を分けて書くことにより「何故このような仕様になったのか」が明確になるとともに、仕様作成者の意思が正しく伝達される 。
仕様は仕様番号単位にカウントできるので、仕様変更率＝仕様確定後に仕様変更した仕様数÷総仕様数が計算できる。これを元にユーザー側とベンダーとの間で仕様変更マネジメントを実施する制度を普及した。
機能仕様は追番が付加されてあること、すべての仕様情報、プログラム情報はシステム内に保存されてあること、などの条件が整ったので、仕様からプログラムまでの関連情報の追跡管理が可能となる。
機能仕様からデータ構造が組み立てられる。概念データベース、あるいは論理データベースの作成が可能になる。仕様を図で表し、データ要素間の関係を追究・分析することにより仕様の曖昧さ、不十分さの解消が可能になる 。
非機能仕様についても経験者が議論し、要求仕様へのまとめ方が明確になった。 ユーザビリティへの要求記述は重要であるが、ユーザビリティを正しく要求仕様書に記述しなさいと指導しているガイドも今まで存在していなかった。新しく発案したユーザビリティを確認できる3手法の活用は比較的簡単である。ユーザビリティを重視するシステムは開発手法そのものを変えたほうがよいことも今回の研究で判明したのでJUAS-UCDモデルを創案した。
JUASのUVC検討プロジェクトのメンバ、ユーザビリティ研究プロジェクトメンバをはじめとしておおくの関係者の皆様のご努力により、要求仕様書のベストプラクティスが誕生できたと考えている。ユーザー企業の情報システム部門、利用部門、システム開発・保守部門、SＩ会社の各管理者の方々など必見の一冊である。
・システム開発・保守における要求仕様定義の明確化に日夜努力されているプロジェクトマネージャの方
・システム開発・保守における要求仕様フェーズにおける役割の明確化に頭を悩ませている方
◆主な内容
【目次】
0. 前書き
1. JUAS UVCプロジェクト事業体制
2. 要求仕様書に関わる問題とその解決方法
3. 要求仕様書とは
4. 要求仕様書作成に関わる作業の流れ
5. 知識共有の方法
6. 要求仕様の定義方法
7. 利用部門とIT部門の役割
8. 要求仕様を設計からプログラムまでトレースする方法
9. データベースの定義方法
10. 画面／帳表のデザインとユーザビリティ
11. 非機能要求の定義方法
12. USDMを使用した要求仕様書の有効性の確認
13. USDM表記法の適用方法・
14. 残された課題
付1．参考文献
付2．要求仕様書のプロトタイプ
付3．要求仕様書のテンプレート
付4．画面／帳票定義書の記載項目
付5．「USDM表記法による要求の仕様化について」（清水吉男氏のレジメ）
索引
