→ /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 では、「要求事項」 という言葉も使用している
en : system
JIS X 0160:2021 での定義 : 一つ以上の明記された目的を達成するために組織された相互に作用する要素の組合せ
一般システム理論におけるシステム
内部の要素が相互に関連する、1 つのまとまりのこと
複数の要素が情報やモノ、エネルギーなどの流れでつながり、相互に作用しあい、全体として目的や機能を有する集合体
SyRS (システム要件仕様) に関する文書
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
en : operational concept
略 : OpsCon
JIS X 0166:2021 の定義 : 一つの特定のシステムの、又は特定の新規、既存若しくは修正された関連する一組のシステムの、運用又は一連の運用に関して、組織の前提条件又は意図を言葉及び図で記述するもの
en : stakeholder requirements specification
略 : StRS
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 : 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』 より
システム、ソフトウェア製品、又はサービスの開発を目的とする
要件を、顧客のニーズにあったシステムへと変換する
システムの新規開発や保守に伴う開発、旧システムからの移行に伴う開発で用いられる
以下のプロセスがある
ホケットによるもの
今井・秋田版
言語の本質的特徴
1. 意味を伝える
2. 変化する
複数のコンポーネントやサブシステムからなるプロダクトの要求を表す (ISO/IEC/IEEE 29148:2011 (E))
システムというのはソフトウェア以外のハードウェアなども含んでおり、人やプロセスもシステムの一部
ユーザーインターフェイスの分析と設計の中の作業のひとつ
システムのエンドユーザーのプロファイルに焦点を当てる
スキルレベルや業務の理解、新しいシステムに対する受容力などを記録
ユーザーのカテゴリごとに要求が導かれる
本質的には、ユーザーの種類ごとのシステム知覚を理解する取り組み
識別された利害関係者のニーズ、欲求、要望、期待及び識別された制約条件を記述するもの
文章又は形式的表現によるモデルを使用して表現する
システムの目的及び振る舞いに焦点を当てる
関連
利害関係者ニーズ及び利害関係者要件定義プロセス
en : software system
JIS X 0160:2021 の定義 : 利害関係者にとって、ソフトウェアが最も重要であるシステム
一般的に、ソフトウェアシステムは、ハードウェア、ソフトウェア、人員及び手作業で構成される
ソフトウェア開発の成果物
3 つの重要な特性 (1)
組織が学習できない 7 つの要因
1. 私の仕事は○○だから : 事業全体のことを考えられない
2. 悪いのはあちら : 他責にする
3. 先制攻撃の幻想 : 難しい問題に直面したときに積極的に敵に攻撃する (が、実際には敵はおらず、問題を引き起こしているのは自分自身を含めたシステム)
4. 出来事への執着 : 売上や予算削減、競合他社の新製品などの短期的な出来事を重視し、その背後の長期的なパターンを無視する
en : Theory of Constraints / 略 : ToC / 同義 : 制約条件の理論
TOC (Theory Of Constraints : 「制約理論」 または 「制約条件の理論」) は、「どんなシステムであれ、常に、ごく少数 (たぶん唯一) の要素または因子によって、そのパフォーマンスが制限されている」 という仮定から出発した包括的な経営改善の哲学であり手法です。
相手への気づかいに基づく感情の状態だと考えられやすい
思いやりは、行動に作用するシステムに対する気づきの度合いに基づくものでもある
参考文献
学習する組織 ―― システム思考で未来を創造する
en : General systems theory
1940 年代の後半に作られた
第 1 期のシステム理論とされる
世界のほとんどの現象は、要素間の関係性の網としてみなせる、という考えに基づく
複数の学問分野を一つの共通言語で形式化することを最終ゴールとしているっぽい
en : System Thinking / Systems thinking
複雑なシステムの根底にある構造を見抜き、問題解決を単純化するという考え方
多様な分野にまたがる一連の一般原則
以下に端を発する独自のツールと手法でもある
サイバネティクスのフィードバック
社会をシステムの観点から読み解こうとする理論
制御の学をルーツに、20 世紀半ばから発展
統計熱力学を下敷きにしている
コミュニケーション一元論を用いて、コミュニケーション以外のものを要素としないシステムのダイナミズムを記述する
従来の上部構造と下部構造の二元論とは区別される
モダンからポストモダンへの変化
生活世界がシステムに置き換わるプロセスの当初は、システムを使うのは生活世界を生きる我々がより便利で豊かになるため、と自己理解できる
システムが一定程度広がり、生活世界が空洞化 → もはや我々がシステムを使っていると言えない
我々や生活世界というイメージも、システムの構築物だと理解するしかない
変化のまとめ
生活世界でまかなわれていた便益をシステムに置き換える合理化過程
途上が近代過渡期 (モダン)
完遂した段階が近代成熟期 (ポストモダン)
あえて生活世界を保全しているといえるようになるのが再帰的近代
選択対象としての生活世界なので、厳密にはシステムの中に含まれる
アメリカの国内外で疑惑と論争の種を撒き散らし続ける
それでもフィールグッド・ステイトを目指す以外に選択肢はない
民主制の危機を招来する
プラットフォームの保全に関わる危機
1. 国民の便益増大が国家の権益拡大になる
システムの全域化による生活世界の空洞化
ウェーバーは、生活世界がシステムに置き換えられる動きを近代化や形式合理化と呼ぶ
モダンからポストモダンへの変化という逆説
生活世界の空洞化が起こった経緯
生活世界の空洞化 = システムの全域化は、郊外化の動きと並行
ローマ帝国が 2000 年も続いた理由
優れたシステム
徹底した合理主義
多様性 (ダイバーシティ)
キリスト教が国教になるまで、異なる宗教や文化に寛容だった
生活世界を生きる我々が便宜のためにシステムを利用する、という自己理解が、汎システム化でできなくなる社会
生活世界も、そこで生きる我々もシステムの生成物に過ぎないものとして意識される
関連
ポストモダン
モダンからポストモダンへの変化
システムに対して、残余の領域
ここで言うシステムは、マックス・ウェーバーの言葉でいうと 「物事を計算可能にする手続きが一般化した領域」
例えば、役割とマニュアルが優位なコミュニケーション
役割をマニュアル通りに演じられれば誰でもいい
善意と内発性が優位なコミュニケーション領域
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 の移行プロセスの成果を引き出す一助になる
ソフトウェア実装プロセスの一部??
製品が要件を満たしているという確信を、取得者が持つことを助ける
開発者は、次のことを行う
en : Implementation process
共通フレーム 2013 のソフトウェア構築プロセスは、このプロセスを特化したものっぽい
JIS X 0160:2021 より
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
指定されたシステム要素を実現することを目的とする
共通フレーム 2013 におけるソフトウェア実装プロセスの一部
要件を実装し、それに対して検証できるソフトウェアの設計を提供する
JIS X 0160:2021 のアーキテクチャ定義プロセスを特化させたものかな?
ストーリーの活用を妨害するアンチパターン
会話をする人の一人がクライアントの役割を果たし、もう一人がベンダーの役割、という形
何が欲しいかを知っており、詳細を説明するのはクライアントの仕事
いわゆる要件を説明する
それを聞いて理解し、その要件を満たす物を作る技術的なアプローチを考えるのがベンダーの仕事