3.1需求分析的任务
3.1.1确定对系统的综合要求
1.功能需求
- 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。
2.性能需求
- 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3.可靠性和可用性需求
- 可靠性：某个时间段内无差错运行的概率，定量地指定系统的可靠性。
- 可用性：用途的满意度，量化了用户可以使用系统的程度。
4.出错处理需求
- 这类需求说明系统对环境错误应该怎样响应
5.接口需求
- 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求硬件接口需求；软件接口需求；通信接口需求。
6.约束
- 设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
7.逆向需求
- 仅取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8.将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。
3.1.2分析系统的数据要求
任何一个软件系统本质上都是信息处理系统。
-
3.1.3导出系统的逻辑模型
数据流图
- 实体-联系图
- 状态转换图
-
3.1.4修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
3.2与用户沟通获取需求的方法
3.2.1访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术
正式访谈
- 系统分析员将提出一些事先准备好的具体问题
- 非正式访谈
- 分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法
情景分析技术
所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析
结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
3.2.3简易的应用規格说明技术
1.进行初步的访谈
2.开发者和用户分别写出“产品需求”
3.开会讨论，各自展示需求列表
4.得出了意见一致，为需求列表制定小型规格说明
5.根据会议结果，起草完整的软件需求规格说明
3.2.4快速建立软件原型
为了快速地构建和修改原型，通常使用下述3种方法和工具。
数据模型：(E-R图)实体-联系图
- 功能模型：数据流图
-
3.3.2软件需求规格说明
软件需求规格说明是需求分析阶段得出的最主要的文档。
通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求求以及将来可能提出的要求。
3.4实体-联系图
数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。
3.4.1数据对象
-
3.4.2属性
-
3.4.3联系
客观世界中的事物彼此间往往是有联系的。
- 一对一联系（1:1）
- 一对多联系（1：N）
多对多联系（M:N）
某校教学管理E－R图<br />
3.5数据规范化
软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范
3.6状态转换图
状态转换图（简称为状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作。
3.6.1状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式
- 定义的状态
- 初态（即初始状态）
- 终态（即最终状态）
- 中间状态
- 在一张状态图中只能有一个初态，而终态则可以有0至多个。
- 状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。
3.6.2事件
事件是在某个定时刻发生的事，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。事件就是引起系统做动作或（和转换状态的控制信息。）
3.6.3符号
状态图中使用的主要符号
- 状态的名称，必须有；状态变量的名字和值，可选；活动表，可选。
- 活动表
- entry事件指定进入该状态的动作
- exit事件指定退出该状态的动作
- do事件则指定在该状态下的动作
- 状态转换
3.7其他图形工具
3.7.1层次方框图
3.7.2 Warnier图
和层次方框图类似, Warnier图也用树形结构描绘信息, 但是这种图形工具比层次方框图提供了更丰富的描绘手段。
3.7.3 IPO图
IPO图是输入、处理、输出图的简称。
- 改进的IPO图
3.8验证软件需求
3.8.1从哪些方面验证软件需求的正确性
若有收获，就点个赞吧
0 人点赞
