需求分析思路

需求说明书应该满足两方面阅读群体，想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题：

1、最好为每个需求注释，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。

2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

一、需求的风险

由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。

1、客户说不清楚需求

有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。此时，用户就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。

2、需求自身经常变动

随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。

3、分析人员或客户理解有误

软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功。所以分析人员知识的专一性也会造成需求分析的误解和失败。

二、短期要求

根据调研情况，详细列出各职能部门的需求，形成需求文档，需求文档应包含以下几点：

1、给出触发功能的各种条件（如：控制流、运行状态、运行模式等）；功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致；

2、定义各种可能性条件下的所有可能的输入（包括合法的输入空间和非法的输入空间）；

3、给出各种功能间可能的相互关系（如各个功能间的控制流、数据流、信息流，功能运行关系：顺序、重复、选择、并发、同步）；

4、尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件，如果出现待定的部分，必须进行待定部分内容说明，落实负责人员、落实实施日期。

5、功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采用和种数据结构，定义多个模块，接口间的接口等）是设计阶段的事情，功能描述不应涉及到那些细节问题，以避免给软件设计带来不必要的约束。

6、需求变更：详细描述变更的内容，定期召开需求变更讨论会，确定需求的变更与否。

三、中长期要求

1、第一阶段：访谈

这一阶段是和具体用户的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。

实现手段：访谈、业务调查表格

输出成果：业务调查报告、业务流程报告

2、第二阶段：诱导

这一阶段是在已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

实现手段：拜访（诱导）、原型演示

输出成果：调研分析报告、原型反馈报告、业务流程报告

3、第三阶段：确认

这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。

实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统

输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、企管信息部进行确认和存档）

需求分析的三个阶段是需求调研中不可忽视一个重要的部分，特别在后期的需求改进中，工作则基本集中在后两个阶段中。

 

第二篇：20xx年总结思路分析