功能需求分析方法

‘壹’ 如何进行软件需求分析

软件需求分析免费下载

链接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

‘贰’ 需求分析的步骤有哪些

一、需求识别
需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。

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字）。

五、系统功能分析

‘叁’ 需求分析的方法

原型法：获取一组基本需求之后，快速构造出一个能够反映客户需求的初始系统原型。

让用户看到未来系统的概貌，以便判断哪些功能是符合要求的，哪些还需要改进。

按照信息的流向、结构和内容三个方面将现有的需求分析建模方法划分为结构化分析方法，Jackson分析方法和面向对象分析方法。

通过E-R图提供表示实体、属性和联系的方法，描述显示世界中的概念模型，不涉及这些实体在系统中的实现方法。

通过数据流图描述逻辑模型，表示数据在系统内的变化；分层表示信息流和功能的细节。

行为建模采用动态分析方法，直观地分析系统的动作，最常用的动态分析方法包括状态迁移图，时序图和Petri网。

状态迁移图通过描述状态以及导致系统改变状态的事件来表示系统的行为，指明了系统如何在状态间移动。

‘肆’ 软件工程中常用的需求分析的方法有哪些

一、过滤需求的方法
做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。

这不是一个贬义词，反而是体现后端产品价值判断的基础。

过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。

1. 用户场景模拟法
后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。

如果不能帮助用户，那么这个需求就可能是伪需求。

以下面的案例说明：

背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。

需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。

分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。

因此，该需求是个伪需求，应该被过滤掉。

2. 功能归属分析
专门的系统做专职功能，有助于合理的产品体系建设。

因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。

如果不属于该系统范畴，那么直接说服需求方更换方案。以

下面的案例说明：

背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。

需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。

分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。

所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。

之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；

其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。

结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。

否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。

二、拆分和聚合的方法
1. 拆分需求法
业务用户提出一个需求，很可能只是短短的一段话。

但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：

先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。

每个需求点再当做一个子需求进行调研，最后再聚合在一起。

以下面的案例说明：

背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。

需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。

该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：

自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。

这里不一一展开。

2. 聚合需求法
拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：

由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。

然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。

三、利用辅助功能调研需求
调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。

比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。

最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：

背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。

需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。

分析：需求是很明白的，也有它的意义，但有风险。

因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。

因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。

于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。

测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。

四、“拔萝卜带出泥”的方式调研需求
调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。

举例说明：

背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。

需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。

分析：

第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……

第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……

通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。

罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。

‘伍’ 需求分析常用方法

行为事件分析

行为事件分析是根据运营关键指标对用户特定事件进行分析。通过追踪或记录用户行为事件，可以快速的了解到事件的趋势走向和用户的完成情况。

以用户投标的行为事件为例，出借人在完成投标过程中，所进行的注册、认证、开户、充值、投资等行为，都可以定义为事件，也是完成投标成功的一个完整事件。
确定投标行为事件后，我们可以根据事件属性细分维度：用户来源、性别、出生年月、注册时间、绑卡时间、首次充值时间、首次投资时间、标的ID，标名、期限、利率、还款方式等。然后从中找出符合指标的规律，并制定针对性的措施。

用户留存分析

用户留存分析是一种用来分析用户参与情况与活跃程度的模型。通过留存量和留存率，可以了解用户的留存和流失状况。比如用次日留存、周留存、月留存等指标来衡量产品的人气或粘度。以渠道访问的用户留存为例，我们对APP端有过访问行为的渠道用户进行留存分析。用户留存一般符合40-20-10法则，即新用户的次日留存应该大于40%，周留存大于20%，月留存大于10%才符合业务标准。我们做用户留存分析主要验证是否达到既定的运营目标，进而影响下一步的产品决策。

漏斗模型分析

漏斗模型分析是用户在使用产品过程中，描述各个阶段中关键环节的用户转化和流失率情况。比如在日常活动运营中，通过确定各个环节的流失率，分析用户怎么流失、为什么流失、在哪里流失。找到需要改进的环节，要重点关注，并采取有效的措施来提升整体转化率。

邀请人将活动专题页分享给好友，之后进行的注册、认证、开户、充值到投资，用漏斗模型分析一些关键节点的转化率。其中用户注册转化率为68%，实名认证转化率为45%，绑卡开户转化率为29%，线上充值转化率为17%，投资标的转化率为8%。
漏斗模型分析可以验证整个流程的设计是否合理。经过对比发现，访问到注册的转化率为68%，远低于预期的80%。这次运营策略是用户必须先注册才能领取新手福利。之后采取A/B测试的方式，优化为先领取新手福利再诱导用户注册。经过数据对比分析，注册转化率提升了20%。因此，通过对各环节相关转化率的比较，可以发现运营活动中哪些环节的转化率没有达到预期指标，从而发现问题所在，并找到优化方向。

行为路径分析

行为路径分析就是分析用户在产品使用过程中的访问路径。通过对行为路径的数据分析，可以发现用户最常用的功能和使用路径。并从页面的多维度分析，追踪用户转化路径，提升产品用户体验。

不管是产品冷启动，还是日常活动营销，做行为路径分析首先要梳理用户行为轨迹。用户行为轨迹包括认知、熟悉、试用、使用到忠诚等。轨迹背后反映的是用户特征，这些特征对产品运营有重要的参考价值。我们可以记录用户从注册、认证、开户、充值到投资的行为轨迹。通过分析用户的这些行为轨迹数据，来验证访问路径是否和预期指标的一致。

‘陆’ 需求分析常用方法都有哪些，请举例说明

问卷调查法，是指设计方就用户需求中的一些个性化的、需要进一步明确的需求或问题，通过采用向用户问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。 这种方法适合于设计方和建设方、使用方都清楚项目需求的情况。因为建设方和使用方都清楚项目的需求，需要双方进一步沟通的需求或问题就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。显然对于乐百氏集团这样规模庞大的公司，简单的问卷调查是不能够满足准确获得需求的需要的。会议讨论法，是指设计方和用户相关人员召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于设计方不清楚用户的详细业务需求，但使用方清楚项目需求的情况。因为使用方清楚项目的需求，他们能准确地表达出他们的需求，而设计方有专业的需求，而我们有专业的软件开发经验，经过回忆讨论交流之后，能够对用户的需求进行准确描述和把握。这个方法对于准确的获得乐百氏公司的需求是一种不错的选择。在本案例中系统的设计人员也是这么做的，他们通过和乐百氏项目组经理的讨论，很快了解了乐百氏的运作过程的数据。界面原型法，是指设计方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于设计方和用户都不是非常清楚项目需求、只是大概了解用户需求的情况。因为设计方和用户方都不能非常准确的描述出客户的需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解

‘柒’ 软件的功能需求分析要怎么写

1. 引言

1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.

1.2项目背景

1.2.1项目委托单位:****公司

1.2.2开发单位:***公司

1.3定义

1.4参考资料

2. 任务概述

2.1目标:

<1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示

<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.

2.2运行环境:

<1> 硬件方面:Pentium级处理芯片
1兆显存的兼容显卡
256色,800*600的兼容显示器
标准兼容打印机

<2>软件方面: WIN95操作系统

2.3条件与限制:

编程用计算机一台
完成期限2000/7/1
无资金供给

3. 数据概述

数据流程图如下:

3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据

3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间

3.3数据库描述:

人事管理数据库:公司内人员的个人详细信息,包括档案信息
销售管理数据库:当日销售记录及以前的销售统计,用于销售分析
财务管理数据库:公司内部账目及收支情况详表
技术管理数据库:公司所需各技术档案的详细记录(包括文档)

3.4 数据字典:

<1>数据流词条描述:

1.数据流名:登录信息
来源:用户的输入
去向:系统内部检验部分
组成:用户名,密码
流通量:每次登录输入一次

2.数据流名:登录结果
来源:系统
去向:用户
组成:返回信息
流通量:每次登录返回一次

3.数据流名:输入修改信息
来源:用户
去向:系统判断部分
组成:根据各数据库内容而不同
流通量:依用户输入而定

4.数据流名:反馈信息
来源:系统判断部分
去向:用户
组成:系统经判断后发回的字符数据
流通量: 依系统当前信息而定

5.数据流名:识别信息
来源:系统内部检验部分
去向:系统判断部分
组成:系统各数据库的标识信息
流通量:用户每次输入流通一次

6.数据流名:处理信息
来源:系统判断部分
去向:各数据库处理部分
组成:读取/修改标识,读取/修改的变量名称
流通量:用户每次输入流通一次

7.数据流名:读取修改
来源:系统判断部分
去向:系统各数据库
组成:读取/修改标识,读取/修改内容
流通量: 用户每次输入流通一次

<2>数据文件词条描述:

1.数据文件名:人事数据
简述:存储人员信息
数据文件组成:人员的各项信息(以CString类型为主)

2.数据文件名:销售数据
简述:存储当日及从前的销售记录
数据文件组成:销售的各项信息

3.数据文件名:财务数据
简述:存储财务管理信息
数据文件组成:财务管理的各项记录

4.数据文件名:技术数据
简述:存储公司内部使用的技术档案信息
数据文件组成:技术档案名称,内容

<3>加工逻辑词条描述:

1.加工名:检验
简要描述:判断用户的许可性
输入数据流:登录信息
输出数据流:登录结果
加工逻辑:判断是否与系统内部用户信息相符合

2.加工名:判断
简要描述:判断用户的操作并进行相应的读取/存储工作
输入数据流:输入修改信息
输出数据流:反馈信息
加工逻辑:判断用户的操作->调用数据库->读取/修改->反馈

3.加工名:人事档案管理
简要描述:对人事数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

4.加工名:销售统计
简要描述:对销售数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

5.加工名:财务统计
简要描述:对财务数据库进行相应要求的操作,并与判断部分交互
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

6.加工名:技术管理
简要描述:对技术统计数据库进行相应要求的操作,并与判断部分交互信息
输入数据流:处理信息,读取修改
输出数据流: 读取修改, 处理信息
加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

<4>源点及汇点词条描述:

名称:用户
简要描述:既是源点又是汇点,发出动作信息给"检验"和"判断"加工,通过交互界面接受反馈信息有关数据流:登录结果,登录信息,输入修改信息,反馈信息
数目:一个

4. 功能需求

4.1功能划分

可细分为四部分:人事管理,销售管理,财务管理,技术档案管理

4.2功能描述

<1>人事功能:

(1)能对公司内部的所有人员有关档案详细资料记录并保存。
(2)能对数据库内人事档案的数据进行查阅和修改。
(3)能按部门或姓名检索人员。
(4)当某员工的雇用期限达到整年时，按时提醒。

<2>销售统计功能

(1)按日对公司的销售情况进行统计,包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况
(2)制定销售情况的月报表\季报表以及年报表对销售情况进行分析,对不同销售人员的业绩进行评定

<3>财务管理功能

(1)协助财务人员进行计算机管理,对库存情况\进货情况\销货进行登录和输出
(2) 根据预设的库存情况提醒进货
(3) 对收款情况进行统计,在应收帐款达到预设值时进行提示

<4>技术管理功能

(1)对技术资料进行登录
(2)对维修记录进行登录和统计,按不同型号的机器进行故障整体分析,并作出分析报告
(3)对维修配件的需求进行管理并及时提示备货

5. 性能需求

5.1数据精确度:因为此数据为公司内部数据,所以要求不能有误差

5.2时间特性:当日销售统计要求有即时性,马上能反应出存货的问题;同时财务管理数据计算当前存货情况,并对进货情况进行估算

5.3 适应性:此软件只在公司内部管理人员的机器上使用,因此不考虑适应性

6. 运行需求

6.1用户界面:

屏幕格式:

(1)要求有菜单及工具栏以方便操作
(2)各数据库信息可在屏幕上直接修改
(3)各数据统计结果可在屏幕上显示
(4)进行系统分析后的结果在另一窗口中显示

报表格式:

(1)人事管理报表只要求有个人的普通数据
(2)销售统计报表要求可分别打印当日统计或之前的统计
(3)财务统计报表要求打印出存货及公司帐务详表
(4)技术管理报表要求可以分别打印技术档案总表和任一技术档案文档内容菜单格式:要求菜单项大致与WIN95标准相同,另外附加的功能做到新的单项中输入输出时间:年份以4位数字表示

6.2硬件接口:需要标准打印机接口进行报表打印

6.3 软件接口:Windows标准接口

7. 其他需求

可使用性:要求容易使用,界面友好

安全保密性:因本数据属于公司内部管理用关键数据,因此除公司管理人员外,其他人员不得访问.要求设有登录密码检验功能,并且此密码可以在以后进行修改

可维护性:要求本软件的维护文档齐全,便于维护

‘捌’ 软件工程 需求分析有哪三种方法

软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。 在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。 软件开发，能否获得成功，最重要的是需求分析的工作。因此，软件需求分析能力和水平，对软件项目至关重要。 一般的分析方法和步骤如下： ⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。 ⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。 ⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。 ⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。 ⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。 ⑶请专人介绍。 ⑷询问 对某些调查中的问题，可以找专人询问。 ⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。 ⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

‘玖’ 传统需求分析方法包括哪些主要特点是什么

传统需求分析方法：结构化分析方法。

主要特点：结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。

因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制。

通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。

当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。

需求分析原则

为了促进软件研发工作的规范化、科学化，软件领域提出了许多软件开发与说明的方法，如结构化方法、原型化法、面向对象方法等。这些方法有的很相似。在实际需求分析工作中．每一种需求分析方法都有独特的思路和表示法，基本都适用下面的需求分析的基本原则。

1、侧重表达理解问题的数据域和功能域。对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。

2、需求问题应分解细化，建立问题层次结构。可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。

3、建立分析模型。模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。