全过程仿真案例教学(答案)
- 格式：pdf
- 大小：871.83 KB
- 文档页数：23
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需 求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目 视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的 任务，这在使用实例（ use case）文档或方案脚本（ s c e n a r i o）说明中予以说明。功能需 求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务， 从而满足了业务需求。所谓特性( f e a t u r e )是指逻辑上相关的功能需求的集合，给用户提供 处理能力并满足业务需求。软件需求各组成部分之间的关系如下图所示。
可以分级建立用例模型，用以区分业务需求和功能需求，业务需求详细程度遵循“一页纸”原则。 用例描述可分为基本用例（essential use case）和具体用例（concrete use case）。 3，需求开发活动
需求开发活动包括以下步骤： 1. 确定用户类和重要等级，选择每类用户的代表(注意：建议根据与系统的交互方式分类)。
问题五：建立用例视图时，不知道何时完成 没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的
同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的 构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。 • 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重 要性的顺序来确定使用实例的。 • 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的 使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的 其它使用实例的可选过程。 • 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。 • 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工 作。 • 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收 集需求的工作。
目录
第二部分 初始阶段案例练习.................................................................................................................... 1 2.3.2 自助订餐系统：模拟演练情况点评 ........................................................................... 1 2.3.4 能力评估系统：模拟演练情况点评 ........................................................................... 4
在项目的早期阶段，列出系统可能包括的功能区。在考虑多个项目的情况下，你可能要 列出公共函数的清单，例如：写错误日志、备份与恢复、报表、打印、预览功能、格式和用 户最喜爱的特性。然后在需求开发阶段，把你所确定的功能与原始列表进行比较。如果没有 发现不一致性，则你可能完成了收集需求的工作。
3
2.3.4 能力评估系统：模拟演练情况点评
飞行 ID
职行员类建立继承关系 由于飞行员的主副驾驶的身份是不确定的，所以产生主、副驾驶类不合适。
3.3.6 城铁门禁系统：模拟演练情况点评
问题一：采用有限状态机的设计模式，可以解决很多类似状态转换的情况
需求开发可进一步分为：问题获取（elicitation）、分析(analysis)、编写规格说明
1
（specification）和验证（verification）四个阶段。这些子项包括软件类产品中需求收集、评价、 编写文档等所有活动。
需求管理需要“建立并维护在软件工程中同客户达成的契约”。这种契约都包含在编写的需求 规格说明与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需 求应用到产品中。 2,软件需求的不同层次
问题一：业务流程模型和用例模型混淆，忽视业务过程 z 用例模型关注的是系统的输入和输出，不关心业务的实现过程。 z 业务流程建模的视角在业务上，关注业务的约束和边界。
问题二：过度关注技术风险，忽视业务风险 z 项目分为基础数据采集、未来任务预计、模型计算和评估结果展现，四个子系统； z 从技术上评估结果展现风险最小，但从业务上它最重要，所以先做它。
问题都弄清楚。
问题四：定义里程碑评审标准时，用例模型和文档描述详细程度无标准 z 牢记写文档和模型的目的，促进合作和降低交换成本。 z 需求评审一般在细化阶段的概要设计结束，详细设计开始时才进行。这时，一般只是走查。 用例是基本用例也可，具体情况参考下文。 z 例如，如果项目的需求、架构和程序，是一个人在干，那么评审的重点是给用户确认的部分。 如果，需求和架构是分开的，那么评审需求的标准是：架构和程序人员可以据此无歧义地工 作。 z 界面原型的目的是表明干些什么，而不是约束开发人员怎么干。
第四部分 构建阶段案例练习.................................................................................................................. 15 4.3.2 能力评估系统：模拟演练情况点评 .......................................................................... 15
下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠 正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。 而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替 换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显 示提供替换词的对话框以及实现整个文档范围的替换。
第七部分 强化练习 .................................................................................................................................... 21 7.2 租借公司管理系统：模拟演练情况点评.............................................................................. 21
第三部分 细化阶段案例练习.................................................................................................................... 5 3.3.2 能力评估系统：模拟演练情况点评 ............................................................................ 5 3.3.4 飞行员薪酬系统：模拟演练情况点评...................................................................... 11 3.3.6 城铁门禁系统：模拟演练情况点评 .......................................................................... 11
第五部分 交付阶段案例练习.................................................................................................................. 20 5.3.2 加油站发油系统：模拟演练情况点评...................................................................... 20
2
2. 确定产品前景和项目范围（主要从客户经理或负责人等处获得）。 3. 获取每个用户类的需求（主要方法有：面谈、现场观察、示范、文档调查、问卷调查、原型开
发、需求专题研讨会、情节串联法等），详细参见《涉众请求》文档模版。 4. 分析源于用户的信息以区别：业务需求、功能需求、业务规则、质量属性、建议解决 5. 方法和附加信息。 6. 了解实际用户任务和目标以及这些任务所支持的业务需求，时刻注意要在项目范围内。 7. 确定用例（区分基本用例和详细用例；用例和需求规格说明书的关系） 8. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 9. 了解相关质量属性的重要性。 10. 商讨实施优先级的划分。 11. 将所收集的用户需求编写成规格说明和模型。 12. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将
4
第三部分 细化阶段案例练习
3.3.2 能力评估系统：模拟演练情况点评
问题一：在选择高层架构时，没有认真体会项目背景的区别 z 选择代理体系结构：忽略了学习新技术的风险，并极大地扩大了项目范围，提高了成本。 z 选择多层体系结构但数据是集中的：银行的人员容易采用该结构，但这个项目对数据的实时性和
安全性的要求和银行项目不同，所以该设计不好。 z 选择多层体系结构但数据逐级上报，分布式存储，这种架构更符合安全性要求。 问题二：为接口分包时，没有考虑单位组织和业务情况 如有些单位的大项目，由总体组统一控制。这样的单位会把接口集中在一个包中，统一管理；有些为 芯片开发二次接口的单位，将接口放 B 包中；有些开发业务系统的单位如安防系统，将接口放 A 包中。 分包时根据业务情况的不同，有不同的分包原则。一般是由主业务方控制接口。 问题三：设计方案时没有考虑变更的情况，无法适应变化 进行面向对象分析，步骤如下：
可以分级建立用例模型，用以区分业务需求和功能需求，业务需求详细程度遵循“一页纸”原则。 用例描述可分为基本用例（essential use case）和具体用例（concrete use case）。 3，需求开发活动
需求开发活动包括以下步骤： 1. 确定用户类和重要等级，选择每类用户的代表(注意：建议根据与系统的交互方式分类)。
问题五：建立用例视图时，不知道何时完成 没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的
同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的 构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。 • 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重 要性的顺序来确定使用实例的。 • 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的 使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的 其它使用实例的可选过程。 • 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。 • 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工 作。 • 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收 集需求的工作。
目录
第二部分 初始阶段案例练习.................................................................................................................... 1 2.3.2 自助订餐系统：模拟演练情况点评 ........................................................................... 1 2.3.4 能力评估系统：模拟演练情况点评 ........................................................................... 4
在项目的早期阶段，列出系统可能包括的功能区。在考虑多个项目的情况下，你可能要 列出公共函数的清单，例如：写错误日志、备份与恢复、报表、打印、预览功能、格式和用 户最喜爱的特性。然后在需求开发阶段，把你所确定的功能与原始列表进行比较。如果没有 发现不一致性，则你可能完成了收集需求的工作。
3
2.3.4 能力评估系统：模拟演练情况点评
飞行 ID
职行员类建立继承关系 由于飞行员的主副驾驶的身份是不确定的，所以产生主、副驾驶类不合适。
3.3.6 城铁门禁系统：模拟演练情况点评
问题一：采用有限状态机的设计模式，可以解决很多类似状态转换的情况
需求开发可进一步分为：问题获取（elicitation）、分析(analysis)、编写规格说明
1
（specification）和验证（verification）四个阶段。这些子项包括软件类产品中需求收集、评价、 编写文档等所有活动。
需求管理需要“建立并维护在软件工程中同客户达成的契约”。这种契约都包含在编写的需求 规格说明与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需 求应用到产品中。 2,软件需求的不同层次
问题一：业务流程模型和用例模型混淆，忽视业务过程 z 用例模型关注的是系统的输入和输出，不关心业务的实现过程。 z 业务流程建模的视角在业务上，关注业务的约束和边界。
问题二：过度关注技术风险，忽视业务风险 z 项目分为基础数据采集、未来任务预计、模型计算和评估结果展现，四个子系统； z 从技术上评估结果展现风险最小，但从业务上它最重要，所以先做它。
问题都弄清楚。
问题四：定义里程碑评审标准时，用例模型和文档描述详细程度无标准 z 牢记写文档和模型的目的，促进合作和降低交换成本。 z 需求评审一般在细化阶段的概要设计结束，详细设计开始时才进行。这时，一般只是走查。 用例是基本用例也可，具体情况参考下文。 z 例如，如果项目的需求、架构和程序，是一个人在干，那么评审的重点是给用户确认的部分。 如果，需求和架构是分开的，那么评审需求的标准是：架构和程序人员可以据此无歧义地工 作。 z 界面原型的目的是表明干些什么，而不是约束开发人员怎么干。
第四部分 构建阶段案例练习.................................................................................................................. 15 4.3.2 能力评估系统：模拟演练情况点评 .......................................................................... 15
下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠 正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。 而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替 换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显 示提供替换词的对话框以及实现整个文档范围的替换。
第七部分 强化练习 .................................................................................................................................... 21 7.2 租借公司管理系统：模拟演练情况点评.............................................................................. 21
第三部分 细化阶段案例练习.................................................................................................................... 5 3.3.2 能力评估系统：模拟演练情况点评 ............................................................................ 5 3.3.4 飞行员薪酬系统：模拟演练情况点评...................................................................... 11 3.3.6 城铁门禁系统：模拟演练情况点评 .......................................................................... 11
第五部分 交付阶段案例练习.................................................................................................................. 20 5.3.2 加油站发油系统：模拟演练情况点评...................................................................... 20
2
2. 确定产品前景和项目范围（主要从客户经理或负责人等处获得）。 3. 获取每个用户类的需求（主要方法有：面谈、现场观察、示范、文档调查、问卷调查、原型开
发、需求专题研讨会、情节串联法等），详细参见《涉众请求》文档模版。 4. 分析源于用户的信息以区别：业务需求、功能需求、业务规则、质量属性、建议解决 5. 方法和附加信息。 6. 了解实际用户任务和目标以及这些任务所支持的业务需求，时刻注意要在项目范围内。 7. 确定用例（区分基本用例和详细用例；用例和需求规格说明书的关系） 8. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 9. 了解相关质量属性的重要性。 10. 商讨实施优先级的划分。 11. 将所收集的用户需求编写成规格说明和模型。 12. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将
4
第三部分 细化阶段案例练习
3.3.2 能力评估系统：模拟演练情况点评
问题一：在选择高层架构时，没有认真体会项目背景的区别 z 选择代理体系结构：忽略了学习新技术的风险，并极大地扩大了项目范围，提高了成本。 z 选择多层体系结构但数据是集中的：银行的人员容易采用该结构，但这个项目对数据的实时性和
安全性的要求和银行项目不同，所以该设计不好。 z 选择多层体系结构但数据逐级上报，分布式存储，这种架构更符合安全性要求。 问题二：为接口分包时，没有考虑单位组织和业务情况 如有些单位的大项目，由总体组统一控制。这样的单位会把接口集中在一个包中，统一管理；有些为 芯片开发二次接口的单位，将接口放 B 包中；有些开发业务系统的单位如安防系统，将接口放 A 包中。 分包时根据业务情况的不同，有不同的分包原则。一般是由主业务方控制接口。 问题三：设计方案时没有考虑变更的情况，无法适应变化 进行面向对象分析，步骤如下：
