1. HOME
  2. USDM用語集

USDM用語集

USDM関連用語集

ア行

IEEE29148

システムとソフトウェアの要求定義に関する国際標準。要求で定義すべき項目が記載されている。「どのように記述すればよいか」までは記載されておらず、その部分をUSDMで補うことができる。

IEEE830

ソフトウェア要求仕様の国際標準。IEEE29148と似た項目が定義されているが、830の特徴として、要求の8つの品質特性(正当性、非曖昧性など)が定義されている点が挙げられる。USDMのマナーに沿って記述することで、ほとんどの特性を満たすことができる。

1行1仕様

USDMの仕様の書き方。Excelの仕様の1行には1つの仕様だけを書く、という考え方。

カ行

階層化

複合的な要求を単純な複数の下位要求分けること。要求の範囲が広すぎるとモレが生じやすくなるため、要求を階層的に表現することで1つの要求の範囲を小さくする。

カスタマージャーニーマップ

ユーザーとサービスや商品との関わりからユーザの行動を詳細に記述し、見える化するという、マーケティングから広がった手法で、要求開発で広く利用される。カスタマージャーニーマップでは、ペルソナと呼ばれる特定のユーザーが商品やサービスを利用する際の、ニーズを満たすために必要なシステムとのやり取り、その時のユーザーの感情、商品やサービスに対する不満・課題などを、サービス利用の流れに沿って視覚的に表現する。ここで分析したペルソナの思考や課題が、USDMの理由、説明に当てはまることが多い。

キーワードラベル

USDMの要求に添えるラベル。要求を一言で表現したもの。エクセルのA列に相当し、馴染みの用語や別名を添えて、要求や仕様の一覧性を良くする。

機能仕様

実現手段に依存しない、要求を実現する仕様。「実装仕様」の項も参照。

機能仕様書

システム完成後に、要求仕様書を機能仕様の形に整えたもの。一般的な記述で機能を説明するためのものである。

強制2層

階層化の必要のない要求を強制的に2層に階層化すること。階層化の必要がなく要求の下に仕様を直接書くべき場合でも、周りの要求が階層化されていて、仕様の階層のレベルを合わせたいことがある。そのときには、下位要求を作成し、「同上」と記載する。

共通分割

分割基準の1つ。複数の要求に共通する部分を切り出して独立した要求にする。

グループ

複数の要求(または仕様)をまとめたもの。USDM要求仕様書では< >で囲って記載する。要求や仕様の数が多い場合に、小さな集合に分割して範囲を限定することでモレを防ぐ。動作を表す名詞で記述する。

グループ化

要求や仕様をグループに分類すること。分割した下位要求の数が多くなるとモレに気づきにくくなるため、共通項で「グループ化」し、範囲を限定する。グループは「動詞性名詞」(動作を表す名詞)の形式で記述する。

検証者

プロジェクトにおける役割の1つ。要求仕様に基づいてテストを行う。

構成分割

分割基準の1つ。時間的な順序を持たない機能や構成の単位で要求を切り分ける。

コンテキスト図

1970年代に普及した構造化分析・設計手法の概念。構造化手法ではデータフローダイアグラムの最上位レベルをコンテキスト図と呼ぶ。

サービスや料金について
詳しく知りたい方はこちら

サ行

時系列分割

分割基準の1つ。時間軸に沿った動作や処理で要求を切り分ける。

実装仕様

プログラミング言語などの実現手段を考慮して、機能仕様をどのように実現するかを定義したもの。「機能仕様」の項も参照。

ジャーニーマップ

カスタマージャーニーマップの項を参照。

仕様

「作るべきもの」に関する記述。開発者および関係者が「Specify(特定)」できる状態まで具体化する。要求から導出し、実現可能性と検証可能性が見えるものでなければならない。この仕様を開発者が実現する。

状態分割

分割基準の1つ。状態図などで洗い出した状態をもとに要求を切り分ける。

仕様ラベル

USDM要求仕様書の仕様の行に含まれる白抜きの四角(□)。仕様であることを示すとともに、「レビュー済み/実装済み/テスト済み」などのステータス管理に用いることができる。

スコープ

要求の範囲。スコープによって開発対象のシステムとシステム外部との境界を明確にする。これにより、対象システムの範囲が決まり、ステークホルダが明らかになる。開発現場では、コンテキスト図を使って視覚的に表現することで、全体が俯瞰でき、入出力も把握できる。

ステークホルダ

開発するシステムと直接、間接に関係を持つすべての人。システムを直接利用するユーザーが直接ユーザー、保守担当などの関係者が間接ユーザーであり、直接ユーザーからは主に機能的な要求が、間接ユーザーからは主に作りに関する要求が出てくる。ステークホルダを明確にすることで、要求をモレなく正確に抽出することができる。

Specify

USDMの仕様のあるべき姿。仕様がSpecify(特定)できている状態とは、プログラミング時に何を実現するのか悩まなくていい状態、すなわち、仕様を読めば実現可能性が見え、検証可能性が見えるという状態である。開発者および関係者がSpecifyできる状態まで具体化しなければならない。

責任者

プロジェクトにおける役割の1つ。プロジェクトのビジョン、ゴールを示し、スケジュールや進捗状況の把握、人のアサインなどを行う。

設計者・実装者

プロジェクトにおける役割の1つ。要求仕様書に基づいてソフトウェアを作成する。

説明

要求の構成要素の1つ。「要求には要求、理由には理由、それ以外の事は説明に書く」というのがUSDMのマナー。動きの事例、前提事項、用語の説明、要求の背景など、要求と仕様の理解を助ける内容を記述する。

ナ行

認定仕様

要求だけで実装内容が明確であり、仕様を書く必要がない場合の記述方法。要求のラベル欄に「□」を記述して認定仕様であることを示す。認定仕様の場合、仕様は記述しない。

ハ行

分割

範囲の広い要求を、見通しが良くなるように分けること。1つ1つの要求が範囲を持ち、もれなく、だぶりのないように分割する。

分割基準

要求や仕様を分割する際の視点。「時系列分割」、「構成分割」、「状態分割」、「共通分割」の4つがある。要求の範囲が広すぎると、下位要求や仕様が発散してモレが生じやすいため、このような基準を用いて分割するとよい。

サービスや料金について
詳しく知りたい方はこちら

ヤ行

USDM

“Universal Specification Describing Manner”の略。株式会社システムクリエイツの清水吉男氏が提唱した現場向けソリューションで、どのように作ってほしいかを要求仕様書に記述する際のマナーが示されている。「表記法」と「考え方」で構成されており、正確な要求仕様を定義するための仕様化の技法として利用される。

要求

「システムに実現してほしいこと」であり、ゴール・目的を達成するためにシステムに求められる機能や性能、作り方に対する品質など、実現したいことを抽象的に表現したもの。システムで達成したいことの振る舞いを「目的語+動詞」で記述し、仕様化の範囲、つまりゴールを明確に記述する。要求には、システム要求、ソフトウェア要求といった様々なレベルがあり、レベルごとに要求開発を行って要求仕様を定義する。要求は設計のインプットとなる。

要求開発

「要求獲得」、「要求分析」、「要求仕様化」、「検査と評価」から構成される(REBOKの定義)。USDMでは、このうち要求獲得の一部から要求仕様化までを扱う。

要求獲得

要求開発のフェーズの1つ。求められた要求について調査を行い、要求の範囲(スコープ)を定義し、ステークホルダを特定する。

要求工学

要求仕様化プロセスを工学的に定式化する技術。要求工学の知識体系として「REBOK」(Requirements Engineering Body Of Knowledge)がある。

要求者

プロジェクトにおける役割の1つ。ユーザーや保守担当など、システムに何かしらの要求をする人。

要求仕様化

要求開発のフェーズの1つ。要求仕様を定義する。

要求仕様書

受け取った要望から要求や仕様を抽出、整理してまとめたもの。要件定義書と同じ。システムを新規に作るときに、「どのように作ってほしいか」を記述する。システム完成後は「機能仕様書」の形に整える。

要求分析

要求開発のフェーズの1つ。機能要求の分析、非機能要求の分析を行う。

要件

「要求と仕様」が記述されたもの。要求仕様書と要件定義書は同じ意味合い。

要件定義者

プロジェクトにおける役割の1つ。要求者の要求を整理して作り手と合意するための文書を作成する。

要望

要求者、依頼者が望むこと。ニーズ。

ラ行

理由

要求の構成要素の1つ。関係者間の認識のズレを抑えるために、その要求が必要な理由を記述する。理由を書くことで、要求が洗練され、正しい仕様が導出できるようになる。下位要求も含むすべての要求に記載する。必要であれば仕様にも記載する。

レビュア

プロジェクトにおける役割の1つ。多くの場合、組織のベテランが担う。中間成果物を確認して正しい方向へ導く。