→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
en : requirement
JIS X 0166 の定義 : ニーズ並びにそれに付随する制約及び条件を変換した又は表現する文
requirement は、通常 「要求」 または 「要件」 と訳される
JIS X 0166 では、「要求事項」 という言葉も使用している
ITIL 4 では、サービスの利害関係者の代表例として以下を挙げている
サービス消費者 (ユーザー、顧客、スポンサー)
サービス・プロバイダ
パートナー、サプライヤ
株主、従業員、コミュニティ等
利害関係者要件仕様とほぼ同義だと思われる
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
en : system requirements specification
略 : SyRS
JIS X 0166:2021 の定義 : システム及びその運用環境並びに外部インターフェイスに対する要件を構造化した集合
en : software requirements specification
略 : SRS
同義 : ソフトウェア要求仕様書
JIS X 0166:2021 の定義 : ソフトウェア及びその外部インターフェイスへの必要不可欠な要件を構造化した集合
機能、性能、設計の制約、及び属性
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
経営上のニーズの実現や課題解決のために、経営環境を踏まえて、新たな業務の全体像とそれぞ実現するためのシステム化構想及び推進体制を立案する
アクティビティとしては、準備、立案、承認、がある
ISO/IEC 29148 の A.2.5 「Concepts for the proposed system」 を参考にすると良い
規格名称 : Systems and software engineering — Life cycle processes — Requirements engineering
https://www.iso.org/standard/72089.html
ISO/IEC/IEEE 29148 の 2018 年の版
対応する JIS は JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
要求エンジニアリングについての日本産業規格
内容は https://www.jisc.go.jp/app/jis/general/GnrJISSearch.html にて 「X0166」 で検索して閲覧できる
版
JIS X 0166:2021
en : operational concept
略 : OpsCon
JIS X 0166:2021 の定義 : 一つの特定のシステムの、又は特定の新規、既存若しくは修正された関連する一組のシステムの、運用又は一連の運用に関して、組織の前提条件又は意図を言葉及び図で記述するもの
en : concept of operations
略 : ConOps
JIS X 0166:2021 の定義 : 運用又は一連の運用に関する組織の前提条件又は意図を、言葉及び図で、全体像として記述するもの
en : business requirements specification
略 : BRS
同義 : ビジネス要求仕様、ビジネス要求事項仕様、ビジネス要求記述書
JIS X 0166:2021 の定義 : ビジネス又はミッション、及びその外部環境との関係についての要件を構造化した集合
すなわち、ビジネス要件 (= ビジネス要求) に関する仕様
共通フレーム 2013 においては、JIS X 0160:2021 の利害関係者ニーズ及び利害関係者要件定義プロセスを単に要件定義プロセスとしている
いわゆる業務要件定義を行うプロセス
関連
利害関係者要件
『SEC BOOKS 共通フレーム 2013』 より
規格名称 : ソフトウェアライフサイクルプロセス
対応国際規格 : ISO/IEC/IEEE 12207:2017 (IDT)
JIS X 0160 の 2021 年に発行された版
内容メモ
ISO/IEC/IEEE 12207:2017 を基に、技術的内容および構成を変更することなく作成された日本産業規格
DSV は Drive Stakeholder Value のこと
サービスに関わる利害関係者の誰もが、サービスを通して価値を得られるように牽引すること
顧客だけではなく、サービス・プロバイダやサプライヤにとっても価値があるように
互いに win-win な関係 → 持続可能なサービス
カスタマージャーニー
ITIL の継続的改善のモデル。 ITIL SVS の構成要素のひとつになっている。
ビジョンを定義し、現状分析から改善を積み上げて推進力を維持しながらビジョンを達成するためのアプローチ
ビジョニングの分野から生まれた
ITIL 4 DPI に合致するモデル
次の 2 つが参考になる
ビジネスコンセプト : 構想立案時やシステム化企画時に検討され、要件定義開始時に提示されていることが多い
ビジネスコンセプト確認ドキュメント
ステークホルダー (利害関係者)
ステークホルダー関連図
ステークホルダー一覧
最初にやること
立ち上げ : 確認・準備
企画・構想を確認する
企画の目的の整理
ステークホルダー (利害関係者) の特定
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
システム化構想を実現するために、運用や効果等の実現性を考慮したシステム化計画とプロジェクト計画を具体化し、利害関係者の合意を得ることが目的
アクティビティとしては、準備、立案、承認、がある
ソフトウェアエンジニアが、適切な利害関係者に対してソフトウェアの側面を理解させたり、工業製品化したり、伝達する際に使える身近な手法
汎用原則
本質をモデル化せよ
大局観を提供せよ
効果的な伝達を図れ
IT システムを作らせる側が、システムに求めること (= 要求) を明確にする作業
ケンブリッジ・テクノロジー・パートナーズの定義としては、「利害関係者の意見をまとめ、実現することとしないことを揺るぎなく定めること」 としている
「要求定義」 と 「要件定義」 を同じものとする派閥もあれば、異なるものとする派閥もある
主要な成果物
ファンクショナリティ・マトリクス (FM)
識別された利害関係者のニーズ、欲求、要望、期待及び識別された制約条件を記述するもの
文章又は形式的表現によるモデルを使用して表現する
システムの目的及び振る舞いに焦点を当てる
関連
利害関係者ニーズ及び利害関係者要件定義プロセス
en : software system
JIS X 0160:2021 の定義 : 利害関係者にとって、ソフトウェアが最も重要であるシステム
一般的に、ソフトウェアシステムは、ハードウェア、ソフトウェア、人員及び手作業で構成される
ソフトウェア開発の成果物
3 つの重要な特性 (1)
en : Use Case
1987 年に Ivar Jacobson が提唱して依頼、広く使われてきた要求分析技法
UML では、ユーザー (アクター) とユースケースの関係がユースケースモデルとして表される
ユースケースの分割 : ユースケーススライス
『ソフトウェア要求 第 3 版』 より
一般的マネジメントプラクティス (ITIL 4) のひとつ
戦略および戦術レベルで、組織と利害関係者のつながりを確立し、深める
関係の識別、分析、モニタリング、継続的改善等
参考文献
ITIL® ファンデーション ITIL 4 エディション
目的 : 組織で、変更が円滑かつ成功裏に実施されることと、変更における人に関わる側面を管理して、持続的なメリットの実現を確実にする
組織変更の管理のポイント
切迫感の創出 (危機意識を生み出す)
変革の 8 段階のプロセスの 1 番目のステップと同等
人は変化を嫌うものなので、今のままではいけない、という意識を持ってもらう
環境的、社会的、経済的発展に関連するリスクと機会に取り組むことで、社会やその他の利害関係者に長期的な価値を生み出すことに焦点をあてたビジネスアプローチ
参考文献
ITIL 4 の教本
アジャイル手法とソフトウェアライフサイクル
JIS X 0160:2021 より
アジャイルプロジェクトでは、概念の探索、開発、構築、テスト、移行、及び以前のソフトウェアの廃棄を連続的な反復で同時並行して行うことができる
こういったプロジェクトでは、これらの活動と同時並行して再計画を行う
この取組方法では、ライフサイクル段階の終了時点を管理チェックポイントとして、あるいは制御のために使用することは有用ではない
from PMBOK はじめの一歩 ― スッキリわかるプロジェクトマネジメントの基本
プロジェクトを実行、監視・制御、および終結する方法を記述した文書
計画書の要素
プロジェクトの目的、目標
スコープ
en : System/Software Requirements Definition process
同義 : システム及び/又はソフトウェア要件 (要求事項) 定義プロセス (JIS X 0160 での訳)
共通フレーム 2013 においては、システム要件定義プロセスやソフトウェア要件定義プロセスがこのプロセスに該当するぽい
JIS X 0160:2021 より
JIS X 25030:2021 で説明される、品質要件の一種
この JIS では 「利用時品質要求事項」 という言葉が使われているが、requirement の訳として 「要件」 を使うことが多いので、要件としている
利害関係者の視点から品質の要求レベルを明記したもの
様々な利害関係者のニーズから導出される
製品の妥当性確認のための対象として使用可能
en : systems engineering
JIS X 0160:2021 での定義 : 利害関係者のニーズ、期待及び制約の集合を、解決するソリューションへ変換するため、及びソリューションが用いられる全期間を通じて、それを支援するために要求される、技術上及び管理上の作業の全体を統括するような、複数の専門分野を横断した取組方法
en : Stakeholder Needs and Requirements Definition process
JIS X 0160 での訳 : 利害関係者ニーズ及び利害関係者要件 (要求事項) 定義プロセス
JIS X 0160 で定義されているソフトウェアライフサイクルプロセスのひとつ
取得者の業務要件と、取得者がシステムに求める要件 (機能要件、非機能要件) を明確にすることを求めている
ドメインの機能には直接関連しないがソフトウェアが満たさなければならない全てのこと
問題領域とは独立した、システムの重要な側面
非機能要件や品質特性と同義らしい
アーキテクチャ特性の定義は、設計やコーディングとアーキテクティングの違いのひとつ
次の 3 つを満たす
アーキテクチャを設計したり、開発プロジェクトの技術的なリスクをプロトタイプ開発で検証したりする
他のプログラマへの技術的な指導をすることも
『進化的アーキテクチャ ―― 絶え間ない変化を支える』 より
アーキテクトの仕事とは、(それが何であれ) 重要なものを全て理解し、釣り合いを取ること
アーキテクトが最初にやるべき仕事は、解決案のためにビジネスやドメインの要件を理解すること
en : requirement
ステークホルダーの観点で、ソフトウェアシステムに何を期待するかを示したもの
関連
あらゆるソフトウェア開発に含まれる要素
要件
原著 : Software Engineering: A Practitioner's Approach (9th edition)
著 : Roger S. Pressman、Bruce R. Maxim
訳 : SEPA 翻訳プロジェクト
関連ページ : https://github.com/ohmsha/sepa9th_book
感想
製品やサービスが合意済みの要件を満たすことに対する確約
「サービスがどのように提供されるか」 であるといえる
「サービスが使用に適しているか」 の判断に使える
一般的に、サービスの可用性やキャパシティ、セキュリティ、継続性を確約する
参考文献
from 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
要求と要件と仕様の違い
要求は、希望のこと
例 : インターネット上で取引できるようにしたい
要件は、要求を実現するための条件
en : Design Definition process
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
JIS X 0160:2021 より
ソフトウェアシステムに対しては、通常、設計アクティビティを、システム/ソフトウェア要件定義プロセスとアーキテクチャ定義プロセスの中のアクティビティとともに反復する
ソフトウェア設計は、通常、実装プロセス、インテグレーションプロセス、検証プロセス、妥当性確認プロセスと同時並行になる
『アジャイルイントロダクション : Agile 開発の光と影』 で説明される、アジャイルの原則
from アジャイルイントロダクション : Agile 開発の光と影
アジャイルの信条の価値基準に従うもの
「アジャイル宣言の背後にある原則」 は原則とは言えない
組織 (プロジェクトマネジメント、スケジューリング、チーム構成に影響)
システム開発における要求と要件の違いについて、標準的な定義は無い模様
英語の requirement の訳として、要求も要件も使われるっぽい
『ユーザのための要件定義ガイド 第 2 版』 では、「要求を文書化、仕様化し、ステークホルダーと合意したもの」 を要件としている
『経営者が参画する要求品質の確保 ~超上流から攻める IT 化の勘どころ~ 第 2 版』 における使い分け
以下のような使い分けを考えている様子
『SEC BOOKS 共通フレーム 2013』 より
要求と要件は、いずれも requirement の訳語
国際規格での定義の例 : 製品またはプロセスの運用/機能/設計上の特性を識別する文で、曖昧性がなく、テスト可能で、測定可能で、(顧客または内部の品質保証ガイドラインに) 受け入れられるために必要であるもの
事業目的や業務目的に照らして 「本当に必要か」 が十分検討され、要求が満たされたことの基準や手段がはっきりしており、明文化されているもの
要求、要求事項、要件などと訳される
関連
「要求」 と 「要件」 はいずれも requirement の訳
システム化に対するニーズと要求/要件の使い分け
共通フレーム 2013 のプロセスのひとつ
ISO/IEC 15288 の移行プロセスの成果を引き出す一助になる
ソフトウェア実装プロセスの一部??
製品が要件を満たしているという確信を、取得者が持つことを助ける
開発者は、次のことを行う
共通フレーム 2013 におけるソフトウェア実装プロセスの一部
システムのソフトウェア要素の要件を確立する
JIS X 0160:2021 におけるシステム/ソフトウェア要件定義プロセスを特化したものっぽい
en : Implementation process
共通フレーム 2013 のソフトウェア構築プロセスは、このプロセスを特化したものっぽい
JIS X 0160:2021 より
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
指定されたシステム要素を実現することを目的とする
共通フレーム 2013 におけるソフトウェア実装プロセスの一部
要件を実装し、それに対して検証できるソフトウェアの設計を提供する
JIS X 0160:2021 のアーキテクチャ定義プロセスを特化させたものかな?
『SEC BOOKS 共通フレーム 2013』 より
システム、ソフトウェア製品、又はサービスの開発を目的とする
要件を、顧客のニーズにあったシステムへと変換する
システムの新規開発や保守に伴う開発、旧システムからの移行に伴う開発で用いられる
以下のプロセスがある
ストーリーの活用を妨害するアンチパターン
会話をする人の一人がクライアントの役割を果たし、もう一人がベンダーの役割、という形
何が欲しいかを知っており、詳細を説明するのはクライアントの仕事
いわゆる要件を説明する
それを聞いて理解し、その要件を満たす物を作る技術的なアプローチを考えるのがベンダーの仕事