エンタプライズ系事業/機能要件の合意形成技法 | アーカイブ | IPA 独立行政法人 情報処理推進機構
発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に「ギャップ」が生じます。具体的には、次の（1）～（3）のようなギャップが生じます。 要件定義すべき内容が抜けており、開発者に説明していない。 発注者が開発者に説明したが、何らかの理由で漏れた。 開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するための次のようなコツを集めたものです。 実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ 発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ 機能要件の合意形成ガイドは、「概要編」 と次の6つの技術領域のコツをまと
コンサルタントがよく使うRFPの書き方：12項目で網羅的に作成
情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。 新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト（月単価150万円以上）であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根本的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。 そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用い
「早期に」「誤解なく」「漏らさずに」非機能要求グレードを使いこなす
性能や信頼性、保守性といった非機能要求は情報システムの高度化・大規模化が進むに伴って、その重要性が改めてクローズアップされている。あいまいにしたままシステム開発を進めるのはあまりにもリスクが大きいからだ。 こうしたなか「システム基盤の発注者要求を見える化する非機能要求グレード検討会」はこの5月に非機能要求グレードを公開した（図1）。検討会はNTT データ、富士通、NEC、日立製作所、三菱電機インフォメーションシステムズ、OKIの6社が2008年4月に共同で発足させた。 非機能要求グレードの目的は、「早期に」「誤解なく」「漏らさずに」非機能要求を発注者が受注者と共同で定義して、かつ、合意できるようにすること。これまでの非機能要求定義の難しさを克服するため、非機能要求で決めるべき項目を定め、その具体例を段階的に「見える化」することで、発注者が非機能要求を決めやすくしている。 「機能以外」だから
要件定義を得意ワザにしよう
「システム開発で、何が一番難しい？」と尋ねられたら、「要件定義」と答える人が多いのではないか。ユーザーが何を望んでいるのか的確につかみ、ときとして関係者間で対立する要望を整理し、システムの要件にまとめて関係者の合意を得なければならない。技術者からは「いろいろ神経使うし、大変だよね…」という声が聞こえてきそう。 要件定義のスキルを磨くには「知識＋実践」が不可欠だ。ここでは要件定義に関する好評連載・特集をピックアップした。これらの手法やノウハウを使って、より良い要件定義ができるよう、実践に役立てていただければ幸いである。 認識のズレや要件の抜けを防ぐ「詰めの質問術」 システムの出来が見違える コツ1●言葉の定義を聞く コツ2●言い換えて聞く コツ3●タイミングを聞く コツ4●なぜ必要なのかを聞く コツ5●そうではないケースを聞く コツ6●順番が逆のケースを聞く コツ7●状態の変化に注目して聞く
要件定義支援ツール「要件のツボ」によるRDRAの実践
普段UMLを使っていない方に、UMLを使った要件定義の話をしてもなかなか受け入れられません。重要なことは要件の定義であり、UMLの表記法やツールの使い方を覚えることではありません。そこで今回から、UMLを使わずに簡単な入力でスムーズに要件定義の情報をまとめられる「要件のツボ」を紹介します。 はじめに 普段UMLを使っていない方に、UMLを使った要件定義の話をしてもなかなか受け入れられません。「要件定義したいのであってUMLを覚えたいわけではない」あるいは「要件定義を行うためにわざわざUMLを覚える時間はない」などの声が返ってきます。それはもっともで、重要なことは要件の定義であり、UMLの表記法やツールの使い方を覚えることではありません。 そこで今回から、UMLを使わずに簡単な入力でスムーズに要件定義の情報をまとめられる「要件のツボ」を紹介します。 個別の情報を「表形式」で並べて表現する 第
超上流の実践手法「要求開発」を理解する - 週末スペシャル：ITpro
連載「超上流を極めるための『要求開発』入門」が完結しました。 「要求開発」とは、業務をデザインしながら段階的にシステム要求を導いていく活動のことで、「オープンソロジー」と呼ぶ方法論に基づいています。対象とする範囲は、BA（ビジネスアナリシス）と同様、「システム企画」に該当します。 本連載では、システム開発の前段階に要求開発を適用する方法を、ホワイトバードという架空のクリーニングチェーン店でのシステム再構築プロジェクトを題材に、易しく解説しています。連載を読むことで、システム化の出発点となる正しい要求を導き、定義するための要求開発の実践方法が、初心者でも理解できます。ぜひ、ご一読下さい。 連載記事 第1回 BA/BABOKが注目される背景と「要求開発」が必要な理由 第2回 プロジェクトの基本情報を整理する 第3回 要求を整理し、ゴールを設定する 第4回 現状業務の全体像を把握する 第5回 新
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
漁業ナビ - 【漁師向け】船具・漁具のおすすめ情報を紹介
2024.06.20 ガラス玉編は、網のブイ（浮袋）で使用する漁具です。 海沿いにあるお土産店などでガラス製の丸い形をしていて、紐でそれを固定している飾りのようなものを見たことがある人は多いかと思われますが、それはお土産品で大きいものが漁具のガラス玉編です。 ガラスといっても中が空洞になっていて水に浮かぶため、網を水面に浮かせるときに便利です。 なお、ガラス玉網には、網のサイズや引き上げるときの重量など、適切な大きさの […]
構造に沿って要件をUMLで具体的に定義する
はじめに 「上流工程で作成するドキュメント」というとWordやExcelなどを使い、自然言語（文章など）で表したものをイメージすると思います。しかし、昔から自然言語での表現はあいまいになることが多く、仕様としては適さないことが指摘されています。 皆さんも過去に意味不明な要件定義書を受け取ったことや、「いろいろ書いてあるけど重要なのはたった1行だった」あるいは粒度がバラバラで統一感のないものなどさまざまな要件定義書を見てきたと思います。 前回は要件定義には構造があり、その構造を使うことで要件をスムーズに定義できることを紹介しました。今回はその構造に沿った具体的な定義の方法をご紹介します。 リレーションシップ駆動要件分析（RDRA）は、その名のとおりリレーションシップが重要な意味を持ちます。その情報のつながりを直接表現できる図的な方法としてUMLを使います。 UMLを使って要件を定義する 視点
間違い1「利用者視点しかない」
「セキュリティ対策は大事だ」。そう分かっていても、どこかで「メインはシステム本体の開発、セキュリティは二の次」「セキュリティ対策は後から考えればよい」といった意識を持っていないだろうか。そんな意識が、セキュリティ設計に思わぬ間違いを生み、システムの脆弱性を作り込む。 悪人になって攻撃 一つ目の間違いは、システムの機能を利用者視点でしか考えないというものだ。要件定義において、利用者に提供する機能はきちんと洗い出したとしても、その機能が悪用されたらどうなるかを逐一チェックしているだろうか。セキュリティ設計は本来、悪意を持った者がシステムを利用しようとするのを防ぐ対策を考えること。業務要件をまとめるための正規利用者の視点でシステムを見ている限り、起こり得るリスクは洗い出しきれない。 正規利用者に提供する機能を洗い出すには「ユースケース図」がよく用いられる。ユーザーや外部システムを表す「アクター」
第2回 「応答一律3秒」という性能要件はやめよう
今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。 システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0～午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。 （1）全機能の処理時間を同じレスポンス時間に収めなければならない 全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。 例えばコールセンターのシステムで、「（a）電話オペレーターが操作する画面」と「（b）管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる（a）の方が、求められるレスポンス時間は
第1回 性能品質は開発工程全体で作り込もう
性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。 そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。 ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです（図1）。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。 本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方
1500枚の要件定義書に困惑、リスト化し設計レビューを進める
1. 1日の処理量が1000万件にも達する株式売買システムを新たに開発 2. 要件定義書から要素を洗い出したチェックリストを作り，設計書をレビュー 3. 取引結果の書き込み処理時間が想定外の長さ。処理の分散を図って乗り切った 2010年1月4日，稼働を開始したシステムがある。東京証券取引所の株式売買システム「arrowhead（アローヘッド）」だ。「ITエンジニアとして20年以上のキャリアがあるが，こんな“静かな”カットオーバーは初めてだ」。こう語るのは，arrowhead開発プロジェクトのリーダーを務めた，東京証券取引所の宇治浩明氏（IT開発部 株式売買システム部長）である。 開発プロジェクトには，東京証券取引所側から最大で70人，開発ベンダーである富士通側から最大500人が参加。初期投資だけで130億円に上る大規模なプロジェクトである。 arrowheadは，100社ほどの証券会社から
第1回 BA/BABOKが注目される背景と「要求開発」が必要な理由
昨今、ソフトウエア開発の分野では、「BA（ビジネスアナリシス）」が注目されるようになってきました。BAは、システム化の前段階で、要求分析や業務分析を通じて、システムの担うべき役割を導き出す活動のことです。2009年8月には、IIBA（International Institute of Business Analysis）日本支部がBAの知識体系をまとめた「BABOK（Business Analysis Body of Knowledge）」の翻訳本を発売しました。これをきっかけに、BAはますますホットな話題となってきています。 本連載では、このBAを実践するための具体的な方法である「要求開発」について、その概要から、プロジェクトへの適用方法までを解説します。これからBAを実践したいと考えている人は、ぜひ参考にしてください。第1回は、イントロダクションとして、BAが重視される背景と、要求開
第2回 BABOKにとっての“超上流”とは
「BABOKを読んだがよく理解できない」という声をよく耳にする。BABOKは知識体系でありプロセスや方法論ではない。このため、ビジネスアナリシスの具体的な手順を知りたいと期待して読んでも、抽象的な記述からは具体的なビジネスアナリシスの活動のイメージにつながらず理解しがたい---ということかもしれない。 記述が抽象的である理由のひとつは、BABOKが意図的に「ビジネスアナリシスの対象とする問題領域を限定していない」ことにある。BABOKでは、この問題領域のことを「ドメイン」と呼ぶ。定義は以下のとおりだ。 ドメインとは、ビジネスアナリシスの対象となる領域のことである。領域の境界はさまざまである。組織または部署がそのままドメインになる場合もあれば、組織の外にいる主要なステークホルダーやステークホルダーとの相互作用がドメインとなる場合もある。 「ドメイン」が限定されないということは、解決すべき問題
要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/sec/old/users/events/events_tokyo_20170310-2.pdf
「要件定義」の4つの構造と依存関係に着目した実践手法
要求定義書と仕様書の海で溺れないための10分でできる要件変更対策