在软件行业已经做了好几年了,由于公司风格的原因,缺少真实处理需求的人员,需求编写环节只是机械性的填写文档,没有经过严谨思考的,泥沙俱下的需求文档,常常让程序员无从下手,导致技术方向出问题。最近下决心好好梳理一遍。提升自身的专业化、职业化能力。
软件的作用
软件是现代系统中的重要元素,使这些产品/系统成为用户的解决方案
软件是容易修改的,但修改正确是很难的
《软件工程最佳实践 - 项目经理的指南》
- 需求分析
通过分析分配给软件的那些系统需求,确定软件需求及约束 - 软件体系结构设计
为软件需求及约束,确定一组解决方案,进行实例研究,分析可能的方案,并选择一个最佳的方案 - 产品评估
以需求为准则,通过测试、演示、分析及审查等方式,评估最终产品和文档。其中包括一些必要的软件系统集成活动
- 步骤
- 调查、确定一个系统需求规约中分配给软件的系统需求。
- 以及在一个软件需求规约中的软件需求的描述
- 自顶向下和自底向上
自定向下:从需求出发,给出需求规约,进行软件设计,测试,交付(瀑布模型)
自底向上:获取需求,筛选成熟的软件构建搭建系统,满足需求(搭建式)
需求的定义
- 定义
一个需求是一个有关“需要构造”的陈述,描述了待开发产品/系统(项)功能上的能力,性能参数或者其他性质
- 需求的基本性质
单一需求必须具有5个基本性质
- 必要的
- 无歧义的
- 可测的:可以对它进行测试吗
- 可跟踪的:可以对它从一个开发阶段到另一个开发阶段可进行跟踪吗?
- 可测量的
需求分类
- 功能需求(整个需求的主体)
功能需求规约了系统或系统构件必须执行的功能
还应注意如下规约:
输入验证,有序,异常响应,优先级,功能之间的互斥规则,系统内部状态,输入输出次序,计算所需的公式 - 性能需求
规约了一个系统或系统构建必须具有的性能特性
- 外部接口需求
规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它也可能规约其格式、时间或其他因素。
系统接口/用户接口/硬件接口/软件接口/通讯接口
内存约束(易失性存储和永久性)/操作/地点需求(运行环境) - 设计约束
限制了系统或系统构件的设计方案
- 质量约束
规约了软件产品必须具有的一个性质是否达到质量方面一个所期望的水平
可靠性/存活性(健壮性)/可维护性/用户友好性/安全性/可移植性
需求发现
自悟:作为用户,提出问题
交流:询问用户想要的功能(需要控制用户提出合理需求)
观察:观察用户执行现行的任务和过程或观察如何操作与期望系统有关的现有系统,了解运行环境(客户可能抵触这一观察)
小组会:举行客户和开发人员的联席会议,与客户代表共同开发需求
提炼:可复用的技术文档,提取出未来可能会用到的信息
综合运用:将上述的方法灵活运用
需求规约及其格式
- 需求规约(SRS)
一个需求规约是一个软件项目/产品/系统所有需求陈述的正式文档,是一个软件产品/系统的概念模型。 - 基本性质
- 重要性和稳定性程度
- 可修改的,在少量的影响其他需求的前提下,可以容易的修改一个单一需求
- 一致性,不存在互斥的需求
- 功能需求
功能源,功能共享的数据,功能与外部界面的交互,功能所使用的计算资源 - 需求规约格式(IEEE 830-1998)
1.引言
1.1目的
1.2范围
1.3定义,缩略语
1.4参考文献
1.5概述(项目范围)
2.总体描述
2.1产品描述
2.2产品功能
2.3用户特性
2.4约束
2.5假设和依赖
3.特定需求
附录
索引
特定需求:
- 模板1:根据系统运行模式,把第三部分划分为一些小节,并在一个小节中给出系统性能的约束
- 模板2:通过一种可选的模式划分,把第三部分划分为一些小节,其中每种模式的性能包含在该模式的规约中
- 模板3:根据用户类,把第三部分划分为一些小节,其中每类用户执行的功能包含在该类用户的描述中
- 模板4:按对象,把第三部分划分为一些小节,在每一小节中给出该对象所关联的功能
- 需求规约的作用
- 最重要的,作为软件开发组织和用户之间的一份事实上的技术合同书;是产品功能及其环境的体现。
- 对于项目的其余大多数工作,它是一个管理控制点
- 对于产品的设计,它是一个正式的、受控的起始点
- 是创建产品验收测试计划和用户指南的基础,即基于需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述
- 初始测试计划
对系统中的功能和性能指标进行测试,以达到目标要求 - 用户系统操作描述
从用户使用的角度来,简要描述系统功能和性能,使用系统的主要步骤和方法,以及系统用户的责任等
项目需求及需求规约
- 项目需求(SOW)
项目需求是客户和开发者之间有关技术合同-产品/系统需求的理解,应记录在工作陈述SOW中或其他某一项目文档(例如:项目管理计划)中
SRS应只关注产品需求——交付的产品是什么
SOW应关注项目工作与管理——开发组要做什么