お知らせ お問い合わせ 無料会員登録 Eureka Box紹介ページトップ ログイン

USDM学習
内容紹介

USDM 学習

このコースでは、これからUSDMを学んでいきたいという人から、書き始めている人、すでにたくさん書いている人に向けて、コンテンツを用意しています。

以下では、コンテンツの先頭部分を少しお見せします。リンク先は有料コースです。一部のコンテンツは体験版として公開しており、無料会員登録でご覧いただけます。

《ビギナー》

USDMとは

コンテンツ名 内容
USDMとは そもそもUSDMとは何なのか？を簡潔に説明します。 USDMとは USDMは、“Universal Specification Describing Manner”の略で、正確な要求仕様を定義するための仕様化の技法です。 USDMの技法は、表記法プラス考え方で構成されており、要求仕様記述のマナーにあたります。 USDMの提唱者 USDMは、株式会社シス... ＜続きを見る＞
USDMのメリット はじめに USDMによって、モレやミス、勘違いに気づき、手戻りを防止できるというメリットがあります。 それだけではありません。エンジニアにもメリットがあります。 ここでは、さまざまなUSDMのメリットを紹介します。 USDMで解決できる問題 USDMは、要求から仕様を引き出す形で階層化して整理している点が特徴です。 要求と仕様を整理すると、開発の中で生じる問題を解決できます。 仕様... ＜続きを見る＞
役割別USDMのメリット USDMには「要求する人」と「作り手」のギャップを埋める効果があります。それ以外の役割でも、USDMによるメリットがあります。 ここでは、役割別のUSDMによるメリットをご紹介します。 プロジェクトにおける役割 プロジェクトには様々な役割があります。・要求者はその名の通り、要求する人を指します。・要件定義者は、要求者の要求を整理して作り手と合意するための文書を作成します。・責任者は、... ＜続きを見る＞
USDMを書いた後のうれしさ USDMによってモレやミス、勘違いに気づき、手戻りを防止できます。しかし、メリットはそれだけではありません。USDMを設計やテストにつなげることで、さらにメリットが増えます。ここでは、USDMを書いた後のうれしさについて紹介します。 USDMを設計につなげる USDMで定義した要求仕様は、具体的な仕様記述に落とし込まれているため、「作業指示」とみなすことができます。 要求仕様の「文言」... ＜続きを見る＞
USDM導入例 USDMでどのような効果があるのか疑問に思っている方も多いと思います。 ここでは、USDMのメリットを身近に感じていただくために、実際の現場でUSDMを導入して効果を上げた２つの事例をご紹介します。 例1 バラバラな仕様書から統一仕様書へ 1つめの例は、自動車の1つのサブシステムの開発です。プロジェクト規模は約30名です。このプロジェクトの問題は、分冊の各要求仕様書の粒度が異なり、内... ＜続きを見る＞

要求仕様定義工程の全体像

コンテンツ名 内容
要求の大事さと要求開発の問題 要求はV字モデルの左上に位置し、開発のスタート地点にあたります。 しかし、「こんな商品、サービスを作ろう」と企画段階で決まっても、そこからあまり要求を具現化しないまま「どのように」実現するかが先走り、要求仕様がモレることもあります。結果、思っていたものと違う、と利用者に受け入れられないことも。 ここでは、要求の大事さと要求開発の問題を紹介します。 要求の大事さIPAの資料によると、... ＜続きを見る＞
要求開発の全体像 「要求仕様は実際にどのように定義して、どこまで定義すればいいの？」、「要求仕様、要件定義、機能仕様などいろいろあるけど違いがよくわからない」。そういった疑問に答えるため、要求開発の最初に覚えておくべき事柄や、要求開発の全体像を紹介します。 用語の整理要件定義のフェーズでは、要望、要件、要求仕様など、様々な用語が使われています。企業によってそれぞれ定義があるかもしれませんが、本コースでは... ＜続きを見る＞
世の中の要求定義とUSDM 要求仕様の定義で一般的な書き方とはどのようなものでしょうか？ 実際の現場では、要求仕様は文章で記述するため、自由に記述している仕様書をよく見かけます。一方、世の中にはIEEEで要求定義の標準が定められていますが、USDMとの関係、位置づけ、違いなどは気になると思います。 ここでは、世の中の要求仕様定義とUSDMについて紹介します。 要求仕様定義の標準要求仕様定義には、いわゆ... ＜続きを見る＞
スコープ定義とステークホルダ定義 要求の範囲、スコープが定まっていないと、本来定義すべき要求が範囲外となり、要求がモレてしまいます。また、スコープが定まっていないと、要求する人、ステークホルダも定まらないため、要求を獲得する上で、これらの定義は非常に重要です。 ここでは、スコープ定義とステークホルダ定義を紹介します。 スコープ定義スコープ定義では、開発対象のシステムとシステム外部との境界を明確にします。スコープを定義... ＜続きを見る＞
困りごとから要求を引き出す 要求を書きましょう、と言ってもいきなりは難しいと思います。利用者の要求をうまく引き出せば書けそうですが、どのように引き出せばよいでしょうか。メーカーの新商品のように、価値を前面に出す場合は書けそうですが、しっかり要求として整理しないと仕様がモレてしまいます。 ここでは、ユーザーの困り事から要求を引き出し、USDMにつなげる方法を紹介します。 ユーザーの困りごと ユーザーは、最初は不便と思っ... ＜続きを見る＞
ジャーニーマップを活用して要求を引き出す 世の中にはさまざまな要求獲得の方法があり、その1つであるカスタマージャーニーマップは要求開発で広く利用されています。カスタマージャーニーマップは、マーケティングから広がった手法で、ユーザーとサービスや商品との関わりから、ユーザの行動を詳細に記述し、見える化するという特徴を持っています。では、ジャーニーマップで獲得した要求をUSDMにつなげるにはどうすればよいでしょうか？ ここでは、ジャーニ... ＜続きを見る＞

USDMの書き方

コンテンツ名 内容
USDM作成の流れ ここでは、USDMの作成の流れを紹介します。 USDM作成の流れ要求仕様をUSDMで整理する場合の流れは、非常にシンプルです。最初に、要求を記述します。次に、要求を分割・階層化します。最後に仕様を導出します。詳しく見てみましょう。 要求を記述する要求分析の結果をもとに、「目的語+動詞」でシステムで達成したいことの振る舞いを記述します。例えば、・システムを起動したら、前回の設定... ＜続きを見る＞
USDMの基本的な構成 はじめに USDMの構成要素は７つあります。１つ１つ説明します。 ①キーワードラベル 1番目は、キーワードラベルです。キーワードラベルは、エクセルではA列に相当し、馴染みの用語や別名を添えて、要求や仕様の一覧性を良くします。 要求を一言で表現したものがラベルです。 ②要求 2番目は要求です。要求は、目的語と動詞を使って振る舞いを表現し、仕様化の範囲、つまりゴールを明確... ＜続きを見る＞
理解度チェック：構成要素 USDMの構成要素の名称を確認しましょう。 ＜続きを見る＞

《ベーシック》

コンテンツ名 内容
USDMにおける要求と仕様の定義・関係 USDMの構成要素の中で最も重要な要素は「要求」と「仕様」、およびそれらの関係です。ここでは、その重要な要求と仕様の関係について紹介します。 要求と仕様の定義、関係 あらためて、要求仕様の定義を確認します。 USDMでは、要求は「実現してほしいこと」であり、ゴール・目的を達成するシステムに求められることです。 仕様は、「作るべきもの」に対する具体的な記述で、関係者間でSpecifyされ... ＜続きを見る＞
要求と仕様が書き分けられていない例 この講座では、要求と仕様が書き分けられていない例をご紹介します。 はじめにUSDMの要求と仕様は、次のような関係です。要求：実現してほしいことであり、ゴール、目的を達成するためにシステムに求められる事柄仕様：作るべきものに対する具体的な記述しかし、頭でわかっていても、実際に記述してみると、要求と仕様がうまく書き分けられていないことがあります。ここでは、うまく書き分けられていない例と改善... ＜続きを見る＞

要求

コンテンツ名 内容
要求の役割 USDMでは、要求は仕様を引き出すという、重要な役割を果たします。ここでは、そんなUSDMにおける要求が果たす役割について説明します。 USDMにおける要求 USDMにおける要求とは、システムに求められる機能や性能、作り方に対する品質など、実現したいことを抽象的に表現したもので、大きく次の４つに分類できます。・システムや製品に求められる振る舞いとしての機能要求・パフォーマンスなどの機能... ＜続きを見る＞
要求の構成要素 USDMにおける要求定義は、単に要求を記述するだけではありません。ここでは、要求を支える要求の構成要素を紹介します。 要求の構成要素 要求の構成要素は、「要求」、「理由」、「説明」の３つです。「要求」には、動詞を使って振る舞いを表現し、仕様化の範囲を明確に記述します。また、個々の要求を特定するため、固有のIDを振ります。「理由」には、関係者間の認識のズレを抑えるために、その要求が必要な... ＜続きを見る＞
要求の書き方 USDMの要求の役割・構造を理解し、いざ要求を記述しようとしても、いきなり記述する事は難しいと思います。 要求を記述したつもりでも、仕様を導き出せなかったということもあるでしょう。 ここでは、仕様を導き出せる良い要求の書き方を具体例を交えて紹介します。 要求の書き方 ある特定の範囲で仕様をうまく導き出せるように要求を記述するには、システムがどのように動いてほしいかを具体的に表現しま... ＜続きを見る＞
要求を書く視点 USDMはどんな視点で、どんな粒度で書けばいいの？という質問が多くあります。誰の視点で、どういうことを書けばよいかが定まっていないと、文章は書けません。 そんな要求の視点について説明します。 USDMの要求の視点 要求の視点には、WhoとWhereがあります。Whoは要求者の視点で、ユーザー、保守担当などシステムに何かしらの要求をする人を指します。Whereは要求の対象をどこから見る... ＜続きを見る＞
理解度チェック：マウスの要求 「ソフトウェア要求」としてどのような記述をすればよいか、確認してみましょう。 ＜続きを見る＞
理解度チェック：ドライブレコーダーの要求 「ソフトウェア要求」としてどのような記述をすればよいか、確認してみましょう。 ＜続きを見る＞
要求を認定仕様とする USDMは要求を分割・階層化して仕様を引き出すのがマナーですが、プロジェクトによっては、十分わかっていることを正確に記述することは労力がかかるため避けたいことがあります。 そんなときに役に立つ「認定仕様」について紹介します。 全ての要求を均一に書かなくても良い おさらいになりますが、USDMは要求者と開発者の間で、システムに望むことの認識を合わせるために記述します。しかし、要求者と開... ＜続きを見る＞
理由の役割 USDMにおいて、要求の理由には、要求する人と作り手の認識のズレを抑えるため、その要求が必要な理由を明示します。しかし、実際の現場では、「理由？何を書けばいいのかわからない」といった戸惑いが多くみられます。理由の役割が分かれば、積極的に書こうという気持ちになるかもしれません。 ここでは、そんな理由の役割を紹介します。 理由の役割 要求には、それが必要な理由があります。要求の裏に困りご... ＜続きを見る＞
理由の書き方 理由は？と聞かれると、自明なものもあれば、要求を受け取っただけで、理由までは分からない、といった状況はよくあることです。 理由に書く観点・種類がわかれば、その要求がどれに該当するか考えることで理由が書きやすくなります。 ここでは、そんな理由の書き方を紹介します。 理由の書き方 理由に書く観点・種類は４つあります。1つ目は、ユーザーの困りごとの解決です。逆に考えると、ユーザーの困りご... ＜続きを見る＞
理解度チェック：理由の書き方 ＜続きを見る＞
説明の書き方 ここでは説明の書き方を紹介します。 はじめに USDMのフォーマットを見て、説明の欄には何を書けばいいんだろう、と思った人も多いと思います。説明は、要求と理由以外の事を書く場所です。動きの事例、前提事項、用語の説明、要求の背景など、要求と仕様の理解を助ける内容を記述します。 説明欄の背景 はじめは、USDMに「説明」という欄はありませんでした。そのような状況では、要求に要求以... ＜続きを見る＞
要求、理由、説明の書き分け USDMの要求には、要求のほかに、理由、説明を記述しますが、要求の中に理由が入り込んでいるなど、うまく書き分けられていない例をよく見かけます。実際に書いていると、これは要求か？理由か？と迷い、実は要求である振る舞いが説明の中に書かれていることもあります。 ここでは、要求、理由、説明の書き分けについて紹介します。 書き分けに迷った場合書き分けに迷ったら、以下のように判断します。最終的に... ＜続きを見る＞

要求の分割・階層化

コンテンツ名 内容
要求を分ける 要求が複雑であったり、要求の範囲が広すぎると、モレやミスが生じやすくなります。また、USDMのマナーに沿って1つの要求は書けても、システム全体の要求を書くのが難しい場合もあります。 USDMには、要求の範囲を段階的に小さくし、モレやミスを防ぐ方法として「要求の分割」「階層化」「グループ化」の３つがあります。ここでは、その３つの方法について紹介します。 要求を分ける考え方要求を分ける考... ＜続きを見る＞
要求の分割基準 要求のヌケモレを防ぐ方法の1つに「分割基準」があります。ここではこの分割基準について説明します。 要求の分割基準 要求の範囲が広すぎると、下位要求や仕様が発散してモレが生じやすいため、明確な基準を用いて分割します。USDMには「時系列分割」、「構成分割」、「状態分割」、「共通分割」の４つの分割基準があり、状況ごとに適したものを選択します。 要求の分割基準 USDMの４つの分割... ＜続きを見る＞
時系列分割 ここでは、時系列分割の詳しい方法や例を紹介します。 時系列分割 時系列分割はUSDMの要求を分割する基準の一つで、時間軸に沿った動作や処理で要求を切り分けます。 時系列分割の基本 上位の要求が、時系列、つまり時間に沿った順序のある動きを示しているときは、要求を分割したあとにその順番に並べます。例えば、このように「設定して」→「作動させる」 というような順序のある動き... ＜続きを見る＞
構成分割 ここでは、構成分割の詳しいやり方や例を紹介します。 構成分割 構成分割は、USDMの要求を分割する基準の一つで、時間的な順序を持たない機能や種類で要求を切り分けます。 構成分割の基本 構成分割では、「機能」や「構成」、例えばコマンド、種類、独立した機能、ハードウェア構成などで分割します。これらは時間的な順序を持たないものです。例えば、上位要求を機能単位で分割したり、下位要求を... ＜続きを見る＞
状態分割 ここでは、状態分割の詳しいやり方や例を紹介します。 状態分割 状態分割は、USDMの要求を分割する基準の一つで、状態に従って要求を切り分けます。 状態分割の基本 状態図などで洗い出した状態をもとに要求を分割します。この例では、「停止中」という状態と「動作中」という状態それぞれで下位要求を切り分け、その状態で求められる要求と仕様を記述します。記述する内容は、それぞれの状態にいる... ＜続きを見る＞
共通分割 ここでは、共通分割の詳しいやり方や例を紹介します。 共通分割 共通分割は、USDMの要求を分割する基準の一つで、複数の要求に共通する部分を切り出し、独立した要求にします。 共通分割の基本 要求を分割していると、同じ下位要求が複数の上位要求の中に共通して出現することがあります。例えば、どの機能でも共通に行われる表示についての要求などです。この要求をそれぞれで仕様化したり、面倒だ... ＜続きを見る＞
理解度チェック：分割基準 分割基準が理解できているか試してみましょう。 ＜続きを見る＞
要求の階層化 ここでは、要求の階層化について、詳しいやり方や例を紹介します。 階層化 要求の範囲が広すぎるとモレが生じやすくなるため、２階層に階層化します。 動詞単位で分割 階層化の基本は、動詞を基準にする方法です。まずは上位要求の動詞を時系列に分割し並べてみましょう。これが実際の例です。「設定した」、「鳴らして」、「停止できる」の３つの動詞を時系列に分割して並べています。 隠れ... ＜続きを見る＞
強制2層 要求を上位要求、下位要求に階層化した時、要求によっては1層でよく、階層化する必要がない場合があります。そのような場合、どのように要求を記述すればよいのでしょうか。 ここでは、範囲が広い要求と狭い要求が混在している場合の階層化の方法を紹介します。 階層化階層化は、上位要求の範囲を小さくして単純な要求にすることで、仕様の発散を防ぐ効果があります。しかし、要求によっては階層化するまでもない... ＜続きを見る＞
要求のグループ化 下位要求の数が多くなったときに役に立つ「グループ化」について紹介します。 グループ化とは 要求の範囲や粒度によっては、分割した下位要求の数が多くなり、モレに気づきにくくなります。その場合には、共通項で「グループ化」し、範囲を限定します。例えばこの例のように、下位要求をグループ化します。このとき、グループは「動詞性名詞」、つまり動作を表す名詞の形式で記述します。 グループ化の方... ＜続きを見る＞

仕様

コンテンツ名 内容
仕様の役割 普段、詳細設計やプログラミングをされている方は、要求より仕様のほうが身近に感じられると思います。しかし、要求とのつながりを意識したり、抜け漏れのないように仕様を導き出すとなると難しく感じる方も多いようです。USDMならではの仕様記述マナーを習得して、モレやミスによる手戻りといった時間のムダをなくしましょう。 仕様の条件 仕様とは、要求に含まれる「具体的」な処理や振る舞いを表現したもので... ＜続きを見る＞
仕様の“Specify”とは 仕様はどれくらい細かく書けばいいの？という疑問をお持ちのかたも多いと思います。USDMには仕様を「Specify」できるまで書きましょう、というマナーがありますが、どこまで書けばよいのかピンと来ないかもしれません。 ここでは、そんなUSDMの「Specify」について説明します。 USDMの仕様 仕様は、開発者および関係者が「Specify（特定）」できる状態まで具体化しなければなり... ＜続きを見る＞
仕様の書き方 仕様では「Specify」することが大切だと頭では分かっていても、実際に書こうとすると手が止まる、という人も多いのではないでしょうか。ここでは、USDMの「Specify」できる仕様を、どういう手順で、どのように書いていけばよいかを説明します。 仕様の導出 仕様は、要求の目的語と動詞から導出します。要求を階層化している場合は、下位の要求から導出することになります。「◯◯の時、（目的語）... ＜続きを見る＞
仕様の分類 仕様記述を広く見渡すと、書かれている内容をいくつかに分類できることに気づきます。ここでは、これらの分類を網羅し、具体的に説明します。このようなポイントを押さえておくことで、モレなくスムーズに仕様を記述することができます。 仕様の分類 仕様に書く内容は、4つに分類できます。・条件と動作：どのような条件のときにどのような動作を行うかを記述します。・定義：値の範囲や、規定値などがこれに当たり... ＜続きを見る＞
仕様の理由・説明 要求から導出した仕様は、そのままで腑に落ちる記述になっていることがほとんどです。しかし、記述によっては、「なぜこの仕様になったのか」と思う場面もあります。 そのような場合、仕様にも理由と説明が必要です。ここでは、仕様における理由と説明の記述マナーを紹介します。 「仕様の理由と説明」の背景 USDMのマナーが固まる以前は、仕様にも要求と同じように「理由」と「説明」がありました。しかし、... ＜続きを見る＞
仕様のグループ化 仕様の数が多くなると、ただ羅列されているように見えて可読性が落ちます。よってミスやモレに気づきにくくなります。 USDMでは、仕様の記述も要求と同じ分割基準を使用してグループ化します。このグループ化により、分かりやすさが向上し、ミスやモレに気付きやすくなります。 ここでは、仕様の整理に有効な、仕様のグループ化について説明します。 仕様のグループ化 仕様のグループ化には、要求と同じ分... ＜続きを見る＞
仕様から要求を立てる 要求より先に仕様が思いついた場合に、どのように要求仕様を整理していけばよいかを紹介します。 はじめに 仕様のほうが具体的でわかりやすいため、要求より先に仕様が思いつく場合があります。また、仕様を記述していると、要求と仕様の不一致が起こることがあります。そのような場合には、どのように要求仕様を整理していけばよいでしょうか。 仕様が先に思いつく場合 仕様が先に思いつく状況としては... ＜続きを見る＞
仕様とソースコードの違い 仕様をSpecifyすると、ソースコードのように詳細な記述になることがあります。実際の開発現場では、最初は気を付けていても、いつの間にか、作り手目線で記述するようになっているケースもよく見かけます。 ここでは、USDMの仕様とソースコードの違いを紹介します。仕様とソースコードの違いを理解し、仕様を正しく書けるようになりましょう。 機能仕様と実装仕様機能仕様は、実現手段に依存しない、要求を実... ＜続きを見る＞

ラベル

コンテンツ名 内容
ラベルについて ここでは、USDMのラベルについて、詳しくご説明します。 はじめに USDMの要求記述の文章が長く分かりにくくなってしまっても、ラベルを見れば、「なんだ、そのことか」と、一目で理解できることがよくあります。昔は、カテゴリと呼ばれていましたが、今は「ラベル」が定着しています。要求にはキーワードラベル、仕様には仕様ラベルを用います。 キーワードラベルの書き方 キーワードラベルには... ＜続きを見る＞

《アドバンスト》

非機能要求

コンテンツ名 内容
機能要求と非機能要求の違い この講座では、機能要求と非機能要求の違いについて紹介します。 はじめに「USDMにおける要求の役割」講座の中で、USDMにおける要求は、大きく４つに分類できると説明しました。このうち、「システムや製品に求められる振る舞いとしての機能要求」が機能要求に分類され、「パフォーマンスなどの機能に付随する品質要求」、「保守性などの作り方に対する品質要求」、「法規、特許、利用できる技術などの制約」... ＜続きを見る＞
非機能要求と品質要求の関係 この講座では、非機能要求と品質要求の関係について紹介します。 はじめに非機能要求には、・パフォーマンスなど、機能に付随する品質・保守性など、作り方に対する品質・法規、特許、利用できる技術などの制約があると説明しました。一方で、品質要求という言葉もよく聞きますが、非機能要求と品質要求とはどのような関係なのでしょうか？ 非機能要求と品質要求非機能要求と品質要求の関係についてみてみ... ＜続きを見る＞
非機能要求の分類 ISO/IEC25010 製品品質モデル この講座では、非機能要求の分類に使える「ISO/IEC25010製品品質モデル」について紹介します。 はじめに非機能要求には、・パフォーマンスなど、機能に付随する品質要求・保守性など、作り方に対する品質要求・法規、特許、利用できる技術などの制約がありますが、振る舞いでないためイメージしにくく、ヌケモレが生じやすい面があります。非機能要求の導出のヌケモレを防止するために利用できるものに、... ＜続きを見る＞
非機能要求の分類 EAST-ADL この講座では、「EAST-ADL」に定義された非機能要求の分類について紹介します。 はじめに非機能要求には、・パフォーマンスなど、機能に付随する品質要求・保守性など、作り方に対する品質要求・法規、特許、利用できる技術などの制約がありますが、振る舞いでないためイメージしにくく、ヌケモレが生じやすい面があります。非機能要求の導出のヌケモレを防止するために利用できるものに、ISO/IEC25... ＜続きを見る＞
非機能要求のUSDM記述 非機能要求には、次のようなものがあると説明しました。 パフォーマンスなど、機能に付随する品質 保守性など、作り方に対する品質 法規、特許、利用できる技術などの制約 では、非機能要求はUSDMではどのように記述すればよいのでしょうか。ここでは、非機能要求のUSDM記述について説明します。 非機能要求のUSDM記述非機能要求のUSDM記述には、これまでに学んだUSDMの記述... ＜続きを見る＞

導入・プロセス

コンテンツ名 内容
【未】レビュー 【近日公開予定】 ＜続きを見る＞
【未】構成管理 【近日公開予定】 ＜続きを見る＞
【未】トレーサビリティ 【近日公開予定】 ＜続きを見る＞
【未】変更管理 【近日公開予定】 ＜続きを見る＞
【未】見積もり 【近日公開予定】 ＜続きを見る＞
【未】形骸化防止 【近日公開予定】 ＜続きを見る＞
【未】変更要求仕様への活用 【近日公開予定】 ＜続きを見る＞

まずは無料でお試しを！

無料会員登録
Close