软件需求分析
- 1、 需求分析定义及获取
- 2、 需求分析过程
- 2.1 需求提炼
- 2.2 需求描述
- 2.3 需求验证
- 3、 需求分析任务
- 3.1 软件需求规格文档编制
- 沟通活动通用任务集
- 软件需求规格说明的原则
- 软件需求规格说明的结构
1、 需求分析定义及获取
需求分析:确定系统必须具有的功能和性能,系统要求的运行环境,并且预测系统发展的前景。需求就是以一种清晰、简洁、一致且无二义性的方式,对一个待开发系统中各个有意义方面的陈述的一个集合。
需求不准确将导致修正的代价呈指数级增长。
软件需求获取指的是软件需求的来源,软件工程师收集这些软件需求的方法。它也称为需求抓取、需求发现和需求获得。
- 软件需求分为功能需求、非功能需求和设计约束3个方面内容。
- 功能需求:描述系统应该做什么,即为用户和其他系统完成的功能、提供的服务。
- 非功能需求:必须遵守的标准,外部界面的细节,实现的约束条件,质量属性等。产品必须具备的属性和品质,如可靠性、性能、响应时间、容错性和扩展性等。
- 设计约束:限制条件、补充规约,这通常是对解决方案的一些约束说明。
- 需求来源:用户目标、领域知识、投资者、运行环境、组织环境5个方面。
- 需求获取技术:采访、设定情景、原型、会议、观察商业过程和工作流。
- 需求获取面临的挑战:
- 客户说不清需求;
- 需求易变性;
- 问题的复杂性和对问题空间理解的不完备性和不一致性。
- 经验
- 尽可能地分析清楚那些是稳定的需求,那些是易变的需求。以便再进行系统设计时,将软件的核心建筑在稳定的需求上,否则将会吃尽苦头;
- 在合同中一定要说清楚“做什么”和“不做什么”。
- 需求诱导原则
2、 需求分析过程
需求确认:需求获取 → \rightarrow →需求提炼 → \rightarrow →需求描述 → \rightarrow →需求验证
2.1 需求提炼
需求提炼:对应用问题及环境的理解和分析,为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化,最终形成下一步的需求规格说明书。
核心:建立分析模型。
需求提炼采用多种形式描述需求,通过建立需求的多种视图,揭示出一些更深的问题。
需求提炼还包括与客户的交流以澄清某些易混淆的问题,并明确那些需求更为重要,其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。
2.2 需求描述
软件系统的需求规格说明,是对待开发系统的行为的完整描述。它包含了功能性需求和非功能性需求。
需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
需求规格说明书的标志是为了使用户和软件开发者上方对该软件的初始规定有一个共同的理解,使之称为整个开发工作的基础。
2.3 需求验证
需求验证的重要性:如果在后续的开发或当系统投入使用时才发现需求文档中的错误,就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。假设需求阶段引入1个错误的需求,设计时对这个需求需要5-10条设计实现,1条设计需要5-10条程序,1条程序需要3~5种测试组合测试。
对需求文档需执行以下类型的检查:
1. 有效性检查:检查不同用户使用不同功能的有效性。
2. 一致性检查:在文档中,需求之间不应该冲突。
3. 完备性检查:需求文档应该包括所有用户想要的功能和约束。
4. 现实性检查:检查保证能利用现有技术实现需求。
-
需求验证技术
- 需求评审;
- 利用原型检验系统是否符合用户的真正需要;
- 对每个需求编写概念性的测试用例;
- 编写用户手册。用浅显易懂的语言描述用户可见的功能。
- 自动的一致性分析。可用CASE工具检验需求模型的一致性。
-
需求变更流程
3、 需求分析任务
- 建立分析模型:准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么;
- 编写需求说明:用《需求规格说明书》规范的形式准确地表达用户的需求。
3.1 软件需求规格文档编制
沟通活动通用任务集
- 识别主要客户和共利益者
- 与主要客户会谈“上下文无关的问题”,以确定:业务需要和商业价值;最终用户的特性和需要;需要的用户可见输出;业务约束。
- 写一页项目范围的说明
- 评审范围说明,并应客户要求做出相应修改
- 与客户/最终用户进行写作,确定:采用标准格式记录客户可见的使用场景;输入和输出;重要的软件特性、功能和行为;客户定义的商业风险
- 描述场景、输入/输出、特性/功能以及风险
- 与客户细化场景、输入/输出、特性/功能以及风险
- 为每个用户场景、特性、功能和行为分配客户定义的优先级
- 回顾搜集的所有信息并修订
- 为计划活动做准备
软件需求规格说明的原则
- 从现实中分离功能,即描述要“做什么”而不是“怎样实现”
- 要求使用面向处理的规格说明语言(或称系统定义语言)
- 如果被开发软件只是一个大系统中的一个元素,那么整个大系统也包括在规格说明的描述之中
- 规格说明必须包括系统运行环境
- 规格说明必须是一个认识模型
- 规格说明必须是可操作的
- 规格说明必须容许不完备性并允许扩充
- 规格说明必须局部化和松散耦合
软件需求规格说明的结构
IEEE标准为需求文档提出了以下结构,组织机构内部可以基于此标准扩展.
(1) 引言
(2) 综合描述
(3) 需求描述
(4) 附录(词汇表、分析模型、待定问题列表)
(5) 索引