软件需求分析【百科全说】

本文主要介绍需求分析。

有关需求的基本概念

01

需求的基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
02

需求的重要性开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
03

需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。

软件需求分析的任务

01

需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
02

通常软件开发项目是要实现目标系统的物理模型目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的

需求分析的步骤

01

调查研究从系统的角度来理解软件并评审软件范围是否恰当；确定对目标系统的综合要求，即软件的需求；提出这些需求实现条件，以及需求应达到的标准。
02

分析与综合从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
03

书写文档系统规格说明书；数据要求说明书；用户系统描述；修正的开发计划。
04

开发原型系统采取建立原型系统的策略的主要理由如下：人类认识能力有限，不能预先指定所有要求；在用户和系统分析员之间存在固有的通信鸿沟；用户需要一个现实的系统模型以便获得实践经验；在开发过程中重复和反复使必要的和不可避免的。

软件需求规格说明的原则

01

从现实中分离功能，即描述要“做什么”而不是“怎样实现” ；要求使用面向处理的规格说明语言（或称系统定义语言）；如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；规格说明必须包括系统运行环境；规格说明必须是一个认识模型；规格说明必须是可操作的；规格说明必须容许不完备性并允许扩充；规格说明必须局部化和松散耦合。

需求分析的方法

01

需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成；大多数的需求分析方法是由数据驱动的；数据域具有三种属性: 数据流、数据内容和数据结构。

补充：描述加工逻辑的工具

01

结构化语言，介于自然语言和形式语言之间的语言，结构化语言的特点：无确定语法可分层、嵌套
02

判定表(决策表) 描述多条件、多目标动作的形式化工具
03

判定树(Decision 决策树)

图形工具

01

E-R模型；层次方框图；Warnier图；IPO图。
02

E-R模型：通过使用矩形框、菱形框、椭圆框或者圆角矩形及连线来描述“实体”、“联系”和“属性”现实世界的一种方法。
03

Warnier图：用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息量是重复出现的，也可以表示特定信息在某一类信息中是有条件出现的。
04

IPO图（输入/处理/输出图）：IPO图是IBM公司发展完善起来的一种图形工具，能够很方便地描绘输入数据、对数据的处理和输出数据的关系。 IPO图的基本形式是在左边的框中列出有关的输入数据，在中间的框中列出主要的处理，在右边的框中列出产生的数据。

需求分析的评审

01

系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述;被开发项目的数据流与数据结构是否足够，确定; 所有图表是否清楚，在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内，是否都已充分说明; 设计的约束条件或限制条件是否符合实际; n开发的技术风险是什么;是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;
02

需求评审面临的困难 1，需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。 2，需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。 3，开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。 4，开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。 5，人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案

需求分析评审的方法

01

验证需求的一致性；验证需求的现实性；验证需求的完整性；验证需求的有效性。

软件需求分析

有关需求的基本概念

软件需求分析的任务

需求分析的步骤

软件需求规格说明的原则

需求分析的方法

补充：描述加工逻辑的工具

图形工具

需求分析的评审

需求分析评审的方法

相关推荐