软件进行需求分析的方法(软件需求的分析方法)
1.软件需求的分析方法
软件需求分析方法大体分为如下四类：结构化方法、面向对象方法、面向控制方法和面向数据方法。限于篇幅，将主要从结构化方法和面向对象方法以及RUP三个方面进行简要的探讨。 面向对象（Object Oriented, OO）的方法把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型（对象的静态结构）、动态模型（对象相互作用的顺序）和功能模型（数据变换及功能依存关系）。需求工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分.每一级抽象都重复对象建模（对象识别）一动态建模（事件识别）一功能建模（操作识别）的过程，直到每一个对象实例在物理（程序编码）上全部实现为止。
面向对象需求分析（OORA）利用一些基本概念来建立相应模型，以表达目标系统的不同侧面。尽管不同的方法所采用的具体模型不尽相同，但都无外乎用如下五个基本模型来描述软件需求：
整体—部分模型：该模型描述对象（类）是如何由简单的对象（类）构成的。将一个复杂对象（类）描述成一个由交互作用的若干对象（类）构成的结构的能力是OO途径的突出优点。该模型亦称聚合模型。
分类模型：分类模型描述类之间的继承关系。与聚合关系不同，它说明的是一个类可以继承另一个或另一些类的成分，以实现类中成分的复用。
类—对象模型：分析过程必须描述属于每个类的对象所具有的行为，这种行为描述的详细程度可以根据具体情况而定。既可以只说明行为的输入、输出和功能，也可以采用比较形式的途径来精确地描述其输入、输出及其相应的类型甚至使用伪码或小说明的形式来详细刻画。
对象交互模型：一个面向对象的系统模型必须描述其中对象的交互方法。如前所述，对象交互是通过消息传递来实现的。事实人对象交互也可看作是对象行为之间的引用关系。因此，对象交互模型就要刻画对象之间的消息流。对应于不同的详细程度，有不同的消息流描述分析，分析人员应根据具体馆况而选择。一般地，一个详细的对象交互模型能够说明对象之间的消息及其流向，并且同时说明该消息将激活的对象及行为。一个不太详细的对象交互模型可以只说明对象之间有消息，并指明其流向即可。还有一种状况就是介于此两者之间。
状态模型：在状态模型中，把一个对象看作是一个有限状态机，由一个状态到另一状态的转变称作状态转换。状态模型将对象的行为描述成其不同状态之间的通路。它也可以刻画动态系统中对象的创建和废除，并称由对象的创建到对象的废除状态之间的退路为对象的生存期。
状态模型既可以用状态转换因的图形化手段，又可用决策表或称决策矩阵的形式来表。 RUP(Rational Unified Process)是Rational公司开发和维护的过程产品。RUP是工程化的软件开发过程，它提供了在开发机构中分派任务和责任的纪律化方法。RUP不仅仅是一个简单的过程，而是一个通用的过程框架，可用于各种不同类型的软件系统、各种不同的应用领域、各种不同类型的组织、各种不同的功能级别以及各种不同的项目规模。RUP的突出特点可以由以下三个关键词来体现——用例驱动、以构架为中心、迭代和增量的。这些是RUP所特有的，也是同等重要的。构架提供了一种结构来指导迭代过程中的工作，而用例则确定了目标井驱动每次迭代的工作。
进行需求分析的基础是要获得用户的需要，为了完成这一工作，必须建立业务模型，通过描述业务规则、业务逻辑，明确业务过程并对其进行规范、优化。对于一个系统，在建立业务模型时，应从3个方面来描述其特性：功能、行为、数据，对应于这些特性。 基于上述分析可知，结构化分析方法与面向对象分析方法的区别主要体现在两个方面：
* 将系统分解成于系统的方式不同。前者将系统描述成一组交互作用的处理，后者则描述成一组交互作用的对象。
* 子系统之间的交互关系的描述方式不一样。前者加工之间的交互是通过不太精确的数据流来表示的，而后者对象之间通过消息传递交互关系。
因此，面向对象软件需求分析的结果能更好地刻画现实世界，处理复杂问题，对象比过程更具有稳定性，便于维护与复用。
2.软件工程中常用的需求分析的方法有哪些
一、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。
也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。
过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。1. 用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。
如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。
需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景，是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。
也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。
2. 功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。
如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。
需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。
所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。
结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。
二、拆分和聚合的方法1. 拆分需求法业务用户提出一个需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。
每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。
需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。
这里不一一展开。2. 聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。
例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。
然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。三、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。
比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。
看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。
需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。
因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。
于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。
这个方式的重点是记录和分析操作前状态、操作位。
3.需求分析有哪些方法
三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。
结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。
面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人员的要求非常高。
4.软件需求分析在软件工程中的作用,有哪些软件需求分析的方法
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。
在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发，能否获得成功，最重要的是需求分析的工作。因此，软件需求分析能力和水平，对软件项目至关重要。
一般的分析方法和步骤如下：
⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有：
⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
5.如何进行软件需求分析
软件需求的定义：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。需求工程的定义：需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。需求开发与管理的一些方法：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。3）建立需求基准版本和需求控制版本文档。
确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。5）跟踪每项需求的状态。
可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。6）衡量需求稳定性。
可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚。
4.需求分析评价标准 （1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。
需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。
实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
6.需求分析的步骤有哪些
一、需求识别 需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。
1.需求类别确认：需求类别包含流程类需求、统计分析类需求、接口类需求，一个需求可能为某一类型需求，也可能包含多类需求。确认需求类别后应对每类需求的数量进行初步分析（比如流程类需求包含几个流程、统计分析类需求包含几个报表、接口类需求包含几个接口）。
2.需求复杂度分析：一般需求受理工作量在1-5人天的需求复杂度低，工作量在5-15人天的需求复杂度中，工作量在15人天以上需求复杂度高。（工作量表示需求受理全过程需求人员需要付出的工作量）。
3.价值分析：需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定需求价值，需求价值分析 二、业务流程/统计查询/接口分析 针对流程类需求必须进行业务流程分析，统计查询和接口类需求可不进行详细的流程分析。1.业务流程分为部门级、组织级和岗位级 部门级流程关注脉络需要分析涉及哪些具体岗位、执行活动、每个活动之间的关联关系，它是需求分析的主线条，也是流程分析的主要产物。
组织级流程关注宏观一般不会直接绘制，是对部门级流程的概括和抽象。岗位级流程关注每个业务活动的执行步骤属需求细节范畴，在流程分析阶段不要过度进入细节。
2.需求识别阶段确认的流程均为部门级流程 需求人员在进行流程分析应遵循如下方法：（1）业务流程确认：一个流程为一个业务事件，一般是外部角色发起或系统内部主动发起（比如时间事件或状态事件），发起后会触发一系列业务活动。（2）角色及业务活动确认：流程图中的每个泳道都必须对应到角色，每个角色对应多个业务活动。
需求人员在确认业务活动时一定要保证活动的粒度，一个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。比如项目输入项目名称是一个执行步骤，这个动作没有价值，项目经理查询项目信息就是一个业务活动。
在需求描述时针对线下活动或新增活动应该应标识区分。（3）业务活动间关系及数据确认：确定所有业务活动的前后置关系，并明确流程间的传递的数据实体。
（4）流程整体瓶颈分析：一般若某个角色业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求人员应想办法分散工作量提出流程优化建议。3.针对统计查询类需求及接口类需求，按照上述业务活动确定原则分析、确定角色，并明确每个角色所执行的业务活动即可。
三、数据实体分析 针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件和查询展现两类数据实体、接口类需求需要分析接口传递数据实体，具体分析包含如下内容：1.明确数据实体：确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。2.明确所有数据实体间关系：实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。
3.明确数据实体字段：针对新增数据或改造数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式（人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式）。4.数据权限分析：需要分析不同角色在数据权限方面的差异，若涉及纵向多级用户，要说明对于集团/省/地市用户的数据隔离。
四、角色及使用场景分析 一般来说每个业务活动是对用户使用场景的抽象，每个业务活动可能包含多个场景，分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容：1.明确活动执行角色。2.明确活动执行的前置条件和后置条件。
3.明确不同场景：一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景；4.明确每个场景的执行步骤：描述执行步骤时应使用简单的语法，主语明确语义易于理解，每个步骤不应该在任何一方（执行角色、系统）停留两部以上，重点描述如何交互。5.业务规则和约束：明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则（比如项目周期时长超过90天必须提交二级领导审批），或与数据实体相关的数据规则（需求交接单拒收时候必须填写拒收原因，且拒收原因不能超过500字）。
五、系统功能分析。
7.需求分析有哪三种方法
它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。
三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。
