需求分析why、what、how

需求分析与定义：做什么
可行性分析是要决定“做还是不做”。

需求分析是要决定“做什么，不做什么”。

即使可行性分析是客观的、科学的，但决策仍有可能是错误的。

因为决策者是人，人会冲动，有赌博心态。

如果可行性分析表明做某件事的成功率是10%，失败率是90%，倘若该事情的意义非常大，决策者也许会一拍脑袋：“豁出去，干！”于是这世界就多了一份极喜与极悲。

4.1节讲述可行性分析的四大要素：经济、技术、社会环境和人。

·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。

“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

下一层次需求——用户需求，必须从使用产品的用户处收集。

因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。

例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。

业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。

功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

业务需求、用户需求、功能需求，这三者之间，并不是完全并列的关系，而是在逻辑上有着从外到内、从整体到细节的深入和细化的关系。

比如：要设计一个系统-电视机，（这玩意儿大家都清楚是干么的吧， 8) ）
1。

业务需求：为用户提供看电视的服务。

请注意，是服务，是用从外部的眼光，全局的性看这一需要实现的东东。

2。

用户需求：为了让用户能够看到电视节目，需要提供：接受电视信号、显示到屏幕、可以换台等。

这些内容都是为业务需求服务的，也是为了能够看到电视节目所必不可少的。

即，用户需求，是业务需求的深入和细化。

3。

功能需求：对用户需求的内容进一步细化：如何才能提供接受电视信号的功能？答：需要有信号接收器，并进行信号变化处理。

软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

所谓约束是指对开发人员在软件产品设计和构造上的限制。

质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。

多角度描述产品对用户和开发人员都极为重要。

作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

所谓约束是指对开发人员在软件产品设计和构造上的限制。

质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。

多角度描述产品对用户和开发人员都极为重要。

值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。

需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

需求分析与定义
1. 软件需求：
软件需求分为三大部分：
I．功能需求：指系统需要完成那些事情，即向用户提供那些功能。

II．非功能需求：指产品所具备的品质和属性，比如可靠性、扩展性、响应时间、性能等等。

III．设计约束：也称条件约束、补充规则。

比如用户要安装该产品他需要有什么样的必备条件。

（系统对操作系统的要求、硬件环境的要求等等…..）
2. 需求调查与问题定义：
在做需求调查时需要做到两W一H即 What、Where、How
I. 应该收集什么信息What-----
II. 从什么地方收集Where----
III. 用什么机制或技术来收集How-------
3. 需求分析
需求分析通常包括七个方面：
I．绘制系统上下文范围关系图：主要用于定义系统与系统外部实体间的界限和接口的简单模型，他可以为需求确定一个范围。

其实就是DFD
的0层图。

II．创建用户接口原型：这里我们可以把他看成是用户操作的一个雏形，什么意思呢就是我们通常所说的界面用户通过一系列的操作完成他想达到的效果的接口。

III．分析需求的可行性：这个需求我们应该用什么技术解决，他实现后的性能怎么样，是否与其他需求相重合或是矛盾，这里一定要注意不要把系统的这个需求怎么用代码实现想进去。

在需求分析时应多注意需求本身是否有用不必考虑怎么实现
IV．确定需求的优先级：可采用满意度/不满意度指标来说明（满意度1-5 表示当需求被实现时用户的满意程度；不满意度取值同理）
V．为需求建立模型：这里可以用UML创建用例图或是E-R图再加上少量的文字描述。

VI．使用质量功能调配（QFD）：这里我的理解是分析员根据需求的理解发现隐藏需求而这些需求是用户也没有想到的需求，系统实现后会给用户一个惊喜，而没实现用户也不会有抱怨。

4. 需求分析方法
现在比较流行的软件需求分析方法有4种，其中3种理论比较成熟
I．结构化分析方法（Struetured Analysis,SA）：这个大家想必很熟悉了不在复述。

II．软系统方法：这只是过度性的方法论他的出现只是证明结构化分析方法的一些不足。

因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决“不确定性”时显得十分无力。

III．面向对象分析方法（Object Oriented Analysis，OOA）：这也是我下文想讲的分析方法
IV．面向问题域的分析（Problem Domain Oriented Analysis,PDOA）：OOA也存在着很多不足，但PDOA现在正在研究中所以未被广泛应用
这里需要注意的是：在软件开发中有很多需求分析方法他们没有好坏之分只要你运用得当照样可以做出一个很好的系统，依据个人对某个方法的理解用自己最擅长的方法是最明智的选择。

5. 面向对象需求分析（OOA）
面向对象这个概念很简单但也很复杂我在这里不做深入探讨。

我将从实际出发来和大家一起探讨下在实际开发中我们应该怎么做。

OOA的精髓在于世间万物均为对象采用OOA方法在整个过程中包括2个工作任务：建立一个反应问题域静态关系的概念模型，就是我们通常所说的类图；另一
个反应系统行为的动态模型，即用例模型
那么我们在实际开发中到底怎么做呢？
1）建立域模型
I．寻找类：在寻找类时有多种方法典型的是根据需求文档用“名词动词法”来寻找，找出备选类后再从中寻找出真正的类。

（注意在用此方法时切记不要咬文嚼字专牛角尖在这里花费很长的时间）
II．确定类之间的关联：这个过程是迭代的我们需要理清楚这些类之间的关系如关联、继承、聚合等然后通过UML记录下来。

类之间的关系不是一下子就能确定下来的是要慢慢完善的
III．为类添加职责：这里就可以理解成为类添加所需要的属性和方法。

IV．域模型的详细度：这里不做太多要求可以写的很详细也可以写的简单写，可以把握好一个原则：只要能有利于团队更好的开发就是好模型。

2）建立用例模型
I．什么是用例：
用例实例是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的价值结果。

（用例实例就是常说的“使用场景“）一个用例定义一组用例实例。

II．识别参与者：
用例主要是为了让客户直观的理解需求那么这里参与者是必不可少的这样才能形象的勾画出系统某个特定场景下的流程。

注意参与者不仅可以是人也可以是其他的事物如（其他系统、硬件设备、时钟等等）
III. 合并需求获得的用例
IV．绘制用例图（如果对用例图不清楚请参考UML相关文章）
V．细化用例描述
用例描述可以包括以下几个部分：
u 用例名称
u 简要说明
u 事件流：是该用例要完成的工作步骤
u 非功能需求
u 前置条件
u 后置条件
u 扩展点
u 优先级别
3）要想做好需求分析光上面的用例是不够的还有写建模技术也要有如：协作图、顺序图和状态图
u 协作图：是一种用以显示对象如何被协调在一起执行用例的图，用来识别协作完成给定业务的对象。

u 顺序图：是一种用以显示用例对象之间消息顺序的图，他与协作图表达的信息是一样的知识显示的方式有差别。

顺序图以图形化的方式强调消息的顺
序，而非协作对象间的顺序。

他和协作图统称为交互图。

u 状态图：是一种用以显示对象在生命周期和转换期情况的图
什么是优秀的需求
讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA 的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。

清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。

自然语言对需求分析最大的弊病就是它的二义性。

所以我们不得不对需求分析中采用的语言做某些限制。

例如尽量采用主语＋动作的简单表达方式。

说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。

除了语言的二义性之外，主意不要使用行话，就是计算机术语。

需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。

信用卡有卡号、余额。

一张信用卡有多笔的交易记录。

完整：再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。

需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。

可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。

要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。

至于完整性的详细讨论，我们会在下面的章节中讨论，现在你只需要拼命的想象缺乏完整性的坏处，直到你出了一身的冷汗。

出了吗？好，那我们继续。

一致：一致性也是一个比较大的概念，很难用几句话讲清楚。

还记得我们在开始的时候提到的需求的层次吗？简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。

严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

在实现过程中，我们还必须把一致性关系细化。

比如说用户需求不能超出先前指定的范围。

可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。

更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。

这些都没有错。

但是实际上测试是从需求分析过程就开始了。

需求分析是测试计划的输入和参照。

这就要求需求分析是可测试的。

什么是可测试呢？“我们要用新的系统完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。

因此
这项需求是无法测试的，就是不具有可测试性。

说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。

事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件
系统是成功的。

大家真正在应用一些科学的方法的时候也应该记住，任何的方法都是为了保证软件的成功，不要偏离这个目标，千万不要走火入魔了，呵呵，很容易的。

需求分析是对用户需求的真正明确，是对要解决的问题的彻底理解。

在解决问题之前要理解问题，只有真正的理解问题才能更好的解决问题。

需求分析就是给系统分析、设计人员一个和用户交流来理解问题的机会—了解用户究竟需要什么。

需求分析也是一个建模的过程，与在概要设计中建模不同在需求分析中建模是面向用户的过程。

而在概要设计中的建模过程是面向开发人员的过程。

这样两种建模的过程就会存在差异和不同，从而使用自然语言进行描述也就不同。

在传统的软件工程中并不建议大量的使用自然语言对软件的需求进行描述，因为太多的自然语言会引发出很多问题。

比如说，二义性即不同的人对自然语言的描述会有不同的理解，就是再好的文档编写人员也不会保证他的文档不存在二义性。

毕竟我们不是语言学家。

这样就引入了借用图示进行功能的描述和建模的过程。

图示有其自己的优势比如，清晰，明确给人直观的感觉。

无论是何种背景的人群都可以理解。

这样就大大减少需求分析中的二义性。

从而使系统设计人员和用户更加有效的沟通。

这样也增加了软件的正确性。

在传统的软件工程中提供了多种不同的图示，每一种都从不同的角度对同一个问题进行描述，之所以这样。

可以使系统开发人员在不同的图示中挑出最适合他和他的团队进行问题详尽描述的一个或者一些图示。

比如数据流图，在需求分析中使用数据流图，就充分体现了数据在软件系统中移动时被变换的逻辑过程。

所以就是一个建立功能模型的最好图示；而实体关系图，就是描述数据对象以及他们之间关系的图示，所以就是一个建立数据模型的最好例子。

状态转换图通过事件的外部作用从而对状态进行改变，这就是一个建立行为模型的例子。

在做需求分析时，尽量做到问题阐述明确。

可是一直有一个问题困扰，就是应该选择什么样的图例进行系统的描述是，数据流图，状态转换图还是实体关系图？其实不同系统设计人员给出的答案不会是一样的。

这并不是一个哲学问题而是一个应用问题。

从客户的角度出发使用实体关系图是最好的选择，而数据流图完全就是为系统设计人员量身定做的一样。

因为程序员更关心事物内部的逻辑性和相关性；而用户只关心事物的外部表征和特性。

所以问题的答案只有每个人自己去寻找，寻找一个最能体现用户需求和问题解决方案的图示。

在按照模版进行需求分析撰写的时候，发现有很多模版条目的要求是在需求分析的最初阶段是无法给出确切的答案的。

有的条目要经过概要设计，详细设计之后才能对文档内容进行修改和填充。

同时对其他同行撰写的需求分析文档进行研究发现，一个优秀的需求分析说明说并不是按照规定模版条目不变的照搬。

其实有些冗余的项目完全可以不必关心。

毕竟撰写需求分析的真正目的，是让系统设计人员知道用户的需求。

其他的不必过多强求。

需求分析文档规范
A、三种编写方法
1、用好的结构化和自然语言编写文本型文档；
2、建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系；
3、编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的。

B、应有成果
1、各业务手工办理流程文字说明；
2、各业务手工办理流程图；
3、各业务手工办理各环节输入输出表单、数据来源；
4、目标软件系统功能划分（示意图及文字说明）；
5、目标软件系统中各业务办理流程文字说明；
6、目标软件系统中各业务办理流程图（模型）；
7、目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。

8、目标软件系统用户界面图、各式系统逻辑模型图及说明
C、文档工具推荐
1、调研结果《需求分析说明书》格式参照开发文档模板；
2、单位组织结构图、功能模块分解图用VISIO绘制，或直接用WORD中的画图工具；
3、业务流程图用VISIO中的FLOWCHART模板绘制；
4、系统逻辑模型使用ROSE绘制活用VISIO中的UML模板绘制；
5、软件用户界面用VISIO中的WIN95 USER INTERFACE模板绘制；
6、数据物理模型用POWERDESINER绘制；
D、需求文档编写原则
1、句子简短完整，具有正确的语法、拼写和标点；
2、使用的术语与词汇表中所定义的一致；
3、需求陈述应该有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。

；
4、避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”；
5、避免使用比较性词语，如“提高”，应定量说明提高程度
需求分析
一、需求分析的任务
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么？”这个问题。

需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。

通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中。

它是软件实现的基础。

需求分析的任务不是确定系统如何完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

在这个阶段结束时交出的文档中应该包括详细的数据流图（DFD），数据字典（DD）和一组简明的算法描述。

需求分析阶段的任务包括下述几方面。

1．确定对系统的综合需求
2．分析系统的数据需求
分析系统的数据需求是由系统的信息流归纳抽象出数据元素组成、数据的逻辑关系、数据字典格式和数据模型。

并以输入/处理/输出（IPO）的结构方式表示。

因此，必须分析系统的数据需求，这是软件需求分析的一个重要任务。

3．导出系统的逻辑模型
就是在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质。

4．修正系统开发计划
5．开发原型系统
二、需求分析的步骤
结构化分析方法（简称SA方法）就是面向数据流自顶向下逐步求精进行需求分析的方法。

需求分析的步骤如下。

1．调查研究
2．分析与综合
应注意下述两条原则：第一，在分层细化时必须保持信息连续性，也就是说细化前后对应功能的输入／输出数据必须相同；第二，当进一步细化将涉及如何具体地实现一个功能时，也就是当把一个功能进一步分解成子功能后，并将考虑为了完成这些子功能而写出其程序代码时，就不应该再分解了。

3．书写文档
在这个阶段应该完成下述四种文档资料：
（1）系统规格说明。

（2）数据要求。

（3）用户系统描述。

（4）修正的开发计划。

4．需求分析评审
三、需求分析的原则
1．必须能够表达和理解问题的数据域和功能域
2．按自顶向下、逐层分解问题
3．要给出系统的逻辑视图和物理视图
四、需求分析方法
大多数的需求分析方法是由数据驱动的，数据域具有三种属性：数据流、数据内容和数据结构。

通常，一种需求分析方法总要利用一种或几种属性。

需求分析方法具有以下的共性。

1．支持数据域分析的机制
2．功能表示的方法
3．接口的定义
4．问题分解的机制以及对抽象的支持
5．逻辑视图和物理视图
6．系统抽象模型
五、面向数据流的需求分析方法
结构化分析方法是面向数据流进行需求分析的方法。

结构化分析方法使用数据流图DFD与数据字典DD来描述，面向数据流问题的需求分析适合于数据处理类型软件的需求描述。

其核心思想是分解化简问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。

六、数据流图
数据流图是描述数据处理过程的工具。

1．数据流图的含义
数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的传输变换过程。

数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能。

2．数据流图的特性
（1）抽象性
（2）概括性
（3）层次性
3. 数据流图基本符号
（1）数据流图中的主要图形元素
数据流图的基本图形元素有4种，
数据流图基本图形符号
（2）数据流与加工之间的关系
其中星号“*”表示相邻的一对数据流同时出现，? 则表示相邻的两数据流只取其一。

（3）分层的数据流图。