シリーズ記事の目次
システムアーキテクチャ設計の高度なスキル ・ソフトウェアアーキテクチャの概念、アーキテクチャスタイル、ABSD、アーキテクチャ再利用、DSSA (1) 【システムアーキテクト】 システムアーキテクチャ設計の高度なスキル ・システムの品質属性とアーキテクチャ評価 (2) 【
システムアーキテクト
】システムアーキテクチャ設計・ソフトウェア信頼性解析・設計(3) 【システムアーキテクチャ設計者】
システムアーキテクチャ設計専門スキル・ソフトウェアエンジニアリング要件エンジニアリング
1. 要求エンジニアリングの概要
ソフトウェア要件とは、機能、動作、パフォーマンス、設計制約などの観点からシステムに対するユーザーの期待を指します。
要件エンジニアリング (RE) とは、適切なツールと表記法を使用して、開発対象のシステム、その動作特性、および関連する制約を体系的に記述するために、実証済みの効果的な原理と方法を適用することを指します。
要求エンジニアリングは、図に示すように、要求の取得、要求の分析、要求仕様の作成 (または要求の文書化)、要求の確認と検証、および要求の管理の 5 つの段階で構成されます。
ソフトウェア要件仕様 (SRS)
SRS には、特に機能。制約には、設計制約とプロセス制約が含まれます。承認された SRS は、要件開発と要件管理の間の橋渡しとなります
要件管理
要件管理は、変更管理、バージョン管理、要件追跡、その他のアクティビティを含む、システム要件を変更、理解、制御するプロセスです。
2. 需要開拓（メインライン、ゴール）
2.1 要件の分類
- 要件の分類
(1)ビジネス ニーズ: ビジネス ニーズは、企業または顧客のシステムに対する高レベルの目標要件を反映しており、通常、プロジェクト投資家、製品を購入する顧客、顧客部門のマネージャー、マーケティング部門または製品企画部門などから発生します。ビジネス要件によって、プロジェクトのビューと範囲が決まります。
(2)ユーザー要件: ユーザー要件は、ユーザーの特定の目標、またはユーザーがシステムに完了させる必要があるタスクを記述します。つまり、ユーザー要件は、ユーザーがシステムで何ができるかを記述します。ユーザーの利用シーン（シナリオ）を整理し、ユーザーのニーズを確立するために、ユーザーインタビューやアンケートが一般的に行われます。
(3)システム要件: システム要件は、機能要件、非機能要件、設計上の制約を含む、システムの観点からソフトウェア要件を記述します。
- 品質機能の展開 QFD
ソフトウェアエンジニアリングプロセスにおいてユーザーの満足度を最大化することを目的として、ユーザー要件をソフトウェア要件に変換するテクノロジーです。この目標を達成するために、QFD はソフトウェア要件を通常の要件、予想される要件、予期しない要件の 3 つのカテゴリに分類します。
(1)基本ニーズ：通常のニーズとも呼ばれ、ユーザーがシステムが実現すべきと考える機能や性能であり、実装される機能や性能が多ければ多いほどユーザーの満足度が高くなります。
(2)期待される要件：利用者は、システムが持つべき機能や性能を当然のことと思っているが、自分が求める機能や性能の要件を正確に説明することができない。期待が満たされないと、ユーザーは不満を感じます。
(3)予期せぬ要件: 予期せぬ要件は、エキサイティングな要件とも呼ばれ、ユーザー要件の範囲外の機能や性能です (ただし、通常はソフトウェア開発者が喜んでシステムに提供する技術的特徴)。実現しても実現されず、購入決定にも影響しません。
2.2 要件の取得
| 方法 | 特徴 |
|---|---|
| 情報を集める | システム開発に役立つシステム関連の情報を収集します。 |
| 歴史的文書を読む | データベースの情報を収集するのに役立ちます。 |
| ユーザーインタビュー | 1 ～ 1-3、代表的なユーザー、主観的な考えを理解する、良好なインタラクション。コストは高く、ドメイン知識のサポートが必要です。 |
| アンケート | ユーザー数が多く、一度の面談は不可能で、コストも安い。 |
| 現場視察 | より複雑なプロセスと操作の場合。 |
| ビジネス実務に参加する | 問題の性質を効果的に発見し、その解決策を見つけます。 |
| 共同要件計画 (JRP) | すべての関係者が参加し、アイデアを理解し、相違点を排除し、良好な対話を行い、コストがかかる、高度に組織化されたグループ会議。 |
| ストーリーボード（プロトタイピング手法） | 物語が語られる一連の写真。 |
| サンプル調査・サンプリング | 数学的統計に基づいて、コストを削減し、迅速に取得します。 サンプルサイズ = a*(信頼性係数/許容誤差)2 注: a は通常 0.25 です。 |
-
ユーザー インタビュー
ユーザー インタビューは要件を取得するための最も基本的な手段であり、その形式には構造化されたものと非構造化されたものがあります。構造化とは、事前に一連の質問を準備し、的を絞った方法で質問を行うことを意味し、非構造化とは、大まかなアイデアのみを列挙し、面接の具体的な状況に応じて展開することを意味します。最も効果的な面接は、これら 2 つの方法を組み合わせて実施されますが、結局のところ、すべてを明確に計画することは不可能であり、適切な柔軟性を維持する必要があります。
ユーザーインタビューは柔軟性が高く、応用範囲も広いです。しかし、ユーザーが多忙で時間調整が難しい、インタビュー時の情報量が多く録音が難しい、コミュニケーションに多くのスキルが必要であり、システムアナリストにも十分な専門知識が必要であるなど、さらに、面接中に、会社の機密事項や機密性の高い話題に遭遇する場合もあります。したがって、この一見単純なテクノロジーには、システム アナリストの豊富な経験と強力なコミュニケーション スキルも必要です。 -
アンケート
調査ユーザーインタビューと比較して、短時間かつ低コストで大量の回答データを収集できる; アンケート調査は匿名で回答できるため、ほとんどのユーザーが生の情報を提供できる; アンケート調査は結果が得られやすい整理して数える。しかし、アンケート調査の最大の欠点は、柔軟性に欠けることであり、その他の欠点としては、
① 両者が会っていないこと、システムアナリストがユーザーの表情やその他の行動から暗黙的な情報を得ることができず、ユーザーにはその機会がないこと質問に対する自分の意見をすぐに明確にすること。曖昧な答えや不正確な答え。
② ユーザーは心理的に小さなフォームに注意を払わず、真剣に受け止めない可能性があり、その結果、フィードバック情報が不完全になる可能性があります。
③ アンケートでは質問に答えることができず、詳細が理解できない場合があります。
④ 回答者の数は予想よりも少ないことが多く、ユーザーが質問に答えたり、すべての質問に詳しく説明したりするという保証はありません。 -
サンプル調査/サンプリング サンプル調査/サンプリングとは、母集団から代表的なサンプル セットを
体系的に選択するプロセスを指します。選択されたサンプル セットを注意深く調査することで、母集団全体に関する有益な情報が明らかになります。情報システムの開発では、既存のシステムのドキュメント (ファイル) がサンプリング母集団となります。システムの要件分析を開始するときは、既存のシステムのドキュメントを確認することが、システムを予備的に理解するための最良の方法です。しかし、システム アナリストはどのような種類のドキュメントを参照する必要がありますか? ドキュメント内のデータが大きすぎて 1 つずつ調査できない場合は、サンプリング手法を使用して代表的なデータを選択する必要があります。サンプリング技術はデータ収集だけでなく、ユーザーへのインタビューやユーザーの収集・観察にも活用できます。人々をサンプリングする場合には、上で説明したのと同じサンプリング手法が適用されます。サンプリング技術により、母集団全体ではなく部分を選択することで、データ収集プロセスが高速化されるだけでなく、効率も向上し、それによって開発コストが削減されます。さらに、サンプリング技術は数学的統計の原理を使用して、データ収集の偏りを軽減します。ただし、サンプリング技術は統計原理に基づいているため、サンプルサイズの決定は、期待される信頼性と既存の事前知識に依存し、システムアナリストの主観的な要素、個人的な経験、経験に大きく依存します。依存性が高く、システム アナリストには高度で豊富な経験が求められます。 -
共同要件計画 (JRP)
JRP は要件を取得する比較的高価な方法ですが、非常に効果的な方法でもあります。主要なユーザー代表、システム アナリスト、開発チームの代表者が集まり、組織的な要件について議論します通常、この会議の参加者数は6 ～ 18 名で、所要時間は 1 ～ 5 時間です。
JRP の主な目的は、要件を分析して検証することではなく、要件を収集することです。JRP を実施する際には、次の主な原則を理解する必要があります。
① JRP を実施する前に、詳細な議題を策定し、厳密に従う必要があります。
② 定められたスケジュールに従って実施します。
③ 会議の内容はできるだけ完全に記録するように努めてください。
④ ディスカッション中は専門用語の使用を避けるようにしてください。
⑤ 紛争解決スキルを駆使する。
⑥ 会議中は十分な休憩時間を設けます。
⑦チームの合意形成を促す。
⑧ JRP に参加するすべての関係者は、事前に合意されたルールを遵守するようにしてください。
2.3 要件分析
要件分析: 優れた要件には、曖昧さのなさ、完全性、一貫性、テスト容易性、確実性、トレーサビリティ、正確性、必要性などの特性が備わっている必要があるため、分析者は乱雑なユーザー要件を組み合わせて、期待をユーザーのニーズに変換することが要件分析の仕事です。
要件分析の作業:
(1)システムコンテキストスコープ図の作成
(2)ユーザーインターフェイスのプロトタイプの作成
(3)要件の実現可能性の分析
( 4)要件の優先順位の決定
(5)要件のモデルの確立
(6)データの作成辞書
(7) QFD (品質機能展開) を使用する
2.3.1 構造化分析手法-SA
構造化分析手法SAの中核となるのがデータ辞書です。このコアの周囲には、データ モデル、機能モデル、および動作モデル (状態モデル)という 3 つのレベルのモデルがあります。
構造化分析の手順は次のとおりです。
(1) ビジネスの状況を分析し、現在の物理モデルを反映したデータ フロー図 (Data Flow DiagramDFD) を作成します。
(2) 等価ロジスティックモデルの DFD を導出します。
(3) 新しい論理システムを設計し、データ辞書とプリミティブ記述を生成します。
(3) マンマシンインターフェースを確立し、ターゲットシステムの物理モデルの代替 DFD を提案します。
(5) さまざまなオプションのコストとリスクレベルを決定し、それに応じてさまざまなオプションを分析します。
(6) プランを選択します。
(7) 完全な要件仕様を確立します。
構造化分析手法SAにはデータフローとコントロールフローがあり、よく使われる手法としてはデータフロー図(DFD)やデータディクショナリがあります。
2.3.1.1 SA - データディクショナリ DD
データ ディクショナリは要件分析モデルの中核です。これは、データ フロー図内のデータ フローまたはファイルを構成する各データ フロー、ファイル、プロセス、およびデータ項目の説明です。
データ ディクショナリには、データ フロー、データ項目、データ ストレージ、基本処理の 4 つのカテゴリのエントリがあります。データ要素、データ構造、データ フロー、処理ロジック、外部エンティティが含まれます。以下に示すように:
2.3.1.2 SA - データ フロー図 DFD
データ フロー ダイアグラム (DFD) は、データ フロー図を使用して機能モデルを表現します。DFD は、システムによって完了する機能を記述します。データの送信と処理の観点から、グラフィック シンボルを使用してシステムの各コンポーネントの機能を記述し、レイヤーごとの細分化によるそれらの間のデータ転送の状況を示し、システムによって完了する機能を示します。以下に示すように:
このうち、DFD には「トップレベル DFD マップ」と「0 レイヤ DFD マップ」もあります。
上図に示すように、「絵素」には次のような記述があります。
次のような間違った DFD 図が添付されています。
上に示すようなエラー:
処理 3.1.2 は入力はありますが出力はありません。これは「ブラック ホール」と呼ばれます。
処理 3.1.3 には出力がありますが、入力はありません。それを「奇跡」と呼びましょう。
処理 3.1.1 では、入力が出力を生成するのに十分ではありません。これを「グレー ホール」と呼びます。
2.3.1.3 SA - 状態遷移図 STD
状態遷移図は動作モデルを表すために使用されます。STD は、システムの状態と、システムの状態遷移を引き起こすイベントを記述して、特定のイベントの結果としてどのようなアクションが実行されるかを示すことによってシステムの動作を表します。以下に示すように:
2.3.1.4 SA - ER図/エンティティ関係図
ER 図は主にエンティティの属性とエンティティ間の関係を記述します。なお、ERモデルは構造化時代のモデル・産物であり、オブジェクト指向やUMLには存在しません。以下に示すように:
弱い存在とは何でしょうか？
例: 人事管理システムでは、従業員の子供に関する情報は従業員の存在に基づいています。子供エンティティは弱いエンティティであり、子供と従業員の関係は依存関係です。したがって、従業員は存在であり、強い存在にもなり得るのです。
強いエンティティと弱いエンティティの関係は 1:1 または 1:N のみです。
2.3.2 オブジェクト指向分析手法 - OOA
いくつかの関連する概念
| 物体 | 属性[データ] + メソッド[操作] + オブジェクトID/識別ID |
|---|---|
| クラス [詳細は以下を参照] | エンティティクラス/コントロールクラス/バウンダリクラス エンティティクラス：データ型を問わずデータベースと対応関係があることが多い コントロールクラス：エンティティクラスとバウンダリクラスを繋ぐクラスバウンダリクラス： 外部と通信する クラスシステムの境界3 つの類似した MVC モデル間の関係、それらの考え方は同じ |
| 継承と一般化 | 再利用メカニズムは、一種の密結合です。親クラスが変更されると、サブクラスも変更する必要があるためです。継承は既存のインスタンスに基づいて行われます |
| カプセル化 | オブジェクトのプロパティと実装の詳細を非表示にし、インターフェイスのみを外部に公開します |
| ポリモーフィズム | 異なるオブジェクトは同じ情報を受け取り、異なる結果を生成します。 |
| インターフェース | メソッド定義のみを持ち、メソッド実装を持たない特別なクラス |
| 過負荷 | クラスには、同じ名前で異なるパラメーターの型を持つ複数のメソッドを含めることができます。同じ名前でパラメータが異なる関数の特徴は次のとおりです。 |
| 消息和消息通信 | メッセージは非同期で通信されます |
| 上書きと書き換え | サブクラスの同じ名前のメソッドは、親クラスの同じ名前のメソッドをオーバーライドします。 |
| 組み合わせと集約 | 集合関係：自動車部品と車両全体の関係（全体と部品のライフサイクルは異なる） 結合関係：部門と会社間の関係。会社が倒産したら部門は終わる（全体のライフサイクルは部品のライフサイクルと同じ） |
OOA は、大まかに次の 5 つの基本ステップに従います。
(1)オブジェクトとクラスの決定: ここで言うオブジェクトとは、データとその処理方法を抽象化したもので、現実世界の特定のものに関する情報を保存および処理するシステムの能力を反映しています。クラスは、複数のオブジェクトに共通のプロパティとメソッドのコレクションの記述であり、クラス内に新しいオブジェクトを作成する方法の記述が含まれます。
(2)構造を決定する: 構造とは、問題ドメインの複雑さと接続関係を指します。クラスのメンバー構造は一般化と特殊化の関係を反映し、全体部分構造は全体と部分の関係を反映します。
(3)テーマを決める：テーマとは、物事の全体像や全体の分析モデルを指します。
(4)属性の決定: 属性は、オブジェクトのインスタンスまたは分類構造を記述するために使用できるデータ要素であり、図に指定したり、オブジェクトのストレージに指定したりできます。
(5)メソッドの決定: メソッドは、メッセージを受信した後に実行する必要がある処理メソッドです。メソッドは図で定義し、オブジェクトのストレージに指定する必要があります。すべてのオブジェクトと構造について、追加、変更、削除、選択のメソッド自体が暗黙的であり (ただし、これらはオブジェクトのストレージで定義されており、図には示されていません)、一部は表示されます。
2.3.2.1 OOA - UML
OOA 要件分析用の UML (プラットフォームおよび言語に依存しない統一モデリング言語) は、基本的な構成要素、ルール、および共通メカニズムで構成されます。
UML の基本構成要素 [重要なコンポーネント]
| 事務 | 説明する |
|---|---|
| 構造的なもの | クラス、インターフェース、コラボレーションのユースケース、アクティビティクラス、コンポーネント、ノードなどの最も静的な部分 |
| 行動的なこと | メッセージ、アクション シーケンス、接続などのアクションを時間と空間で表現します。 |
| 物事をグループ化する | パッケージやコンポーネントなどの箱と考えてください。 |
| 物事に注釈を付ける | UML モデルの解釈部分。モデル要素の説明、図示、および注釈付け |
UML の基本構成要素間の関係 [物事を密接に結び付ける]
| 関係 | 説明する |
|---|---|
| 依存関係 | あるものが変化すると、それは別のものに影響を及ぼします。包含関係と拡張関係はどちらも依存関係です。 |
| 一般化関係 | 特殊な一般関係。特殊な要素のオブジェクトは一般的な要素のオブジェクトを置き換えることができます |
| 接続関係 | オブジェクト間の接続であるチェーンについて説明します。 |
| 関係を実現する | 接口与类之间的关系，一个类指定了由另一个类保证执行的契约 |
UML基本构造块之图【多个相互关联的事物的集合】
| 图 | 描述 |
|---|---|
| 静态图 | 结构图 |
| 类图 | 描述一组类，接口协作和它们之间的关系。 |
| 对象图 | 描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。 |
| 构件图 | 也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。 |
| 部署图 | 表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。 |
| 制品图 | 描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。 |
| 包图 | 将某些类放入“包”中，通过包图来组织业务概念图。 |
| 组合结构图 | 展示该部分内容“内部”参与者的配置情况。这个图不常用。 |
| 动态图 | 行为图 |
| 用例图 | 系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。 |
| 顺序图 | 强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。 |
| 通信图 | 也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。 |
| 定时图 | 消息跨越不同对象或角色的实际时间。交互图的一种。 |
| 交互概览图 | 活动图与顺序图的结合。这个图不常用。 |
| 活动图 | 类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。 |
| 状态图 | 从某个物品的状态是如何变化的角度来展示流程。 |
UML规则
是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。
UML公共机制
是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。
UML中的概念
- 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
- 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
- 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
- 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
- 用例：是描述一系列的动作，产生有价值的结果。
- 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
- 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
2.3.2.2 OOA - UML 4+1视图
现有的UML，再有的UML视图
UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。
“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。
2.3.2.3 OOA - 用例模型与分析模型
在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。
2.3.2.4 需求分析工具
2.3.2.4.1 使用用例建模系统需求
用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。
用例建模促进并鼓励了用户参与，具有如下优点：
- 提供了捕捉功能需求的工具。
- 有助于将系统分解为更易于管理的小块。
- 提供了与用户以及其他关心系统的关联人员进行交流的工具。
- 辅助估计项目范围、投入和进度。
- 提供了需求跟踪的工具。
- 提供了确定数据对象或实体的起点。
- 提供了设计用户和系统接口的功能规格说明。
为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。
1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：
- 对架构设计的重要影响。
- 容易实现但包含重要功能。
- 包含有风险、时间紧迫或复杂的功能。
- 需要大量的研究或者新的、有风险的技术。
- 包含主要的业务功能。
- 将增加或者减少费用。
2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：
- 系统事件及其状态的图形化表述有利于对系统功能的理解。
- 有助于确定遗漏的用例。
- 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。
2.3.2.4.2 数据建模与分析
数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。
数据建模的系统概念：
- 实体
- 属性（数据类型、域、默认值）（键）
- 关系
如何构造数据模型？
- 获取实体。
- 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
- 基于键的数据模型：确定每个实体的键。
- 泛化层次体系：父实体、子实体。
- 具有完整属性的数据模型。
- 分析数据模型：规范化（第一范式、第二范式、第三范式）。
- 将数据需求映射到地点：数据–地点–CRUD矩阵。
2.3.2.4.3 过程建模
过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。
过程建模的系统概念：
- 外部代理：常见的同义词包括外部实体。
- 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
- 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
- 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。
如何构造过程模型：
- 构造上下文数据流图：0号数据流图。
- 构造系统功能分解图。
- 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
- 事件分解图：把事件处理过程增加到分解图中。
- 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
- 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
- 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。
2.3.2.4.4 面向对象分析与建模
面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。
2.4 需求定义（形成需求规格）
需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。
严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。
原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。
2.5 需求确认与验证
需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：
（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。
需求验证包括了需求评审和需求测试。
需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。
需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。
三、 需求管理（支持，保障）
在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
3.1 定义需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。
3.2 需求的状态
在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。
3.3 需求变更管理
CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。
3.4 需求变更管理过程
（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。
常见的需求变更策略：
(1) すべての要件変更は、変更管理プロセスに従う必要があります。
(2) 承認されていない変更を伴う設計および実装作業は行わないでください。
(3) 変更は、どの変更を実施するかプロジェクト変更管理委員会によって決定される必要があります。
(4) プロジェクトのリスク保有者が変更内容を理解できること。
(5) 変更要求の元のドキュメントをプロジェクト構成ライブラリから削除または変更してはなりません。
(6) 統合された各要件変更は、水平的なトレーサビリティを維持するために、承認された変更要求まで追跡可能でなければなりません。
3.5 需要リスク
危険な行為には次のようなものがあります。 ① 参加するユーザーが不足している。②ユーザーの分類は無視されます。③ユーザーの要望は増え続けています。④ 曖昧なニーズ。⑤不要な機能。⑥流線型すぎるSRS。⑦不正確な推定。
変更の理由： ① 外部環境の変化。②要件や設計が十分に完成していない。③新しい技術の登場。④ 会社の組織再編により業務プロセスが変化する。
3.6 要件の追跡
SRS 内の各ソフトウェア構成項目の要件は、関連するシステム (またはサブシステム) の要件まで双方向に追跡可能である必要があります。いわゆる双方向追跡には、順方向追跡と逆方向追跡が含まれます。順方向追跡とは、SRS の各要件がその後の作業結果で対応する点を見つけることができるかどうかを確認することを指します。逆方向追跡は、逆追跡とも呼ばれ、設計を確認することを指しますドキュメント、コード、テスト ケース、その他の作業結果をすべて SRS で見つけることができるかどうか。