文章目录

• 实验一 软件需求分析
• • 实验目的
  • 实验内容
• 「软件开发文档管理」软件开发过程涉及的文档
• • 软件开发阶段
  • 开发过程文档
• 「软件开发文档管理」需求获取
• • 1. 功能需求
  • 2. 非功能需求
• 「软件开发文档管理」需求分析、需求规格说明
• • 1. 需求概述
  • • 1.1 功能需求
    • 1.2 非功能需求
  • 2. 用例模型
  • • 2.1 用例图
    • 2.2 用例规格说明
    • • 2.2.1 UC01 ****用例
      • 2.2.2 UC02 ****用例
  • 3. 概念类分析
  • • 3.1 UC01 ****用例的概念类分析
    • • 3.1.1 候选类及筛选
      • 3.1.2 概念类图
    • 3.2 UC02 ****用例的概念类分析
    • • 3.2.1 候选类及筛选
      • 3.1.2 概念类图
  • 4. 交互行为分析
  • 5. 附录

实验一 软件需求分析

实验目的

• 了解软件需求开发阶段相应活动及其目的；
• 了解常见的软件需求分析方法；
• 逐步熟悉UML建模工具的使用；
• 熟悉需求文档的撰写。

实验内容

• 在整个软件生命周期中涉及到大量的"文档"工作，现假设需要开发相应的软件开发过程文档管理系统，根据软件需求工程方法，请完成需求分析：
  • 根据软件工程的基本思想：
    • 自行讨论分析软件开发过程可能涉及的文档
    • 完成软件开发文档管理的需求获取，包括功能需求和非功能需求；
  • 选择合适的UML建模工具完成需求分析，并形成相应的需求规格说明；
  • 建立小组通过团队协作完成实验工作，但人数不得超过4人（<=4人），而且应有明确的分工，并标明组长等角色及各自具体承担的任务；
  • 图表的绘制建议使用Visio工具软件绘制，也可使用其他工具软件，所得需求分析文档请将其命名为"学号-姓名-需求分析"后提交至网络教学平台。
• 注：本次实验将计入考核成绩，需求文档评价标准如下：
  • 文字内容（20%）
    • 文档标题项设置有条理，符合文档格式规范（10%）；
    • 各项内容编号有次序不混乱（5%）；
    • 专业术语描述合理、准确（5%）；
  • 分析建模（60%）
    • 分析模型内容完整，结构清晰，具有一致性（20%）；
    • 图中元素标识恰当，关系分析合理，数量级标注正确，附加描述清楚（20%）；
    • 图例元素符号无误（10%）；
    • 布局合理（10%）；
  • 文档排版（20%）
    • 能够按照文档格式要求进行排版。版面整洁，图表格式符合要求。

「软件开发文档管理」软件开发过程涉及的文档

软件开发阶段

1. 项目分析

2. 需求分析

3. 软件设计

4. 软件构造

5. 软件测试

6. 软件交付

7. 软件维护

8. 其他

开发过程文档

「软件开发文档管理」需求获取

1. 功能需求

2. 非功能需求

「软件开发文档管理」需求分析、需求规格说明

1. 需求概述

在此应当加入引言，引言部分是整个需求规格说明的概览，应当可以帮助读者更好地阅读和理解文档：
对整个软件项目的目的或背景进行说明，也即为什么要进行该软件系统的开发。
-从总体上描述影响产品和需求的因素，说明对该软件系统的总体预期。

1.1 功能需求

在此应当概述软件将要执行的主要功能，这里的功能描述应该是根据用户对软件的期望，进行概略地总结，	而不应当涉及功能的大量细节。而为清晰起见：
1）对于功能的描述组织应当能让第1次看到此文档的用户或其他人员快速理解系统的功能需求。
2）可以适当地使用文本或图表显示不同功能及其相互之间的联系。

• 甲方
  • 查看项目进度
  • 提供需求反馈
• 开发者
  • 上传文档
  • 查看文档仓库
  • 下载文档
  • 查看历史信息
• 项目经理
  • 查看项目进度
  • 提供需求反馈
  • 文档权限管理
  • 创建项目仓库
• 管理员
  • 系统管理维护
  • 用户管理

1.2 非功能需求

在此应当给在功能之外的需求，一般应当包括但不限于：
1）性能需求
2）约束
3）质量属性
4）对外接口

2. 用例模型

在面向对象分析方法中，通常以“用例驱动”，在此部分应当在对来自用户的功能需求进行“分析”基础之上，建立起用例模型，对功能进行细化，建立起规格说明，一般表现为用例图及用例描述。

2.1 用例图

在此提供完整的系统用例图，所用图例应当遵从UML2.5.1/2017标准，从需求分析的角度应当从整体上确定并给出：
1）系统边界
2）参与者
3）用例
4）参与者与用例以及用例之间的关系
其中：
1）用例图应当给出标识号，如UC01，方便在后面的用例规格说明，也即用例描述中，加以引用。
2）所绘制的用例图应当使用工具软件绘制（Visio），在文档中居中显示，大小适中（一般地应当保持图中字体比正文小1号），并在图下方标注，形如：

图2-1 *******系统用例图

2.2 用例规格说明

对于用例图中的所有用例，应当给出相应的用例规格说明，一般地可以采用如下的用例描述模板。

2.2.1 UC01 ****用例

2.2.2 UC02 ****用例

3. 概念类分析

对于系统用例可进一步采用概念类图确定用例中所应有的数据及核心功能，也即以类图确定属性和方法，一般地在概念类分析中，我们主要关注的是类中的重要属性，在此基础上可以给出类与类之间的关联关系，也即概念类之间是如何协作的。

3.1 UC01 ****用例的概念类分析

3.1.1 候选类及筛选

对于概念类的分析，如果无从下手，可以从用例中的场景描述开始，建立起局部概念类图，其分析过程可以参照下表：

3.1.2 概念类图

在经过对用例场景中可能的备选类进行筛选后所形成的概念类，可以绘制概念类图。
1）概念类图中可以有参与者。
2）所绘制的概念类图应当使用工具软件绘制（Visio），在文档中居中显示，大小适中（一般地应当保持图中字体比正文小1号），并在图下方标注，形如：

图3-1 UC01****用例的概念类图

3.2 UC02 ****用例的概念类分析

3.2.1 候选类及筛选

……

3.1.2 概念类图

……

4. 交互行为分析

系统用例往往包含着对象的交互行为，可进一步建立起交互模型用于描述“用例的实现”，也即对象之间是如何通过协作完成系统功能任务的。
一般地在需求分析阶段，更多地使用系统顺序图，强调的是参与者和系统间的交互行为，重点展示系统级事件。
在此部分，应当在用例分析基础之上，给出系统顺序图。
所绘制的系统顺序图应当使用工具软件绘制（Visio），在文档中居中显示，大小适中（一般地应当保持图中字体比正文小1号），并在图下方标注，形如：

图4-1 *********系统顺序图

5. 附录