3.1 需求的作用
3.1.1 在现代系统中的作用
三个作用:
- 为产品提供控制功能。
- 为产品提供耦合功能,可集成其他功能。
- 为产品提供一些由本身所实现的功能,利用自身提供服务。
特别的:
- 为解决系统集成遇到的问题提供了灵活性。
- 为软硬件接口中所出现的问题提供了低成本解决途径。
- 软件易修改,但修改成功很困难。
- 现代技术产品中最重要的技术是软件技术,即软甲是现代系统中的重要因素,是任何系统中最复杂的部分且最大的挑战,它使得产品/系统成为用户的解决方案。
3.1.2 在系统工程中的作用
三个作用:
- 需求分析环节:通过分析系统需求确定软件需求及约束。
- 软件体系结构设计环节:以软件需求及约束为基础,确定一个最佳的方案。
- 验证、确认及测试环节:以需求为准则进行产品评估。
可见:
- 软件在此时作为系统工程工作的一部分被实施。
- 在软件开发活动中首先要做的是调查确定在一个系统需求规约中的分配给软件的那些系统需求和在一个软件需求规约(SRS)中的软件需求
总结:
- 软件需求是软件开发的工作基础。
3.2 需求的定义
3.2.1 定义
概念:一个需求是一个有关“要予构造”的陈述,描述了待开发产品/系统(或项)功能上的能力、性能参数或者其他性质。
3.2.2 基本性质
需求的五个基本性质:
- 必要的:是要求的吗?
- 无歧义的:只能用一种方式解释吗?
- 可测的:可以对它进行测试吗?
- 可跟踪的:可以在不同阶段进行跟踪吗?
- 可测量的:可以对它进行测量吗?
3.3 需求的分类
分类:

- 功能需求是整个需求的主体,即没有功能需求就没有非功能需求。
- 设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。
3.4 需求发现
需求发现的方式:
- 自悟:需求人员把自己作为系统的最终用户审视该系统并提出问题。
- 交谈:为了确定系统应该提供的功能,需求人员向用户提问。
- 观察:通过观察用户了解系统运行环境。
- 小组会:举行客户和开发人员的联席会议,与客户组织的一些代表共同开发需求。
- 提炼:复审技术文档并提出相关的信息。
- 综合运用:所有方法互相结合,取长补短。
3.5 需求规约的概念和格式
3.5.1 需求规约(SRS)及其格式
概念:
- 需求规约是软件项所有需求陈述的正式文档,是一个软件产品的概念模型。
四个基本性质:
- 重要性和稳定性程度。
- 可实现单一需求的修改。
- 完整的没有遗漏的。
- 一致的不存在互斥的。
格式举例:
第一部分:

第二部分:

第三部分(特定需求,是文档的技术核心):
- 模板一:根据系统运行模式,把第三部分划分为一些小节,并在一个小节中给出系统性能的规约。
- 模板二:通过一种可选的模式划分,把第三部分划分为一些小节,其中每种模式的性能包含在该模式的规约中。
- 模板三:根据用户类,把第三部分划分为一些小节,其中每类用户执行的功能包含在该类用户的描述中。
- 模板四:按对象,把第三部分划分为一些小节,在每一小节中给出该对象所关联的功能。
3.6 需求规约的作用
概念:
- 是最重要的,作为软件开发组织和用户之间一份事实上的技术合同书。
- 是一个管理控制点。
- 是一个正式的、受控的起始点。
- 是创建产品验收测试计划和用户指南的基础。
创建产品验收测试计划:
测试类型 | 所处阶段 |
---|---|
有效性测试 | 需求分析阶段 |
集成测试 | 总体设计阶段 |
单元测试 | 详细设计阶段 |
- 目的:对未来系统中的哪些功能和性能指标进行测试,以达到何种要求。
- 作用:指导系统开发早期发现并修改一个错误,减少测试代价,并在以后阶段的软件开发中,对这个测试计划不断的修正和完善使之成为相应文档的一部分。
创建用户指南:
- 目的:从用户使用系统的角度简要描述系统功能和性能,使用系统的主要步骤和方法,以及系统用户的责任等。
- 作用:准备初步的用户手册可以使未来的系统用户能够从使用的角度检查、审核以判断是否符合用户需要,并迫使系统分析员从用户角度考虑,发现需求的不一致和误解的地方。
SRS不能实现的作用:
- 它不是设计文档,是一个“为了”设计的文档。
- 不是进度或规划文档,所以不应包含项目成本、交付进度、报告规程、软件开发方法、质量保证规程、配置管理规程、验证和确认规程、验收规程、安装规程等。
3.7 项目的需求及需求规约
- 概念:项目需求是客户和开发者之间有关技术合同-产品/系统需求的理解,应记录在工作陈述SOW中或其他某一项目文档(如项目管理计划)中。
区别:
- SRS只关注产品需求,即“交付给客户的产品是什么”。
- SOW应关注项目工作与管理,即“开发组要做的是什么”。
(完)