系统上下文
第五章 系统和上下文边界
系统边界：定义哪些物质的对象属于系统并且在系统开发的过程中被改变。
上下文边界：定义需求是需要考虑的物质对象和非物质对象。
一、上下文
系统上下文：系统所处的环境中与定义、理解和解释系统需求相关的那些部分。
- 系统边界
系统边界：通过定义系统边界，涉众将属于系统的方面与系统上下文、无关环境，即不属于系统本身的方面，分割开来。
- 上下文边界
上下文边界：上下文边界将系统上下文和被认为与系统开发无关的环境分割开来。
上下文方面：
上下文方面是系统上下文中的各种物质和非物质对象，如人、技术与非技术性系统、过程与物理规律等。
e.g.上下文方面与系统间关系的实例：
与系统存在直接交互关系的上下文方面实例：
银行客户使用ATM机从账户中取款。在为ATM机定义需求时，必须考虑各种银行客户的 详细情况。例如，如果ATM机可能会被国际客户使用，那么用户接口必须支持多种语言。
与系统没有交互关系但仍然影响系统需求的上下文方面实例：
法律要求进入到银行系统中以及在系统中使用的敏感数据项必须使用某些加密标准加密。
二、系统边界
系统边界：
属于系统之内，在开发过程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分隔开。
信息源（source）和接收单元（sink）
-
人
-
其他技术或非技术系统
-
传感器和执行器
信息源和接收单元通过系统接口与系统交互，接口：
-
人机接口
-
软件接口
-
硬件接口
系统边界的意义：
-
明确哪些属于系统；
-
确定哪些方面属于系统边界之外；
-
定义系统边界时应该改让所有的涉众参与其中；
-
设法就系统边界达成一致。当你无法确定某一对象是都属于系统时，把其放到灰色区域中；
-
经常检查已经定义的系统边界是否仍然有效。注意系统边界所有的扩大或缩小；
-
如果系统边界需要进行调整，验证所做的调整是都影响已定义的需求。
三、上下文边界
主要分为两类
-
系统上下文
-
无关环境
定义上下文边界：
-
按照四种上下文刻面，将上下文和无关环境分离开；
-
如果不确定某些上下文方面是否会影响系统需求，那么将这些归为灰色区域；
-
如果和上下文方面无关，那么放在无关环境；
添加新需求时检验上下文相关性：
-
定义新需求（例如功能）时，检查被归类为无关的上下文方面是否会由于该新需求的添 加而变成与系统相关的上下文方面；
-
使用目标和场景检查系统环境中各个方面是否与系统相关。如果一个上下文方面是相关 的，那么它应该影响至少一个目标或场景；
-
重复执行这些步骤，因为系统和上下文边界影响目标和场景的定义，反之亦然（见第七 部分的COSMOD-RE方法）。
用例子阐述上下文边界：
系统边界中圈定的是“可变”的部分；上下文边界中圈定的是“相关”的部分。
枚举书上的需求
R23:所规划的运输方式应当为旅客到达目的地提供便捷的行程。
示例
比如上下文信息“该地是个没有机场的海岛”（系统开发过程没有办法改变机场和海岛，因此属于系统上下文）基本需求则应该放在“系统”范畴中。
上下文可能对某个需求有直接影响，比如直接限制对需求的理解，也有可能有间接影响，通过上下文方面对其他几个需求的影响而影响该需求。
为了避免上下文信息描述中的冗余或交叉。一些项目需要特定的指南，内容包括：
-
针对待开发系统应描述的上下文方面类型
-
上下文信息描述的表示格式和结构
-
用以关联上下文信息和需求的关系类型
-
上下文信息描述的职责。
第六章 系统上下文的结构化组织
一、结构化原则
-
将上下文分为四个上下文刻面
将上下文组织分为多个刻面
-
上下文方面的分类
-
将每个上下文刻面系统化处理
-
定义标准化模式
-
定义不同类型的关系
各刻面中上下文的分类
-
- 四个上下文刻面：
主体刻面：包含了系统上下文中与系统相关的对象与事件。
换言之，与这些主体刻面中的对象和时间相关的信息必须在系统中加以表示。
例子：测量车速的软件衡量抽象对象“速度”
主体刻面包含了一些影响系统中对象和时间相关信息表示的方面，力图禁止或限制软件密集型系统对某类数据进行记录的法规，限制所记录数据精确性或数据更新频率的法规。
使用刻面：一个软件密集型系统由人或其他系统使用从而达成一个目标或完成某项具体任务。包含了与人或其他系统对本系统的使用相关的所有方面。
例如：已存在的各种使用目标、期待的工作流、具有各种特性的不同用户组、具有不同接口的各种交互模型，以及限制或影响系统使用的法规和标准。
IT系统刻面：待开发的系统最终要被部署在现有IT基础设施上。IT系统可免由运行与技术环境的所有方面构成，包括那些定义了如何使用各种技术与运行环境的约束或指南的仿真和策略。
例如，通信协议，软件平台预定义的一组操作系统。
开发刻面：包含了与系统开发过程相关的上下文方面，包括过程准则与约束、开发工具、质量保障方法、成熟度模型、质量认证，以及其他确保软件密集型系统质量（如安全性、保密性）的数段或技术。
例如：某项标准可能要求特定的测试准则。
- 三类上下文方面
-
需求来源：定义系统需求的根源
三类需求来源：涉众、文档、系统；
涉众：
涉众是在待开发系统中存在潜在利益的人或组织 。涉众对于系统通常有自己的需求。
典型涉众实例包括：客户、系统开发者、系统用户、架构师、领域专家、软件开发人员、测试人员、维护人员。
典型高层权威机构利益的涉众包括：隐私保护官员、法律专家、专利代理人等。
现有文档：
包括通用文件（如法律、标准）、特定组织文件（开发指南、组织内通用指南）或描述同类开发制品或原有系统的文档（用户手册、系统体系结构文档、需求规格说明、测试文档）
有价值的需求来源的文档：
- 市场分析报告
- 客户问询信件
- 原有系统的需求文档
- 遗留系统的需求文档
- 遗留系统的体系结构文档
- 遗留系统的源代码
- 遗留系统的测试文档
- 遗留系统的用户手册
- 业务过程文档
- 技术过程描述
- 对业务过程的描述
- 遗留系统的变更请求文档
- 遗留系统的错误报告
- 遗留系统的错误修正报告
- 法律
- 网站上的产品规格说明
- 保密指南
- 标准
- 易用性测试文档
- 其他
现有系统：
现有系统本身
- 遗留系统和原有系统
- 竞争对手的系统
- 类似系统
-
上下文对象：上下文对象是一个上下文刻面中需求在需求工程里设计或进行考虑的人以及物质和非物质对象。涉众的必须标识出相关的上下文对象并抽取关于它们的信息。
-
人，用户、客户、管理员等
-
法律主体，项目开发所涉及的组织结构
-
物质对象，商品或结构元件
-
非物质对象：物理变量、数学公式、业务过程、法律或生产过程。
-
-
上下文对象的属性和关系：属性和关系表达了关于上下文对象的一些附加信息，更加精确地刻画了各个上下文刻面中上下文对象。
二、四个上下文刻面中的相关上下文方面
-
主体刻面
- 需求来源：
主体刻面，领域专家是一个重要的需求来源。主体刻面的不同方面或特定部分，可能需要多个不同的领域专家参与。
-
上下文对象：
-
相关数据需要被储存的人（客户、供应商）
-
物质对象（生产商品、消费商品）
-
非物质对象（温度、速度、数学公式）
-
过程（软件密集型系统所支持或提供自动化的生产过程或业务过程）
e.g. 主体刻面中上下文对象
对于一个汽车安全系统而言，主体刻面中包括以下相关的上下文对象。
- 汽车本身以及相关的部件，如引擎、轮胎、刹车
- 汽车使用者，如驾驶员和副驾驶
- 行驶过程中的其他参与者，前面行驶的车辆以及行人
- 汽车所处的外部环境状况，如温度、路况等
-
-
属性和关系
-
精确性
-
现实性
-
法律要求
-
-
使用刻面
-
需求来源：
- 系统的直接或者间接用户
e.g. 汽车安全系统中 直接用户：驾驶员 间接用户：副驾驶
- 接口设计专家
e,g, 欧洲汽车人机接口设计原则目录中有一条规定：“系统设计应该避免分散驾驶员的注意力，同时也不允许向驾驶员提供任何形式的视觉娱乐。”
- 领域模型（业务过程模型等）
-
上下文对象
- 用户组
e.g. 汽车的用户组：运动型驾驶员 安全导向性驾驶员
-
用户接口的输入方式
语音、可视化、触摸、声控....
-
属性和关系
-
使用刻面中的上下文对象中通常存在相互关系
-
约束条件
-
当前运行状态会影响使用流程
普通模式、节能模式、故障、恢复应急模式等
-
-
-
IT系统刻面
-
需求来源
-
进行IT系统环境规划、设计以及运行的所有人员。
包括：系统架构师、硬件开发人员、测试专员、维修专家、CTO等。
-
市场趋势策略专家
技术咨询人员、软硬件组件的供应商
-
相关文档
开发企业的IT策略文档、客户的IT策略文档等
-
已存在的系统以及环境
-
-
上下文对象
-
系统待开发的软硬件组建
-
待开发系统的运行和维护
-
相关企业的IT策略
-
-
属性和关系
性能特性、可用性、承约人和供应商的责任义务等
-
-
开发刻面
-
需求来源
-
开发阶段的涉众
-
过程工程师
-
过程经理
-
过程执行者
-
-
开发文档
-
开发标准
-
开发指南
-
方法描述
-
最佳实践文档
-
项目计划
-
-
-
上下文对象
-
角色定义
-
制品定义
-
活动定义
-
工具
-
资源可用性和资源约束
-
-
属性与关系
-
供应商-客户关系
要求、开发标准（如SPICE、CMMI、ISO 9000）等
-
-
网友评论