软件需求任务
功能需求
接口需求
性能需求
约束
可靠性和可用性需求
逆向需求
出错处理需求
将来可能提出的要求
功能需求(一定要有)
这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能
性能需求(最好有)
性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
可靠性和可用性需求
可靠性需求定量地指定系统的可靠性,可用性与可靠性密切相关,它量化了用户可以使用系统的程度。
出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如,如果它接收到从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。
接口需求
接口需求描述应用系统与它的环境通信的格式。常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。
约束
设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。
逆向需求
逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求,人们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。这样做的目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一旦确实需要时能比较容易地进行这种扩充和修改。
软件需求分析概述
需求分析的过程
需求开发的工作有以下四个方面:
需求获取
分析建模
编写需求规格说明书
需求验证
编写需求规格说明书
编与需求规格说明
(1)需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准以及用户在性能、质量、可维护性等方面的要求。
(2)用户手册包括用户界面描述以及有关目标系统使用方法的初步构想。
(3)在需求分析中确立测试标准,作为系统开发目标是否完成的验收依据。
(4)修改的项目开发计划是根据新的分析结果,对可行性分析和软件计划阶段中制订的初步的项目开发计划作必要的修改,补充和完善。
IEEE目录结构
IEEE标准为需求文档提出了以下结构,组织机构内部可以基于此标准扩展:
(1)引言
a需求文档的目的b.文档约定
c.预期的读者和阅读建议d.产品范围
e.参考文献(2)综合描述
a产品前景
b.产品功能与优先级c.用户特征
d.运行环境
c.设计与实现上的限制f.假设和依赖性
(3)需求描述
a功能需求
b.数据需求:与功能有关的数据定义和数据关系c.性能需求:响应时间、容量要求、用户数等
d.外部接口:用户界面、软硬件接口、通信接口
c.设计约束:软件支持环境、报表、数据命名等
f.软件质量属性(可维护性、可靠性、可移植性、可用性、安全性等等)
g其他需求
这一节是文档中最实质性的部分,由于在机构组织的实践中存在极大的变数,对这一节定义的标准结构可以进行增删。
(4)附录(词汇表、分析模型、待定问题列表)(5)索引
需求规格说明书
内容 | 时间 | 成员 | 版本 |
创建 | 2021/9/19 | 小华 | 1.0 |
一.引言
1.1编写目的
1.2定义
1.3约束
1.4参考文献
1.5预期读者和建议
1.6产品描述二.功能需求
2.1登录
功能描述:校验用户的合法性
输入:用户名,密码,验证码
输出:成功登录主界面;失败提示失败原因
约束:密码6位字母数字,非空
2.2注册
...三.性能需求
响应时间:
容载量:
四.数据流程
获取需求的方法
需求分析至今仍是公认为的软件开发中最为困难、亟待解决的一个问题。
1、存在问题
⑴)对需求的理解问题。
(2)分析人员与用户的通信问题。
(3)用户需求的可变性问题。
(4)分析方法和分析工具问题。
3、常用方法
(1)访谈:正式的和非正式的访谈
(2)问卷调查
问卷调查即把需要调查的内容制成表格交给用户填写。该方法对需要调查大量人员的意见时,十分有效。
(3)情景分析
情景分析就是对目标系统解决某个具体问题的方法和结果给出可能的情景描述,以获知用户的具体需求。
(4)快速原型
为了快速地构建和修改原型,通常使用下述3种方法和工具。
第四代技术
可重用的软件构件
形式化规格说明和原型环境
分析建模
工具
数据流图
数据字典
实体-联系图
状态图
数据流图
概念
数据流图(DFD)是一种图形化技术,它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
符号
数据流四中基本符号
正方形表示数据的源点或终点
圆角矩形代表变换数据的处理
箭头表示数据流,即特定数据的流动方向
开口矩形代表数据存储