第二章需求分析
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
的要求，以及对操作系统、数据库和浏览器等软件配置的要求。
在界面方面 • 需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示
器的分辨率要求等问题。
需求分析的步骤
1.获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别
目标系统要解决哪些问题，要满足哪些限制条件，这个过程 就是对需求的获取。
需求说明书的编写提示
4 运行环境规定 4.1 设备 列出运行该软件所需要的硬设备。说明其中的新型设备及其
专门功能，包括： a．处理器型号及内存容量； b．外存容量、输入及输出设备的型号和数量，联机或脱机； d．数据通信设备的型号和数量； e．其他专用硬件 4.2 支持软件 包括要用到的操作系统、编译（或汇编）程序、测试支持软
需求分析的目的与意义
有效的需求分析通常都具有一定的难度，一方面是因为交 流存在障碍，另一方面是因为用户通常对需求的陈述不完 备、不准确和不全面，并且还可能不断地变化。 开发人员不仅需要在用户的帮助下抽象现有的需求，还 需要挖掘隐藏的需求。 此外，把各项需求抽象为目标系统的高层逻辑模型对日后 的开发工作也至关重要。 合理的高层逻辑模型是系统设计的前提。
需求获取面临的问题
无足够用户参与 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类
需求分析的步骤
2. 分析需求，建立目标系统的逻辑模型 常用的模型图有数据流图、E-R图、用例图和状态转换图等，
不同的模型从不同的角度或不同的侧重点描述目标系统。绘 制模型图的过程，既是开发人员进行逻辑思考的过程，也是 开发人员更进一步认识目标系统的过程。
面向对象需求分析方法
目标系统类可以划分为边界类、控制类和实体类
边界类 • 代表了系统及其操作者的边界，描述操作者与系统之间的交
互。它更加关注系统的职责，而不是实现职责的具体细节。 通常，界面控制类、系统和设备接口类都属于边界类。
控制类 • 代表了系统的逻辑控制，描述一个用例所具有的事件流的控
制行为，实现对用例行为的封装。通常，可以为每个用例定 义一个控制类。
需求说明书的编写提示
2 任务概述 2.1 目标
叙述该项软件开发的意图、应用目标、作用范围以及 其他应向读者说明的有关该软件开发的背景材料。如果所 定义的产品是一个更大的系统的一个组成部分，可使用一 张方框图来说明该系统的组成和本产品同其他各部分的联 系和接口。| 2.2 用户的特点
列出本软件的最终用户的特点，充分说明操作人员、 维护人员的教育水平和技术专长，以及本软件的预期使用 频度。这些是软件设计工作的重要约束 。 2.3 假定和约束
需求说明书的编写提示
b． 更新处理时间； c． 数据的转换和传送时间； 3.2.3 灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对
这些变化的适应能力，如： a． 操作方式上的变化； b． 运行环境的变化； c． 同其他软件的接口的变化； d． 精度的变化； 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。 3.3 输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精
需求分析的目的与意义
在进行需求分析的过程中，首先要明确需求分析 应该是一个迭代的过程。 由于市场环境的易变性以及用户本身对于需求描 述的模糊性，需求往往很难做到一步到位。 需求分析不仅仅是属于软件开发生命周期早期的 一项工作，而且还应该贯穿于整个生命周期中， 它应该随着项目的深入而不断地变化。
需求分析的步骤
在需求验证的过程中，可以对需求阶段的输出文 档进行多种检查，比如，一致性检查、完整性检查 和有效性检查等。同时，需求评审也是在这个阶段 进行的。
面向对象 需求分析方法
面向对象需求分析方法
面向对象的需求分析基于面向对象的思想，以用 例模型为基础。 开发人员在获取需求的基础上，建立目标系统的 用例模型。 所谓用例是指系统中的一个功能单元，可以描述 为操作者与系统之间的一次交互。用例常被用来 收集用户的需求。
面向对象需求分析方法
最后，需要将需求分析的结果用多种模型图表示出来，并 对其进行评审。由于分析的过程是一个循序渐进的过程， 合理的分析模型需要多次迭代才能得到。 面向对象需求分析的示意图如图所示。
UML简介
类图和对象图 用例图 顺序图 状态图 活动图 通信图
交互概况图 时序图 组件图 部署图 包图
有哪些？
6 您认为提高工作效率，节省工作时间，减轻工作强度 可采取哪些办法？
某出版社系统调查表
编号
提出问题
7 您的部门需要成本核算和统计的内容有哪些？
8 您的部门采用计算机管理工作情况如何？ 9 如何改进业务流程使之更合理？ 10 哪些问题是目前传统手工方法根本无法解决的？
11 出版社计算机管理信息系统需要解决什么问题？
UML简介
UML 2.0支持13种图，有6种结构图和7种行为图。
结构图 （静态模型图）
类图
组织结构图
组件图
部署图
对象图
包图
行为图 （动态模型图）
活动图 交互图 用例图
状态机图
顺序图 通信图
交互概况图
时序图
ห้องสมุดไป่ตู้
类图
类图使用类和对象描述系统的结构，展示了系统 中类的静态结构，即类与类之间的相互关系。 类之间有多种联系方式，如关联（相互连接）、 依赖（一个类依赖于或使用另一个类）、泛化 （一个类是另一个类的特殊情况）。 一个系统有多幅类图，一个类也可以出现在几幅 类图中。
面向对象需求分析方法
首先要找到系统的使用者，即用例的操作者。操 作者是在系统之外，透过系统边界与系统进行有 意义交互的任何事物。 “在系统之外”是指操作者本身并不是系统的组 成部分，而是与系统进行交互的外界事物。这种 交互应该是“有意义”的交互，即操作者向系统 发出请求后，系统要给出相应的回应。 而且，操作者并不限于人，也可以是时间、温度 和其他系统等。
第三章 需求分析
需求分析的目的与意义 需求分析的步骤
需求分析的目的与意义
需求分析是一个非常重要的过程，它完成的好坏 直接影响后续软件开发的质量。 一般情况下，用户并不熟悉计算机的相关知识， 而软件开发人员对相关的业务领域也不甚了解， 用户与开发人员之间对同一问题理解的差异和习 惯用语的不同往往会为需求分析带来很大的困难。 因此，开发人员和用户之间充分和有效的沟通在 需求分析的过程中至关重要。
实体类 • 描述了系统中必须存储的信息及相关的行为，通常对应于现
实世界中的事物。
面向对象需求分析方法
确定系统的类和对象后，分析类之间的关系
对象或类之间的关系
依赖关系
• “非结构化”的和短暂的关系，表明某个对象会影响另外一个对象的 行为或服务
关联关系
• “结构化”的关系，描述对象之间的连接。
聚合关系和组合关系
度等。
需求说明书的编写提示
3.4 数据管理能力要求 说明需要管理的文件和记录的个数、表和文件的大小
规模，要按可预见的增长对数据及其分量的存储要求作 出估算。 3.5 故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产 生的后果和对故障处理的要求。 3.6 其他专门要求
如用户单位对安全保密的要求，对使用方便的要求， 对可维护性、可补充性、易读性、可靠性、运行环境可 转换性的特殊要求等。
件等。
需求说明书的编写提示
4.3 接口 说明该软件同其他软件之间的接口、数据通信协议等。 4.4 控制 说明控制该软件的运行的方法和控制信号，并说明这些控
制信号的来源。
需求分析的步骤
4. 需求验证 需求验证是对需求分析的成果进行评估和验证的
过程。为了确保需求分析的现实性、一致性、完整 性和有效性，提高软件开发的效率，为后续的软件 开发做好准备，需求验证的工作非常必要。
UML简介
UML（Unified Modeling Language），即统一建模 语言，是一种标准的图形化建模语言。它主要用 于软件的分析与设计，用定义完善的符号来图形 化地展现一个软件系统。 UML的使用可以贯穿于软件开发周期的每一个阶 段，适用于数据建模、业务建模、对象建模和组 件建模。 作为一种建模语言，UML并不涉及编程的问题， 即与语言平台无关，这就使开发人员可以专注于 建立软件系统的模型和结构。
需求分析的步骤
3. 将需求文档化
获得需求后要将其描述出来，即将需求文档化。对于大型的 软件系统，需求阶段一般会输出三个文档：
系统定义文档 • 用户需求报告 系统需求文档 • 系统需求规格说明书 软件需求文档 • 软件需求规格说明书
需求分析的步骤
对于简单的软件系统而言，需求阶段只需要输出 软件需求文档就可以了。 软件需求规格说明书主要描述软件的需求，从开 发人员的角度对目标系统的业务模型、功能模型 和数据模型等内容进行描述。 作为后续的软件设计和测试的重要依据，需求阶 段的输出文档应该具有清晰性、无二义性和准确 性，并且能够全面和确切地描述用户需求。
开发人员通过调查研究，要理解当前系统的工作模型和此 外，在需求的获取时，还要明确用户对系统的安全性、可移 植性和容错能力等其他要求。
需求分析的步骤
需求获取方法 问卷调查 访谈 实地操作 建立原型 研究资料
某出版社系统调查表
编号
提出问题
1 您在哪个部门工作？ 2 出版业务流程是什么？ 3 您每日都处理那些文件、数据、报表？ 4 工作中手工处理特别麻烦的事情是什么？ 5 工作中手工处理什么问题解决不了？影响效率的问题
• 特殊的关联关系，它们强调整体和部分之间的从属性，组合是聚合的 一种形式，组合关系对应的整体和部分具有很强的归属关系和一致的 生存期。比如，计算机和显示器就属于聚合关系。
泛化关系
• 与类间的继承类似。
实现关系
• 针对类与接口的关系。
面向对象需求分析方法
明确了对象、类和类之间的层次关系之后，需要 进一步识别出对象之间的动态交互行为，即系统 响应外部事件或操作的工作过程。 一般采用顺序图将用例和分析的对象联系在一起， 描述用例的行为是如何在对象之间分布的。
需求分析的步骤
需求涉及的方面
在功能方面 • 需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，
目标用户有哪些，以及不同用户需要通过系统完成何种操作等。
在性能方面 • 需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标
的要求。
在运行环境方面 • 需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境
面向对象需求分析方法
下图所示为某图书馆信息管理系统的用例图。
面向对象需求分析方法
确定了系统的所有用例之后，就可以开始识别目 标系统中的对象和类了。 把具有相似属性和操作的对象定义为一个类。 属性定义对象的静态特征，一个对象往往包含很 多属性。
面向对象需求分析方法
比如，读者的属性可能有姓名、年龄、年级、性 别、学号、身份证号、籍贯、民族和血型等。目 标系统不可能关注对象的所有属性，而只是考虑 与业务相关的属性。 比如，在“图书馆信息管理”系统中，可能就不 会考虑读者的民族和血型等属性。操作定义了对 象的行为，并以某种方式修改对象的属性值。
需求说明书的编写提示
3 需求规定 3.1 对功能的规定
用列表的方式（例如IPO表），逐项叙述对软件所 提出的功能要求。 3.2 对性能的规定 3.2.1 精度 说明对该软件的输入、输出数据精度的要求，可能包括 传输过程中的精度。 3.2.2 时间特性要求 说明对于该软件的时间特性要求，如对： a． 响应时间；
面向对象需求分析方法
比如，目标系统需要每隔一段时间就进行一次系统更新， 那么时间就是操作者。 可以把操作者执行的每一个系统功能都看作一个用例。可 以说，用例描述了系统的功能，涉及系统为了实现一个功 能目标而关联的操作者、对象和行为。 识别用例时，要注意用例是由系统执行的，并且用例的结 果是操作者可以观测到的。用例是站在用户的角度对系统 进行的描述，所以描述用例要尽量使用业务语言而不是技 术语言。
需求说明书的编写提示
1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1.2 背景 说明：a． 待开发的软件系统的名称；
b． 本项目的任务提出者、开发者、用户； c．该软件系统同其他系统或其他机构的关系。 1.3 定义 列出本文件中用到的专门术语的定义。 1.4 参考资料
在界面方面 • 需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示
器的分辨率要求等问题。
需求分析的步骤
1.获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别
目标系统要解决哪些问题，要满足哪些限制条件，这个过程 就是对需求的获取。
需求说明书的编写提示
4 运行环境规定 4.1 设备 列出运行该软件所需要的硬设备。说明其中的新型设备及其
专门功能，包括： a．处理器型号及内存容量； b．外存容量、输入及输出设备的型号和数量，联机或脱机； d．数据通信设备的型号和数量； e．其他专用硬件 4.2 支持软件 包括要用到的操作系统、编译（或汇编）程序、测试支持软
需求分析的目的与意义
有效的需求分析通常都具有一定的难度，一方面是因为交 流存在障碍，另一方面是因为用户通常对需求的陈述不完 备、不准确和不全面，并且还可能不断地变化。 开发人员不仅需要在用户的帮助下抽象现有的需求，还 需要挖掘隐藏的需求。 此外，把各项需求抽象为目标系统的高层逻辑模型对日后 的开发工作也至关重要。 合理的高层逻辑模型是系统设计的前提。
需求获取面临的问题
无足够用户参与 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类
需求分析的步骤
2. 分析需求，建立目标系统的逻辑模型 常用的模型图有数据流图、E-R图、用例图和状态转换图等，
不同的模型从不同的角度或不同的侧重点描述目标系统。绘 制模型图的过程，既是开发人员进行逻辑思考的过程，也是 开发人员更进一步认识目标系统的过程。
面向对象需求分析方法
目标系统类可以划分为边界类、控制类和实体类
边界类 • 代表了系统及其操作者的边界，描述操作者与系统之间的交
互。它更加关注系统的职责，而不是实现职责的具体细节。 通常，界面控制类、系统和设备接口类都属于边界类。
控制类 • 代表了系统的逻辑控制，描述一个用例所具有的事件流的控
制行为，实现对用例行为的封装。通常，可以为每个用例定 义一个控制类。
需求说明书的编写提示
2 任务概述 2.1 目标
叙述该项软件开发的意图、应用目标、作用范围以及 其他应向读者说明的有关该软件开发的背景材料。如果所 定义的产品是一个更大的系统的一个组成部分，可使用一 张方框图来说明该系统的组成和本产品同其他各部分的联 系和接口。| 2.2 用户的特点
列出本软件的最终用户的特点，充分说明操作人员、 维护人员的教育水平和技术专长，以及本软件的预期使用 频度。这些是软件设计工作的重要约束 。 2.3 假定和约束
需求说明书的编写提示
b． 更新处理时间； c． 数据的转换和传送时间； 3.2.3 灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对
这些变化的适应能力，如： a． 操作方式上的变化； b． 运行环境的变化； c． 同其他软件的接口的变化； d． 精度的变化； 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。 3.3 输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精
需求分析的目的与意义
在进行需求分析的过程中，首先要明确需求分析 应该是一个迭代的过程。 由于市场环境的易变性以及用户本身对于需求描 述的模糊性，需求往往很难做到一步到位。 需求分析不仅仅是属于软件开发生命周期早期的 一项工作，而且还应该贯穿于整个生命周期中， 它应该随着项目的深入而不断地变化。
需求分析的步骤
在需求验证的过程中，可以对需求阶段的输出文 档进行多种检查，比如，一致性检查、完整性检查 和有效性检查等。同时，需求评审也是在这个阶段 进行的。
面向对象 需求分析方法
面向对象需求分析方法
面向对象的需求分析基于面向对象的思想，以用 例模型为基础。 开发人员在获取需求的基础上，建立目标系统的 用例模型。 所谓用例是指系统中的一个功能单元，可以描述 为操作者与系统之间的一次交互。用例常被用来 收集用户的需求。
面向对象需求分析方法
最后，需要将需求分析的结果用多种模型图表示出来，并 对其进行评审。由于分析的过程是一个循序渐进的过程， 合理的分析模型需要多次迭代才能得到。 面向对象需求分析的示意图如图所示。
UML简介
类图和对象图 用例图 顺序图 状态图 活动图 通信图
交互概况图 时序图 组件图 部署图 包图
有哪些？
6 您认为提高工作效率，节省工作时间，减轻工作强度 可采取哪些办法？
某出版社系统调查表
编号
提出问题
7 您的部门需要成本核算和统计的内容有哪些？
8 您的部门采用计算机管理工作情况如何？ 9 如何改进业务流程使之更合理？ 10 哪些问题是目前传统手工方法根本无法解决的？
11 出版社计算机管理信息系统需要解决什么问题？
UML简介
UML 2.0支持13种图，有6种结构图和7种行为图。
结构图 （静态模型图）
类图
组织结构图
组件图
部署图
对象图
包图
行为图 （动态模型图）
活动图 交互图 用例图
状态机图
顺序图 通信图
交互概况图
时序图
ห้องสมุดไป่ตู้
类图
类图使用类和对象描述系统的结构，展示了系统 中类的静态结构，即类与类之间的相互关系。 类之间有多种联系方式，如关联（相互连接）、 依赖（一个类依赖于或使用另一个类）、泛化 （一个类是另一个类的特殊情况）。 一个系统有多幅类图，一个类也可以出现在几幅 类图中。
面向对象需求分析方法
首先要找到系统的使用者，即用例的操作者。操 作者是在系统之外，透过系统边界与系统进行有 意义交互的任何事物。 “在系统之外”是指操作者本身并不是系统的组 成部分，而是与系统进行交互的外界事物。这种 交互应该是“有意义”的交互，即操作者向系统 发出请求后，系统要给出相应的回应。 而且，操作者并不限于人，也可以是时间、温度 和其他系统等。
第三章 需求分析
需求分析的目的与意义 需求分析的步骤
需求分析的目的与意义
需求分析是一个非常重要的过程，它完成的好坏 直接影响后续软件开发的质量。 一般情况下，用户并不熟悉计算机的相关知识， 而软件开发人员对相关的业务领域也不甚了解， 用户与开发人员之间对同一问题理解的差异和习 惯用语的不同往往会为需求分析带来很大的困难。 因此，开发人员和用户之间充分和有效的沟通在 需求分析的过程中至关重要。
实体类 • 描述了系统中必须存储的信息及相关的行为，通常对应于现
实世界中的事物。
面向对象需求分析方法
确定系统的类和对象后，分析类之间的关系
对象或类之间的关系
依赖关系
• “非结构化”的和短暂的关系，表明某个对象会影响另外一个对象的 行为或服务
关联关系
• “结构化”的关系，描述对象之间的连接。
聚合关系和组合关系
度等。
需求说明书的编写提示
3.4 数据管理能力要求 说明需要管理的文件和记录的个数、表和文件的大小
规模，要按可预见的增长对数据及其分量的存储要求作 出估算。 3.5 故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产 生的后果和对故障处理的要求。 3.6 其他专门要求
如用户单位对安全保密的要求，对使用方便的要求， 对可维护性、可补充性、易读性、可靠性、运行环境可 转换性的特殊要求等。
件等。
需求说明书的编写提示
4.3 接口 说明该软件同其他软件之间的接口、数据通信协议等。 4.4 控制 说明控制该软件的运行的方法和控制信号，并说明这些控
制信号的来源。
需求分析的步骤
4. 需求验证 需求验证是对需求分析的成果进行评估和验证的
过程。为了确保需求分析的现实性、一致性、完整 性和有效性，提高软件开发的效率，为后续的软件 开发做好准备，需求验证的工作非常必要。
UML简介
UML（Unified Modeling Language），即统一建模 语言，是一种标准的图形化建模语言。它主要用 于软件的分析与设计，用定义完善的符号来图形 化地展现一个软件系统。 UML的使用可以贯穿于软件开发周期的每一个阶 段，适用于数据建模、业务建模、对象建模和组 件建模。 作为一种建模语言，UML并不涉及编程的问题， 即与语言平台无关，这就使开发人员可以专注于 建立软件系统的模型和结构。
需求分析的步骤
3. 将需求文档化
获得需求后要将其描述出来，即将需求文档化。对于大型的 软件系统，需求阶段一般会输出三个文档：
系统定义文档 • 用户需求报告 系统需求文档 • 系统需求规格说明书 软件需求文档 • 软件需求规格说明书
需求分析的步骤
对于简单的软件系统而言，需求阶段只需要输出 软件需求文档就可以了。 软件需求规格说明书主要描述软件的需求，从开 发人员的角度对目标系统的业务模型、功能模型 和数据模型等内容进行描述。 作为后续的软件设计和测试的重要依据，需求阶 段的输出文档应该具有清晰性、无二义性和准确 性，并且能够全面和确切地描述用户需求。
开发人员通过调查研究，要理解当前系统的工作模型和此 外，在需求的获取时，还要明确用户对系统的安全性、可移 植性和容错能力等其他要求。
需求分析的步骤
需求获取方法 问卷调查 访谈 实地操作 建立原型 研究资料
某出版社系统调查表
编号
提出问题
1 您在哪个部门工作？ 2 出版业务流程是什么？ 3 您每日都处理那些文件、数据、报表？ 4 工作中手工处理特别麻烦的事情是什么？ 5 工作中手工处理什么问题解决不了？影响效率的问题
• 特殊的关联关系，它们强调整体和部分之间的从属性，组合是聚合的 一种形式，组合关系对应的整体和部分具有很强的归属关系和一致的 生存期。比如，计算机和显示器就属于聚合关系。
泛化关系
• 与类间的继承类似。
实现关系
• 针对类与接口的关系。
面向对象需求分析方法
明确了对象、类和类之间的层次关系之后，需要 进一步识别出对象之间的动态交互行为，即系统 响应外部事件或操作的工作过程。 一般采用顺序图将用例和分析的对象联系在一起， 描述用例的行为是如何在对象之间分布的。
需求分析的步骤
需求涉及的方面
在功能方面 • 需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，
目标用户有哪些，以及不同用户需要通过系统完成何种操作等。
在性能方面 • 需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标
的要求。
在运行环境方面 • 需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境
面向对象需求分析方法
下图所示为某图书馆信息管理系统的用例图。
面向对象需求分析方法
确定了系统的所有用例之后，就可以开始识别目 标系统中的对象和类了。 把具有相似属性和操作的对象定义为一个类。 属性定义对象的静态特征，一个对象往往包含很 多属性。
面向对象需求分析方法
比如，读者的属性可能有姓名、年龄、年级、性 别、学号、身份证号、籍贯、民族和血型等。目 标系统不可能关注对象的所有属性，而只是考虑 与业务相关的属性。 比如，在“图书馆信息管理”系统中，可能就不 会考虑读者的民族和血型等属性。操作定义了对 象的行为，并以某种方式修改对象的属性值。
需求说明书的编写提示
3 需求规定 3.1 对功能的规定
用列表的方式（例如IPO表），逐项叙述对软件所 提出的功能要求。 3.2 对性能的规定 3.2.1 精度 说明对该软件的输入、输出数据精度的要求，可能包括 传输过程中的精度。 3.2.2 时间特性要求 说明对于该软件的时间特性要求，如对： a． 响应时间；
面向对象需求分析方法
比如，目标系统需要每隔一段时间就进行一次系统更新， 那么时间就是操作者。 可以把操作者执行的每一个系统功能都看作一个用例。可 以说，用例描述了系统的功能，涉及系统为了实现一个功 能目标而关联的操作者、对象和行为。 识别用例时，要注意用例是由系统执行的，并且用例的结 果是操作者可以观测到的。用例是站在用户的角度对系统 进行的描述，所以描述用例要尽量使用业务语言而不是技 术语言。
需求说明书的编写提示
1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1.2 背景 说明：a． 待开发的软件系统的名称；
b． 本项目的任务提出者、开发者、用户； c．该软件系统同其他系统或其他机构的关系。 1.3 定义 列出本文件中用到的专门术语的定义。 1.4 参考资料