← 一覧に戻る ↓ このページの最下段に移る

JIS X 0166：2014
システム及びソフトウェア技術−ライフサイクルプロセス−要求エンジニアリング 2014制定

番号 用語 定義 対応英語
4.1.1 取得者 供給者から，製品又はサービスを取得又は調達する利害関係者（JIS X 0170:2013及びJIS X 0160:2012）。
注記　取得者（acquirer）に対して通常用いられている用語には，ほかに納入先（buyer）・所有者（owner）・購入者（purchaser）がある。 		acquirer
4.1.2 属性 人手又は自動的な手段によって，定量的又は定性的に識別できる固有の特性又は特徴（JIS X 25000:2010）。
注記　ISO 9000では二つの属性のタイプを区別する。一つは何かに本来備わった永続的な特性，もう一つは製品，プロセス，又はシステムに付与された特性（例えば，製品の価格，製品の所有者）。 		attribute
4.1.3 ベースライン 公式にレビューされ，合意された仕様又は製品で，以降の開発の根拠として使用されるもの。その変更は，公式の変更管理手順を通してだけ認められる（JIS X 0170:2013及びJIS X 0160:2012）。 baseline
4.1.4 組織レベルの運用概念 運用又は一連の運用に関する組織の前提条件・意図を，言葉及び図で，全体像として記述するもの（ANSI/AIAA G-043-1992）。
注記1　組織レベルの運用概念（ConOps）は，しばしば長期戦略計画及び年間運用計画の形で具体化される。後者の場合，その計画内の運用の概念は，同時に実施する又は順次実施する連結した一連の運用を網羅する。この概念は，組織の運用の全体像を与えるために設計される。システムレベルの運用概念（OpsCon）も参照。
注記2　これは，運用スペース・システム能力・インタフェース・運用環境を制限するための根拠になる。 		concept of operations
4.1.5 条件 要求事項を規定する測定可能な定性的属性又は定量的属性。 condition
4.1.6 制約 システム要求事項，設計若しくは実装に，又はシステムの開発・変更に用いるプロセスに，外から求められる制限。
注記　制約は，ソリューションに対して絶対的又は強制的に求められる要因であり，設計変更を制限又は修正させることがある。 		constraint
4.1.7 顧客 製品又はサービスを受け取る組織又は人（JIS X 0170:2013及びJIS X 0160:2012）。
注記　顧客は利害関係者の部分集合である。 		customer
4.1.8 導出要求事項 要求事項の集合及び組織から演えき（繹）又は推量して得られ，特別なシステム構成及びソリューションを導く要求事項。 derived requirement
4.1.9 開発者 ライフサイクルプロセスを通して，開発作業（要求事項分析，設計，受入れテストなどを含む。）を遂行する組織（JIS X 0160:2012）。
注記　開発者は利害関係者の部分集合である。 		developer
4.1.10 文書 人が利用する上で一意に識別される情報単位で，例えば，紙若しくは電子形式のレポート，仕様，マニュアル，又は本（ISO/IEC/IEEE 15289:2011）。 document
4.1.11 人間システム統合 多分野の協働を必要とする技術・管理プロセスで，全てのシステム要素での人間的側面の考察を統合するプロセス。システムエンジニアリング実践に不可欠なものである。
注記　INCOSE SEHbk 3.2.2010から改変。 		human systems integration
4.1.12 抽象度 特定の詳細レベルで対象を見る視点。 level of abstraction
4.1.13 モード 製品に関する特徴又は機能的能力の集合（IEEE Std 1362-1998）。 mode
4.1.14 システムレベルの運用概念 一つのシステム又は関連する一組のシステムの，運用又は一連の運用に関して，組織の前提条件・意図を言葉及び図で記述するもの（ANSI/AIAA G-043-1992）。
注記　システムレベルの運用概念（OpsCon）は，一つ以上の特定システム，又は関連する一組のシステム，を利用する運用の全体像を与えるために設計する。組織の運用環境の中で利用者及び運用者の視点から全体像を与えるものである。組織レベルの運用概念（ConOps）も参照。 		operational concept
4.1.15 運用シナリオ イベントの発生順序を推測して記述するもの。製品又はサービス要素間の相互作用はもちろん，製品又はサービスと，その環境及び利用者との相互作用を含む。
注記　運用シナリオは，システムの要求事項及び設計の評価，並びにシステムの妥当性確認及び検証に用いる。 		operational scenario
4.1.16 運用者 システムの運用を行う実体（JIS X 0160:2012）。
注記1　運用者及び利用者の役割は，同一の個人又は組織に対して，同時に又は順次的に，付与される（JIS X 0160:2012）。
注記2　この用語定義の中で，実体という用語は個人又は組織を意味する（JIS X 0160:2012）。 		operator
4.1.17 要求事項 ニーズとそれに付随する制約・条件とを変換した又は表現する文。
注記1　“requirement”は，通常“要求”又は“要件”と訳される。この規格では，JIS X 0160:2012及びJIS X 0170:2013との整合性を維持するため，通常“要求事項”を用いる。ただし，“要求エンジニアリング”，“要求仕様”など，成語として定着している用語はそのまま用いる。
注記2　要求事項は様々な層に存在し，上位レベルのニーズを表現する（例えば，ソフトウェア要素要求事項）。
注記3　この規格の箇条5で説明するように，一般に要求プロセスはニーズを要求事項に変換するプロセスと考えられる。要求事項には，利害関係者要求事項，システム要求事項，ソフトウェア要求事項，ソフトウェア要素要求事項というレベルがある。したがって，あるレベルの要求プロセスに注目したとき，そのプロセスの前段階で決定された要求事項は上位レベルのニーズの一部になる。例えば，システム要求事項定義プロセスは，システムニーズをシステム要求事項に変換する。このとき，システムニーズには，上位レベルの利害関係者要求事項が含まれる。 		requirement
4.1.18 要求事項引出し システムの取得者及び供給者が，そのシステム及びライフサイクルプロセスに対する要求事項を発見・レビュー・明確化・理解・文書化するプロセス。
注記　ISO/IEC/IEEE 24765:2010から改変。 		requirements elicitation
4.1.19 要求エンジニアリング 多分野の協働を必要とする工学で，取得者の領域と供給者の領域とを仲介し，対象とするシステム，ソフトウェア，又はサービスが要求事項を満足するように要求事項を確立・保守するための工学。
注記　要求エンジニアリングは，要求事項の発見・抽出・開発・分析・検証手法の決定・妥当性確認・伝達・文書化・管理に関わる。 		requirements engineering
4.1.20 要求事項管理 システム，製品，又はサービスのライフサイクルを通じて，要求事項を識別・文書化・保守・伝達・追跡できるようにする活動。 requirements management
4.1.21 要求事項追跡可能性マトリクス 要求事項及びその源をリンクさせ，プロジェクトライフサイクルを通して追跡する表。 requirements traceability matrix
4.1.22 要求事項妥当性確認 要求事項が（個別であれ集合であれ）利害関係者の意図する正しいシステムを定義していることを，試験によって確認すること。
注記　EIA 632:1999から改変。 		requirements validation
4.1.23 要求事項検証 要求事項が（個別であれ集合であれ）整形式になっていることを，試験によって確認すること。
注記1　EIA 632:1999から改変。
注記2　これは，要求事項又は要求事項集合が，良好な要求事項としての特性を獲得するためにレビューされていることを意味する。 		requirements verification
4.1.24 ソフトウェア要求仕様 ソフトウェア及びその外部インタフェースへの要求事項（機能・性能・設計制約・属性）の構造化された集合。
注記　IEEE Std 1012:2004から改変。 		software requirements specification
4.1.25 利害関係者 システムに，権利，持分，請求権若しくは関心をもっている個人若しくは組織，又は，ニーズ及び期待に合致する特性をシステムがもつことに，権利，持分，請求権若しくは関心をもっている個人若しくは組織（JIS X 0170:2013及びJIS X 0160:2012）。
注記　利害関係者には，エンドユーザ・エンドユーザ組織・支援者・開発者・製作者・教育訓練者・保守者・廃棄者・取得者・顧客・運用者・供給者組織・認可者・規制機関が含まれるが，これらに限定するものではない。 		stakeholder
4.1.26 状態 ある一時点での機能若しくは副機能，又は要素の振る舞いを特徴付ける条件（ISO/IEC 26702）。 state
4.1.27 供給者 製品又はサービスの供給に関して取得者と合意を結ぶ組織又は個人（JIS X 0170:2013及びJIS X 0160:2012）。
注記　供給者は利害関係者の部分集合である。 		supplier
4.1.28 対象システム この規格の文脈においてライフサイクルが検討対象となるシステム（JIS X 0170:2013）。 system-of-interest
4.1.29 システム要求仕様 システム及びその運用環境並びに外部インタフェースに対する要求事項（機能・性能・設計制約・属性）の構造化された集合。
注記　IEEE Std 1233:1998及びIEEE Std 1012:2004から改変。 		system requirements specification
4.1.30 トレードオフ 利害関係者にとっての実質利益に基づいて，様々な要求事項と代替解決策とから選定するという意思決定行為（JIS X 0170:2013）。 trade-off
4.1.31 利用者 システムを利用する間，システムからの恩恵を受ける個人又はグループ（JIS X 0170:2013）。
注記1　利用者及び運用者の役割は，同一の個人又は組織の中で，同時に又は順次的に，付与される。
注記2　利用者は利害関係者の部分集合である。 		user
4.1.32 妥当性確認 客観的証拠を提示することによって，特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること（JIS Q 9000:2006）。
注記　システムライフサイクル文脈における妥当性確認とは，意図する用途・ゴール・目標をシステムが達成できることを確実にし確信する一連の活動である。正しいシステムが構築されたかを確認することである。 		validation
4.1.33 検証 客観的証拠を提示することによって，規定要求事項が満たされていることを確認すること（JIS Q 9000:2006）。
注記　システムライフサイクル文脈における検証とは，システムライフサイクル上のある製品がその製品に要求される特性に反してないかを比較する一連の活動である。その製品には，全てではないが，定義された要求事項・設計記述・システムそのもの，が含まれる。システムが正しく構築されたかを確認することである。 		verification

← 一覧に戻る ↑ このページのトップに戻る