1. system Requirement in SE lecture
1.1. システムの基盤
2. model in SE lecture
2.1. 問題事象のcontextとcontentとstructureとbehaviorを明らかにするもの
3. Diagram in SE Lecture
3.1. Context
3.2. Behavior
3.3. Control Flow
3.4. Data Flow
3.5. Entity Relationship
3.6. FFBD
3.7. IDEF
4. Context in 1362: ConOps
4.1. system overviewを図式で描くことを強く推奨
4.2. 図式方式としてContext diagram，Object diagram，structure chart，DFD，Storyboards，ERなどがある．
4.3. 図式で描くと，異なる背景の読み手に対し，共通の理解を促しやすい
4.4. user dataとして提供
4.4.1. ソフトウエアの概観
4.4.2. システムにアクセスするための情報
4.4.3. 入力コマンドと返り値
4.4.4. エラーメッセージ
4.4.5. 操作環境
4.4.6. 合理的な決定基準
4.5. Requirement dataとして提供
4.5.1. 期待される機能
4.5.2. operational context
4.5.3. 性能上の制約と例外
4.5.4. 品質に達成しているかどうかの基本テスト
4.5.5. 合理的な決定基準
5. Context in 2475: Vocablary
5.1. A-0 context diagram
5.1.1. ValidなIDEF0モデルで要求されるcontext diagram
5.1.2. 一つの箱が，最上位の一つの機能を示す
5.1.3. 入力，制御，出力，メカニズムを箱にくっつけて示す
5.1.4. モデルの正式名称と略称とモデルの目的とモデルの視点を書く
6. Context in 29148: Requirement engineering
6.1. Stakeholder requirements definition process
6.1.1. outcomes
6.1.1.1. 要求されているシステムの特徴とプロダクトの利用コンテキスト
6.1.1.2. システムソリューション上の制約の特定
6.1.1.3. ステークホルダ要求と、ステークホルダおよび各ニーズへのトレーサビリティが完璧であること
6.1.1.4. ステークホルダ要求が特定されていること
6.1.2. According to 15288
6.1.3. Activities
6.1.3.1. Elicit stakeholder requirement
6.1.3.1.1. Elicit stakeholder requirement
6.1.3.1.2. define stakeholder requirement
6.1.3.2. Define stakeholder requirements
6.1.3.2.1. 制約要求の定義：現存する合意事項，マネジメントの決定事項，技術的決定事項
6.1.3.2.2. 代表的な一連動作の集合を定義し，すべての要求されるサービスを特定する．
7. Stakeholder Requirement in 15288
7.1. 特定のステークホルダー別のneeds, wants, desires, expectations and perceived (明らかになっている) constraints
7.2. Operational concept document (OpsCon)
8. Customer Requirement in SE lecture
8.1. tractabilityは，カストマー要求がデザインに反映しているということが確実であることを監査するものである．
9. Context Analysis in SE Lecture
9.1. 各モデルごとにcontext diagramを作成し，モデル境界を再表現する．
9.2. Activity in Concept of Operations
9.2.1. １．Context Modelの定義
9.2.2. ２．ＦＦＤＢの開発
9.2.3. ３．システムと外部システムのインタフェース，そして環境と内部構成物とのインタフェースの定義
9.2.4. ４．タイムラインの開発
9.2.5. ５．CONOPS diagramと記述のエンドユーザーやカストマーとのレビュー