→ /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 : software requirements specification
略 : SRS
プロダクト要求を入れる
ソフトウェアシステムが提供しなければならない機能と能力、その特性、および尊重しなければならない制約条件
様々な条件下におけるシステムの振る舞いを必要十分に表現
ソフトウェア要件仕様のこと
ほぼ同義 : ソフトウェア要求仕様書
en : requirement
JIS X 0166 の定義 : ニーズ並びにそれに付随する制約及び条件を変換した又は表現する文
requirement は、通常 「要求」 または 「要件」 と訳される
JIS X 0166 では、「要求事項」 という言葉も使用している
from ソフトウェア要求 第 3 版
ステークホルダーが合意した要求セット
特定の予定リリースまたは開発イテレーションの内容として定義されることも多い
特定の SRS の一部や全部から構成されることもあれば、要求管理ツールの特定の要求セットの場合もあれば、アジャイル型プロジェクトのひとつのイテレーションの合意済みのユーザーストーリーの場合もある
要求開発の成果物であるビジネス要求、ユーザー要求、機能要求、非機能要求、データディクショナリ、各種分析モデルなどが、レビューされ、承認されたあとで、定義されたサブセットが要求ベースラインとなる
JIS X 25030:2021 より
JIS X 0170:2020に定義されている要求事項関連プロセス (利害関係者ニーズ及び利害関係者要件定義プロセスやシステム要件定義プロセス) を用いて、品質要件を引き出し、定義し、分析し、維持する
ソフトウェアシステムだとシステム/ソフトウェア要件定義プロセスだな
利害関係者ニーズ及び利害関係者要件定義プロセス (要件定義プロセス) によって利害関係者要件を定義する際に、その中で利用時品質要件も定義
スコープ表現技法の一種
『ソフトウェア要求 第 3 版』 より
システムの振る舞いのトリガーとなる外部イベントを特定する
ビジネスイベント : ユーザーがトリガー
時間イベント : 時間がトリガー
テストについて
ソフトウェアテストは、開発と保守を通して、様々なレベル (テストレベル) で実行される
テストレベルは、テストの目標物 (テスト対象) とテストレベルの目的または目標によって識別される
テスト対象による分類 (『SWEBOK V4 Beta』 参照)
単体テスト (unit testing)
en : Use Case
1987 年に Ivar Jacobson が提唱して依頼、広く使われてきた要求分析技法
UML では、ユーザー (アクター) とユースケースの関係がユースケースモデルとして表される
ユースケースの分割 : ユースケーススライス
『ソフトウェア要求 第 3 版』 より
『ソフトウェア要求 第 3 版』 において、要求エンジニアリングの分野を 2 つに分けたうちのひとつ
もう一方は要求管理
要求開発は、以下の分野に分けられる
要求引き出し
要求分析
要求仕様作成で最も重要なことは、種々の要求を、以下を満たすように文書化すること
整合性がある
アクセス可能
レビュー可能な方法
対象とする読者が容易に理解できる
『ソフトウェア要求 第 3 版』 より
構築対象のソフトウェアシステムの特性を記述する要求のこと
ソフトウェア要求仕様書に入るものがプロダクト要求ってことかな? 正確な定義がわからん
#ソフトウェア要求
特定の条件下でシステムが示す振る舞いの記述
ビジネスアナリストが必要十分な程度に記述して、ソフトウェア要求仕様書に入れる
伝統的に 「しなければならない (shall)」 で記述する
例 : 「乗客は、チェックインしたフライト区間すべての搭乗券を印刷できなければならない」
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
en : system requirements specification
略 : SyRS
JIS X 0166:2021 の定義 : システム及びその運用環境並びに外部インターフェイスに対する要件を構造化した集合
en : stakeholder requirements specification
略 : StRS
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 の定義 : ビジネス又はミッション、及びその外部環境との関係についての要件を構造化した集合
すなわち、ビジネス要件 (= ビジネス要求) に関する仕様
ドメインの機能には直接関連しないがソフトウェアが満たさなければならない全てのこと
問題領域とは独立した、システムの重要な側面
非機能要件や品質特性と同義らしい
アーキテクチャ特性の定義は、設計やコーディングとアーキテクティングの違いのひとつ
次の 3 つを満たす
デリバリーパフォーマンスと同義っぽい。
安定性とスループットという 2 つの属性でソフトウェア開発のパフォーマンスを評価。
スループットはチームの学びの機会がどれだけあるかを示す
安定性は、行われた作業の品質の指標になる
スループットの指標
https://dora.dev/
ソフトウェアのデプロイと運用パフォーマンスを促進する機能を理解することを目的としたプログラム
DORA は、チームがこれらの機能を適用できるように支援し、組織のパフォーマンスの向上につなげる
en : Evolutionary Architecture
複数の次元にわたる漸進的で誘導的な変更を支援するもの
進化的設計の延長にあると考えられる
『進化的アーキテクチャ ―― 絶え間ない変化を支える』 にて説明される
下記の 2 つの間の釣り合いをとる
ソフトウェアに関するアーキテクト
アーキテクトへの期待
アーキテクチャ決定を下す
アーキテクチャを継続的に分析する
継続的に最新のトレンドを把握
ソフトウェアのモジュールとしてはサブルーチン (プロシージャとも、サブプログラムとも、関数とも呼ばれる)
サブルーチンを使う動機は、最初はメモリサイズの制限によるもの
ソフトウェアが複雑になるにつれて、サブプログラムは複雑さに対処する重要なツールになった
サブプログラムによって抽象化のレベルを上げて、詳細を隠す
プログラマは、より高いレベルで仕事をすることが可能に
アプリケーションプログラムと外部のハードウェア機器との間にインターフェイスを提供するソフトウェア
デバイスドライバの機能は、次のコードの共同作業で実装される
バスを介して通信を行うコード
デバイスの詳細を扱うコード、
アプリケーションとのやりとりを行うコード
en : software engineering
同義 : ソフトウェア工学
JIS X 0160:2021 の定義 : ソフトウェアへの工学の応用であって、ソフトウェアの開発、運用及び保守に対する、体系的で統制がとれ定量化できる取組方法の適用
1968 年に開催された NATO の会議で初めて使用された言葉
ISO/IEC/IEEE 「システムおよびソフトウェアエンジニアリング用語 (System and Software Engineering Vocabulary: SEVOCAB)」 では、ソフトウェアエンジニアリング (software engineering) を、「ソフトウェアの開発、運用、および保守に関する、体系化され、実践規律化され、かつ定量可能化された手法である。
ソフトウェアエンジニアリングにおける持続可能性
ソフトウェアの想定稼働期間中に、どのような有用な変更要求に対しても反応できること
『Google のソフトウェアエンジニアリング ― 持続可能なプログラミングを支える技術、文化、プロセス』 より
土台となっている技術や製品の方向性の変化に反応する能力を欠いている場合、そのような変化が決定的に重要になることは絶対にないという期待へのハイリスクな賭けをしていることになる
en : software configuration item
略 : SCI
ソフトウェアに関する構成品目 (configuration item)
以下のようなものが SCI となる
計画
複数のコンポーネントやサブシステムからなるプロダクトの要求を表す (ISO/IEC/IEEE 29148:2011 (E))
システムというのはソフトウェア以外のハードウェアなども含んでおり、人やプロセスもシステムの一部
en : instruction set architecture
略 : ISA
表記ゆれ : 命令セット・アーキテクチャ
命令セットと、それに対応する命令表現を定義するもの
ハードウェアと最低水準のソフトウェアの間のインターフェイス
ハードウェアで命令に使われるバイナリ表現のこと
ハードウェアとソフトウェアのインターフェイス
参考文献
コンピュータアーキテクチャのエッセンス [第 2 版]
en : on-premises
IT システムを構成するハードウェアやソフトウェアを自社施設やデータセンターに導入し、インフラ資源を主体的に管理する運用形態
en : software system
JIS X 0160:2021 の定義 : 利害関係者にとって、ソフトウェアが最も重要であるシステム
一般的に、ソフトウェアシステムは、ハードウェア、ソフトウェア、人員及び手作業で構成される
ソフトウェア開発の成果物
3 つの重要な特性 (1)
ソフトウェアとソフトウェアエンジニアリングの歴史
コンピューティングの先駆者
19 世紀のチャールズ・バベッジとエイダ・ラブレスや、ホレリスのパンチカードの開発など
現代のコンピューティングは、1940 年代から発展を開始
初期のコンピューター (一部は電気機械式) のプログラミングの方法 : スイッチ、パンチカードの紙テープ、命令を与えるプラグボードなど
IT (とそれを構成するソフトウェア) 活用を核として事業やプロダクト開発を進めていく考え方
及川卓也氏により、『ソフトウェア・ファースト ― あらゆるビジネスを一変させる最強戦略』 で提唱された
ソフトウェアがすべてということではなく、ソフトウェアは一つの手段
サービス化する社会に合わせたプロダクト開発手法の変化に記載されているようなプロダクト開発の手法は、ソフトウェアの価値を理解した上でプロダクト / 事業開発を前に進めていくための一部にしか過ぎない
技術による事業創出のためのプロダクト企画のやり方
バイモーダル IT におけるモード 1 の IT システムは既存事業の効率化がメインだが、モード 2 では事業創出が必要 → プロダクト企画のやり方を変える必要
市場やユーザーを調査して事業計画を立てること自体は悪ではないが、イノベーションのためにはすでに顕在化しているニーズを調べ上げるだけではダメ
考えること、考え抜くことが必要 (ソフトウェア・ファーストで最も大事)
en : Stakeholder Needs and Requirements Definition process
JIS X 0160 での訳 : 利害関係者ニーズ及び利害関係者要件 (要求事項) 定義プロセス
JIS X 0160 で定義されているソフトウェアライフサイクルプロセスのひとつ
取得者の業務要件と、取得者がシステムに求める要件 (機能要件、非機能要件) を明確にすることを求めている
アーキテクチャを設計したり、開発プロジェクトの技術的なリスクをプロトタイプ開発で検証したりする
他のプログラマへの技術的な指導をすることも
『進化的アーキテクチャ ―― 絶え間ない変化を支える』 より
アーキテクトの仕事とは、(それが何であれ) 重要なものを全て理解し、釣り合いを取ること
アーキテクトが最初にやるべき仕事は、解決案のためにビジネスやドメインの要件を理解すること
共通フレーム 2013 においては、JIS X 0160:2021 の利害関係者ニーズ及び利害関係者要件定義プロセスを単に要件定義プロセスとしている
いわゆる業務要件定義を行うプロセス
関連
利害関係者要件
『SEC BOOKS 共通フレーム 2013』 より
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』 より
システム、ソフトウェア製品、又はサービスの開発を目的とする
要件を、顧客のニーズにあったシステムへと変換する
システムの新規開発や保守に伴う開発、旧システムからの移行に伴う開発で用いられる
以下のプロセスがある
ストーリーの活用を妨害するアンチパターン
会話をする人の一人がクライアントの役割を果たし、もう一人がベンダーの役割、という形
何が欲しいかを知っており、詳細を説明するのはクライアントの仕事
いわゆる要件を説明する
それを聞いて理解し、その要件を満たす物を作る技術的なアプローチを考えるのがベンダーの仕事