定义系统边界

定义系统边界      
goldway 发表于 2006-8-13 9:22:00

 在定义需求时,必须定义要开发的计算机系统的边界,即确定哪些是系统需求,哪些是和系统相关的操作过程的需求,哪些是在系统范围之外的需求。

    需求提供者经常不大了解系统应该包含哪些内容,因此他们可能会提出不恰当的需求。需要通过系统边界定义初步剔除那些明显在系统范围之外的需求,以免这些需求干扰后续的分析过程。

    检查每项原始需求,将它们区分为系统需求、过程需求和应该拒绝的需求。考虑如下问题:

  1. 某项需求是否是基于不完整的或者不可靠的信息做出的?
  2. 某项需求的实现是否需要在系统已定义的数据库之外的信息?
  3. 某项需求是否和系统的核心功能相关?
  4. 某项需求是否牵涉到系统之外的功能或者设备的性能?

    对于问题1和问题2可以判断是否为过程需求,如果是过程需求,则要求系统的操作者提供这些信息,否则需要复审系统应该处理的数据。

   对于问题3和问题4可以判断是否是系统边界以外的需求。如果是,则它可能是不必要的,也可能是无法实现的需求。

   对于于操作过程相关的需求和系统边界之外的需求,必须准备一些技术的和经济的论据,说明这些需求被拒绝的理由。这些论据应该是基于这个组织已定义的业务目标或者系统可行性研究的结果。

   系统边界的定义和需求的检验都需要通过需求的复审来进行,需求的复审之前可以定义适当的分析检验表,如:

 检验表项 检验内容的描述
 草率设计 该需求是否包含不成熟的设计或实现信息?
 组合需求 是单独的需求还是可以细分为几个不同的需求?
 多余需求 只是系统的装饰而不是真正必须的吗?
 使用非标准硬件 该需求必须使用非标准的硬件还是软件?
 符合业务目标 该需求是否符合已定义的业务目标?
 需求多义性 该需求对不同的人是否可能有不同的理解?
 需求可实现性 根据现有的实现技术,是否可以实现该需求?
 需求可测试性 测试工程师是否可以从需求的表述中导出测试已判断系统是否符合需求?

### 如何在 StarUML 中绘制系统边界 #### 绘制准备 为了更好地理解并实现系统边界的绘制,在StarUML环境中,先要熟悉其基本界面布局和功能区。通过这些准备工作能够更加高效地完成绘图任务[^2]。 #### 创建新项目与模型元素 启动StarUML之后,新建一个项目用于保存即将创建的各种图表文件。接着,在该项目下建立一个新的Use Case Diagram(用例图),因为系统边界通常是在用例图中体现出来的[^3]。 #### 添加参与者和用例 利用左侧工具栏中的图标资源来添加Actor(即参与者)至工作区域;随后同样方法加入多个Use Case对象代表不同业务逻辑的功能模块。按照实际需求调整它们之间的相对位置以便后续连线操作[^4]。 #### 定义系统边界 选中矩形框形状的组件放置于画布之上作为物理上的分隔线——这就是所谓的“系统边界”。将之前布置好的各个Use Case拖拽进该区域内表明哪些属于内部处理流程部分;而把Actors保持在外侧则暗示着他们是外部交互方。 #### 设置属性与样式优化 双击进入编辑模式可修改边界线条的颜色、粗细度等外观特性以增强视觉效果区分内外部关系。此外还可以给定标签名比如`System Boundary`帮助读者快速识别此图形的意义所在[^1]。 ```mermaid graph TD; A[顾客] --> B(提供剧目名称); C[售票员] --> D{查询演出信息}; E((显示信息)) --> F[选择座位]; G[确认选择] --> H((计算费用)); I[支付过程] --> J((更新记录)); K[(打印票据)] --> L[离场] ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值