要求、要求事項、要件などと訳される
関連
「要求」 と 「要件」 はいずれも requirement の訳
システム化に対するニーズと要求/要件の使い分け
要求、要求事項、要件などと訳される
関連
「要求」 と 「要件」 はいずれも requirement の訳
システム化に対するニーズと要求/要件の使い分け
en : requirement
ステークホルダーの観点で、ソフトウェアシステムに何を期待するかを示したもの
関連
あらゆるソフトウェア開発に含まれる要素
要件
en : requirement
JIS Q 9000 より
明示されているか、通常暗黙のうちに了解されている、または義務として要求されているニーズまたは期待
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
要求エンジニアリングについての日本産業規格
内容は https://www.jisc.go.jp/app/jis/general/GnrJISSearch.html にて 「X0166」 で検索して閲覧できる
版
JIS X 0166:2021
原著 : Software Engineering: A Practitioner's Approach (9th edition)
著 : Roger S. Pressman、Bruce R. Maxim
訳 : SEPA 翻訳プロジェクト
関連ページ : https://github.com/ohmsha/sepa9th_book
感想
システム開発における要求と要件の違いについて、標準的な定義は無い模様
英語の requirement の訳として、要求も要件も使われるっぽい
『ユーザのための要件定義ガイド 第 2 版』 では、「要求を文書化、仕様化し、ステークホルダーと合意したもの」 を要件としている
『経営者が参画する要求品質の確保 ~超上流から攻める IT 化の勘どころ~ 第 2 版』 における使い分け
以下のような使い分けを考えている様子
『SEC BOOKS 共通フレーム 2013』 より
要求と要件は、いずれも requirement の訳語
国際規格での定義の例 : 製品またはプロセスの運用/機能/設計上の特性を識別する文で、曖昧性がなく、テスト可能で、測定可能で、(顧客または内部の品質保証ガイドラインに) 受け入れられるために必要であるもの
事業目的や業務目的に照らして 「本当に必要か」 が十分検討され、要求が満たされたことの基準や手段がはっきりしており、明文化されているもの
→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
from 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
要求と要件と仕様の違い
要求は、希望のこと
例 : インターネット上で取引できるようにしたい
要件は、要求を実現するための条件
en : Stakeholder Needs and Requirements Definition process
JIS X 0160 での訳 : 利害関係者ニーズ及び利害関係者要件 (要求事項) 定義プロセス
JIS X 0160 で定義されているソフトウェアライフサイクルプロセスのひとつ
取得者の業務要件と、取得者がシステムに求める要件 (機能要件、非機能要件) を明確にすることを求めている
ドメインの機能には直接関連しないがソフトウェアが満たさなければならない全てのこと
問題領域とは独立した、システムの重要な側面
非機能要件や品質特性と同義らしい
アーキテクチャ特性の定義は、設計やコーディングとアーキテクティングの違いのひとつ
次の 3 つを満たす
アーキテクチャを設計したり、開発プロジェクトの技術的なリスクをプロトタイプ開発で検証したりする
他のプログラマへの技術的な指導をすることも
『進化的アーキテクチャ ―― 絶え間ない変化を支える』 より
アーキテクトの仕事とは、(それが何であれ) 重要なものを全て理解し、釣り合いを取ること
アーキテクトが最初にやるべき仕事は、解決案のためにビジネスやドメインの要件を理解すること
共通フレーム 2013 においては、JIS X 0160:2021 の利害関係者ニーズ及び利害関係者要件定義プロセスを単に要件定義プロセスとしている
いわゆる業務要件定義を行うプロセス
関連
利害関係者要件
『SEC BOOKS 共通フレーム 2013』 より
製品やサービスが合意済みの要件を満たすことに対する確約
「サービスがどのように提供されるか」 であるといえる
「サービスが使用に適しているか」 の判断に使える
一般的に、サービスの可用性やキャパシティ、セキュリティ、継続性を確約する
参考文献
en : Design Definition process
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
JIS X 0160:2021 より
ソフトウェアシステムに対しては、通常、設計アクティビティを、システム/ソフトウェア要件定義プロセスとアーキテクチャ定義プロセスの中のアクティビティとともに反復する
ソフトウェア設計は、通常、実装プロセス、インテグレーションプロセス、検証プロセス、妥当性確認プロセスと同時並行になる
『アジャイルイントロダクション : Agile 開発の光と影』 で説明される、アジャイルの原則
from アジャイルイントロダクション : Agile 開発の光と影
アジャイルの信条の価値基準に従うもの
「アジャイル宣言の背後にある原則」 は原則とは言えない
組織 (プロジェクトマネジメント、スケジューリング、チーム構成に影響)
共通フレーム 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』 より
システム、ソフトウェア製品、又はサービスの開発を目的とする
要件を、顧客のニーズにあったシステムへと変換する
システムの新規開発や保守に伴う開発、旧システムからの移行に伴う開発で用いられる
以下のプロセスがある
en : system requirements specification
略 : SyRS
JIS X 0166:2021 の定義 : システム及びその運用環境並びに外部インターフェイスに対する要件を構造化した集合
en : stakeholder requirements specification
略 : StRS
JIS X 0166:2021 の定義 : 利害関係者、及び利害関係者と外部環境との関係についての要件を構造化した集合
en : software requirements specification
略 : SRS
同義 : ソフトウェア要求仕様書
JIS X 0166:2021 の定義 : ソフトウェア及びその外部インターフェイスへの必要不可欠な要件を構造化した集合
機能、性能、設計の制約、及び属性
ストーリーの活用を妨害するアンチパターン
会話をする人の一人がクライアントの役割を果たし、もう一人がベンダーの役割、という形
何が欲しいかを知っており、詳細を説明するのはクライアントの仕事
いわゆる要件を説明する
それを聞いて理解し、その要件を満たす物を作る技術的なアプローチを考えるのがベンダーの仕事
要件定義に関する標準
国際標準 : ISO/IEC/IEEE 29148 に要件定義にも含めた上流工程の用語や概念などが整理されている
これを基にした日本産業規格 : JIS X 0166
参考文献
ユーザのための要件定義ガイド 第 2 版
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
経営上のニーズの実現や課題解決のために、経営環境を踏まえて、新たな業務の全体像とそれぞ実現するためのシステム化構想及び推進体制を立案する
アクティビティとしては、準備、立案、承認、がある
ISO/IEC 29148 の A.2.5 「Concepts for the proposed system」 を参考にすると良い
en : System/Software Requirements Definition process
同義 : システム及び/又はソフトウェア要件 (要求事項) 定義プロセス (JIS X 0160 での訳)
共通フレーム 2013 においては、システム要件定義プロセスやソフトウェア要件定義プロセスがこのプロセスに該当するぽい
JIS X 0160:2021 より
JIS X 25030:2021 より
JIS X 0170:2020に定義されている要求事項関連プロセス (利害関係者ニーズ及び利害関係者要件定義プロセスやシステム要件定義プロセス) を用いて、品質要件を引き出し、定義し、分析し、維持する
ソフトウェアシステムだとシステム/ソフトウェア要件定義プロセスだな
利害関係者ニーズ及び利害関係者要件定義プロセス (要件定義プロセス) によって利害関係者要件を定義する際に、その中で利用時品質要件も定義
要求工学の国際規格
対応する日本産業規格は JIS X 0166
版
ISO/IEC/IEEE 29148:2011
ISO/IEC/IEEE 29148:2011 (E) ← これは違うかも
『ソフトウェア見積り 人月の暗黙知を解き明かす』 において、規模の見積りは、所定の機能の技術的なスコープを見積もることを指す
コード行数 (LOC) やファンクションポイント、ストーリーなどが単位となる
規模の見積りは、シーケンシャルプロジェクトの初期と中期によく使用される
反復型プロジェクトでは、多くの場合は機能を直接見積もる (機能の見積り)
シーケンシャルプロジェクトの後期には、ボトムアップでの工数見積りが中心になりやすい
テストについて
ソフトウェアテストは、開発と保守を通して、様々なレベル (テストレベル) で実行される
テストレベルは、テストの目標物 (テスト対象) とテストレベルの目的または目標によって識別される
テスト対象による分類 (『SWEBOK V4 Beta』 参照)
単体テスト (unit testing)
複数のコンポーネントやサブシステムからなるプロダクトの要求を表す (ISO/IEC/IEEE 29148:2011 (E))
システムというのはソフトウェア以外のハードウェアなども含んでおり、人やプロセスもシステムの一部
IT システムを作らせる側が、システムに求めること (= 要求) を明確にする作業
ケンブリッジ・テクノロジー・パートナーズの定義としては、「利害関係者の意見をまとめ、実現することとしないことを揺るぎなく定めること」 としている
「要求定義」 と 「要件定義」 を同じものとする派閥もあれば、異なるものとする派閥もある
主要な成果物
ファンクショナリティ・マトリクス (FM)
同義 : 分析モデル
情報、機能、振る舞いの 3 つの側面でソフトウェアを記述し、顧客の要求を表現
要求モデルが達成すべき主要な 3 つの目的
1. 顧客が求めているものを説明する
2. ソフトウェア設計の土台を確立する
要求を詳細化して、すべてのステークホルダーが要求を理解していることを確認し、精査することで誤りや漏れやその他欠陥を見つけること
目標 : 十分な品質と精密さを備えた要求を作成すること
マネジャーが現実的なプロジェクト見積もりができ、技術スタッフが設計、構築、テストの作業に進むために十分なレベルの精密さ
要求分析には以下のようなものが含まれる
概要レベルの要求を分解して適切なレベルまで詳細化する
『ソフトウェア・テストの技法 第 2 版』 に出てくる言葉
あまり他の文献ではこの言葉を見かけないので、一般的ではないかも
一般的には要求仕様書に目的仕様書の内容も含まれそう
要求仕様を基に作成され、外部仕様のインプットとなる
目的仕様書が述べていることは、プログラムが何をどのようになすべきかであって、プログラムの機能を表現しているのではない
性能と拡張性をまとめた非機能要求のカテゴリ
処理時間や同時接続数などのの性能についての (将来も含めた) 要求
ここでいう拡張性とは、将来的に性能をどれぐらい上げられるか、的な感じっぽい?
スケーラビリティも含んでるのかな
拡張性を進化可能性のように捉える向きもあるので、言葉づかいが難しい
Essence の言語におけるワークプロダクト
ドキュメントやレポートなどの目に見えるもの
アルファの状態が達成できたことを検証するための証拠になる
例えば、要求アルファのワークプロダクトとして要求仕様書がありえる
複数の詳細レベルを持つことができる
見積り誤差を引き起こす原因 : 一般的に 4 つ
不確実性のコーン (適正に運営されているプロジェクトでも不確実性がある)
プロジェクトの見積りはプロセスの各段階における予測可能な量の不確実性に支配される
不確実性のコーンが表すのは最良の状況であり、見積り者の熟練度やその他の要因によりもっと悪くなる可能性
不確実性を反映させる (範囲で見積もる) ための 2 つの方法
関連 : 要求管理に関する良いプラクティス
同義 : 要求マネジメント
『ソフトウェア要求 第 3 版』 において、要求エンジニアリングの分野を 2 つに分けたうちのひとつ
もう一方は要求開発
目的は、常に発生する変更を予期して、プロジェクトに壊滅的な影響を及ぼさないように組み込んでいくこと
要求の属性
from ソフトウェア要求 第 3 版
要求には文書による説明以外に、補助情報が必要
次のようなものを検討すると良い
要求の作成日
要求のバージョン管理
from ソフトウェア要求 第 3 版
最も賢いバージョン管理の方法は、要求を要求管理ツールに保管すること
要求を文書で保存している場合は、ワードプロセッサの変更履歴機能で追跡記録できる
最も簡単なのは、標準の規約をつくり、手作業でラベルをつけること
from ソフトウェア要求 第 3 版
ステークホルダーが合意した要求セット
特定の予定リリースまたは開発イテレーションの内容として定義されることも多い
特定の SRS の一部や全部から構成されることもあれば、要求管理ツールの特定の要求セットの場合もあれば、アジャイル型プロジェクトのひとつのイテレーションの合意済みのユーザーストーリーの場合もある
要求開発の成果物であるビジネス要求、ユーザー要求、機能要求、非機能要求、データディクショナリ、各種分析モデルなどが、レビューされ、承認されたあとで、定義されたサブセットが要求ベースラインとなる
プロダクトオーナーの職務
from 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
方向性の番人 (なぜこのプロダクトを作るのか)
ビジョンとミッション
プロジェクトはミッション達成のためのタイムボックスであり手段
from 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
人の期待をマネージしながら不確実性に適応する術
3 つの術
余白の戦略
スプリント強度を高める戦術 (やり抜く力)
アジャイルに対する概評
from アジャイルイントロダクション : Agile 開発の光と影
新しくも良くもない
要求をユーザーストーリーやユースケースとして扱うこと
良い要求は、より抽象的な仕様を目指し、多くの異なるシナリオを内包して、柔軟で拡張可能なアプリケーションの開発を支援するもの
en : invention design
ソフトウェア要求プロセスの中で、発見されたニーズと要求を満たすために、システムの概念化および仕様化を目的に行う
from PMBOK はじめの一歩 ― スッキリわかるプロジェクトマネジメントの基本
プロジェクトを実行、監視・制御、および終結する方法を記述した文書
計画書の要素
プロジェクトの目的、目標
スコープ
en : validation
関連 : 検証と妥当性確認
JIS Q 9000 より
客観的証拠の提示により、特定の意図された用途または適用に関する要求事項が満たされていることを確認すること
妥当性確認のための客観的証拠は、試験の結果や別法による計算の実施、文書のレビューのような他の形の確定 (determination) の結果
en : quality requirement
同義 : 品質要求事項
JIS Q 9000 より
品質に関する要求事項
JIS X 25030:2021 より
i コンピテンシ ディクショナリのタスクより
以下のようなことを行う
システム化の対象と目的の決定
要求事項の調査と分析
機能要件の定義
en : inspection
JIS Q 9000 より
規定の要求事項への適合を確定 (determination) すること
検査の結果が適合を示す場合、その結果を検証のために使用できる
検査の結果は、適合または不適合、あるいは適合の程度を示すことがある
en : test
JIS Q 9000 より
特定の意図した用途や適用に関する要求事項に従って、確定 (determination) すること
試験の結果が適合を示す場合、その結果を妥当性確認のために使用できる
en : verification
関連 : 検証と妥当性確認
JIS Q 9000 より
客観的証拠の提示により、規定の要求事項が満たされていることを確認する
検証のための客観的証拠は、検査の結果や別法による計算の実施、文書のレビューなどの他の形の確定の結果であることがある