清水吉男の仕様が漏れない要求仕様の書き方講座(研修会 / 東京都) |
|
内容 | システム開発プロジェクト成功のカギは、要求仕様の完全性!「要求」を「仕様」にする際にどうしたら漏れない要求仕様書・要件定義書になるのか。講師自ら、多数プロジェクトで実践し、成功に導いたUSDM表記法と考え方を、演習を交えて学びましょう! ◆日 時:2012年11月15日(木) 10:00-17:30 ◆会 場:社団法人日本情報システム・ユーザー協会 会議室 ◆趣 旨: プロジェクトの成功の秘訣は、要求仕様書の明確化にあることは、各種の調査結果で報告されています。しかし「何をどのように書けば良いのか」を具体的に記述したガイドはほとんどありません。自らの「要求」を確認し、「仕様」として表現していく必要があります。 今回ご紹介する清水氏の考案されたUSDM方式は、後工程の設計に一貫して活用でき以下の特徴を持っています。 [1]要求を記述する際には、仕様に加えて理由を必ずつける。このことによりなぜこの要求が必要になるのかがより一層明確になる。(レビューがしやすい、漏れがない) [2]要求が仕様書、設計書にどのように展開されたのかが系統的にフォローでき、開発だけでなく保守作業にも引き続き活用できるので、機能のTraceabilityが確保できる。 [3]このUSDM方式は、EXCELを活用して機能、非機能を詳細に定義できるので、従来どのベンダーも出来なかった 仕様変更回数などが簡単にカウントでき仕様変更率のマネジメントなどが可能になる。 [4]IEEE830に提唱されている開発ドキュメント方式も、この方式に近似しており、国際的にも通用しやすい。 USDM方式を活用したプロジェクトの場合、品質が向上し、成功率がアップしたとの声が多数聞かれております。 今回は、「仕様が漏れない要求仕様」をどのような点を注意し、書いていったらいいのか、USDM(Universal Specification Describing Manner)という具体的な表記法はもちろん、要求を仕様化する際の考え方、整理すべき点、注意すべき点などを中心に演習を交えた講座をご用意させていただきました。この業界では、多数の成功プロジェクトの経験者として有名な講師の事例なども交え、具体的、かつ実践的な即使えるノウハウを中心に実施します。 常日頃、よりビジネスに役立つシステム開発に熱意を注いでいる方、より品質の高いシステムを作るにはどうしたらいいか悩まれている方、失敗プロジェクトの撲滅に取り組んでいる方など、システム開発に携わるシステム管理者、担当者などユーザー企業、ベンダー企業問わず、必見の講座です! 世の中にあふれる「要求仕様書の書き方」講座とは一味違う、充実の講座です。ぜひご参加ご検討ください。 ◆プログラム: 第1章:なぜ、仕様が漏れるのか 最初に、仕様モレなど仕様にまつわる問題の整理を行います。 問題の根底にあるのは、「仕様は設計しながら抽出するもの」という間違った考え方であり、「要求仕様書ではコミュニケーションの不完全性は解決できない」という認識です。これを認めるかぎり仕様モレなどの要求仕様にまつわる問題は解決しませんし、その後の仕様の変更も減りません。そして仕様モレが起きる直接的原因は、実現して欲しいことを「要求」として適切に表現していないことにあるのです。 第2章:USDMの特徴 USDMとはどういう表現方法なのか 「仕様は動詞およびその目的語にある」と考えています。そのために「要求」を表現するのです。また表現の特徴としては、要求と仕様を区別し、それらを「階層」で表現したり、要求を「振る舞い」の形で表現し、さらに「理由」を付けたりすることで依頼者の思いとのずれを解消します。USDMは要求の階層構造の中で仕様を効果的に抽出する方法です。 第3章:要求を表現する(演習) バグの主要な要因は「仕様」に関係するものです。そして「仕様モレ」の最大の原因は「要求」を表現していないことにあります。コミュニケーションの不完全が問題になるのも、「要求」が適切に表現されていないからです。この章では、要求とは何か? 要求の役割は何か? 要求をどのように表現すれば良いのか? といった、要求の役割や分割基準など表現方法と、要求を表現することの重要性について説明します。 第4章:要求を仕様化する(演習)(事例紹介) 多くの組織では、いきなり「仕様」を引き出そうとして失敗しています。しかしながら、要求がその範囲を適切に制御された(階層化などで狭められた)形で表現され、そこに含まれる「動詞」が表現されれば、仕様を引き出すのは簡単な作業です。逆に言えば、動詞が表現されれば仕様は漏れないのです。これがUSDMの大きな特徴の一つです。要求と仕様を使い分けない限り、仕様モレは残ってしまいます。この章では、事例ケースを元に、実際に手を動かし、書いてみていただきます。 第5章:画面仕様にもUSDMを適用する 画面仕様にも一般の機能要求と同じ表記法を適用します。ボタンや表示域など、操作画面を構成する個々の要素に対して、その要素に求められる責務や「振る舞い」を「要求」として表現します。画面遷移は一種の状態遷移ですので、「イベント」と「アクション」を持っていて、これが「振る舞い」となります。そして要求の表現の中に見える動詞を満たすべく仕様を引き出します。 第6章:作り方の品質要求の扱い 品質要求は、「非機能要件」を構成する主要な要件です。品質要求にはパフォーマンスなど「機能に付随したもの」と保守性などの「作り方に関するもの」があります。機能に付随する品質要求は、通常の機能要求と同じように表現することができますが、作り方の品質要求は、作業者に対する「作業の仕方の要求」の形で表現したり、「見なす」という概念が持ち込まれたりして、機能要求とは違った視点が必要です。 第7章:要件管理プロセス 基本的な姿勢としては、ベースライン設定後の仕様変更が少なくなるように、たとえば「5%以下」になるように要求仕様の書き方や構成を工夫することが先決です。それでも、仕様変更はなくすことを保証できるあけではありません。USDMでは、要求と仕様を階層で表現することで文書を「1つ」にまとめます。また要求仕様書に「TM(Traceability Matrix)」を組み合わせることで、途中で発生する仕様変更に効果的に対応する方法を持っています。 ◆講 師:清水 吉男氏 (株式会社システムクリエイツ 代表取締役) 1968年からソフトウェアの世界に入り,一般のビジネスシステムからオンラインシステムの開発まで黎明期のシステム開発に携わる。途中から組み込みシステムの世界に転じ、POSシステムでは世界で最初の5万件の単品管理システムを完成、またインクジェットプリンターや内線電話のデジタル化システムなど多くの製品のソフトウェアを開発。この間の20数年間、納期遅れや仕様トラブルもなし。1990年頃にCMMと遭遇したのを機に、それまでの成功事例を元にして、たとえば要求の仕様化技術を「USDM」としてまとめ、また派生開発に特化した開発プロセスを「XDDP」としてまとめたりして、95年に「QCDの達成」を旗印にしたプロセス改善のコンサルティングに転向して今日に至る。一貫して「営業しない」という姿勢を堅持。 「硬派のホームページ(http://homepage3.nifty.com/koha_hp/)」を主催。 ※「要求を仕様化する技術・表現する技術」(技術評論社) …(USDM)「仕様は動詞にある」という基本的考えの下に、要求と仕様を使い分け、それらを階層で表現することで仕様モレを起こさずに表現する方法。また階層構造にすることで「1つの文書」になり要件管理も容易になる。 ※「『派生開発』を成功させるプロセス改善の技術と極意」(技術評論社) …(XDDP)現実の大部分は派生開発であるにも関わらず、間違ったアプローチで失敗を重ね混乱を繰り返している。XDDPは、筆者の経験の中で生み出した派生開発を成功させる独自の開発アプローチです。他著書:「SEの仕事を楽しくしよう」(SRC刊)、「わがSE人生に一片の悔いなし」(技術評論社) ◆定 員:45名 ◆対 象:ユーザー企業やベンダー企業にて情報システム開発に携わる、管理者、担当者、プロジェクトマネージャー ◆参加費:JUAS会員/ITC:31,500円 一般:39,900円(消費税込み、テキスト込み) |
開催期間 | 2012年11月15日 |
有料/無料 | 有料 |
種別 | 研修会 |
テーマ | 技術・技能 |
問い合わせ先 |
社団法人日本情報システム・ユーザー協会 TEL:E-mail: |
詳細ページ | http://www.juas.or.jp/seminar-event/open_seminar/detail.asp?SEMICODE=414066 |
情報提供機関 | 福井県産業情報ネットワーク |
更新日 | 2012年04月19日 |