需求分析与定义

需求分析与定义

有一组对23000个项目进行的调查显示，有28%的项目彻底失败，46%的项目是超出经费预算或超出工期。而在这些不成功的项目中，有大约60%的失败是源于需求问题。

1.软件需求与需求过程

2.1什么是软件需求

软件需求就是系统必须完成的事情以及必须具备的素质。软件需求必须包括功能需求，非功能需求和设计约束三方面。

·功能需求：即软件所要完成是事情

·非功能需求：只软件产品所必须具备的属性或品质，如可靠性、性能等。

·设计约束：也就是限制条件、补充规约；例如：软件产品必须采用国产软件，数据库系统的选择等等。

2.2需求工程

通常包括需求开发和需求管理两大工作。

·需求开发：包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。

·需求管理：包括定义需求准线、处理需求变更、需求跟踪等方面的工作。

2.需求调查与问题定义

做好需求调查我们要弄清楚3个问题：

·What ----应该收集什么信息

·Where----从什么地方收集信息

·How----用什么机制或者技术来收集信息

2.1 What –要捕获的信息

包括三大类：一是与问题领域相关的信息（如业务资料、组织结构图、业务流程图等）；二是与要求解决的问题而相关的信息；三是用户对系统的特别希望与施加的其他要求。

2.2Where----信息的来源

应该对所有涉众人进行分类，然后每个分类中找到几个代表。在实践需求捕获的时候，我们不妨列出一个表格，左边写上系统分析人员想了解的信息，右边写上可能认为的来源。

2.3How----需求捕获技术

A．用户访谈

B． 用户调查

C． 现场观摩

D．文档考古，即跟踪一些数据流复杂业务的数据流程。

E． 联合讨论会

最后，需要说明的一点是在整个需求的过程中，需求的捕获、分析、规格化文档与验证过程不可能是一蹴而就的，而是在经过问题的发现到问题的解决间反复演化。

3．可行性研究

可行性研究顾名思义就是研究一个系统方案行不行、可不可以完成的过程。分析师需要进行一次高抽象的系统分析与设计，但是可行性研究毕竟不是解决问题，而是研究问题的范围，所以千万不能研究的太过深入，以免掉入泥潭。我们仅需要探索问题是否值得去解决，是否有更有效的办法代替，最终找到一个平衡点。

3.1可行性研究工作的任务

1.技术可行性

2.经济可行性

3.社会可行性，即该解决方案是否符合企业的实际情况、是否符合相关规范和法律。

3.2可行性研究工作的步骤

1.合适问题定义与目标

2.研究分析现有系统

3.为新系统建模

在前两步工作的基础上，为系统建模可以获得对系统框架的基本认识，通常有以下几种技术

·系统上下文关系范围图：即DFD（数据流程图）的0层图，将系统与外界实体的关系体现出来。

·实体关系图：即系统的数据模型，这个阶段并不需要完整的ER图，只要找出实体与实体间的关系即可。

·用例（Use Case）模型：主要整理出系统的功能框架，处于系统的概念级别，无需追求细节，描述出大致即可。

·域模型：采用OO的思想，找出系统主要实体及其间 的关系。

·IPO表：这是采用传统的结构化思想，从输入处理输出的角度进行描述。

注意，这部分工作所有模型不是精确的，是一个框架，只要从宏观的高度了解即可，否则将陷入无休止的工作中。

4.客户复核

因为前3步都是程序员眼中的问题定义，那么当然要与用户一起复核。

5.提出并评价解决方案

6.确定最终的解决方案

这步需要详细的说明选择的方案的理由，要对其进行更加完善的成本/效益分析。

成本、效益分析包括两个部分的内容

A．成本估计：主要是人力成本，其他还包括一些直接费用、设备采购费用等。对于人力成本就需要计算工作量，计算的方法可以借鉴历史数据和经验模型。经验模型常用的有功能点分析、COCOMO分析等。

B． 效益分析：进行效益分析前手写对系统应用后带来的直接、间接收益，以及成本降低的具体数额。

效益分析的几个概念：F=P（1+i）的N次方，其中F代表未来的价值，P为现在的价值，i为年利率，n为年数。

投资回报率：投资回报率（ROI）=年利润或年均利润/投资总额×100%。一般要求算整个系统生命周期的总投资回报率。我们在计算的时候要考虑汇率。P=F1/(1+j)+F2/(1+j)2+…+Fn/(1+j)n （n为系统周期）

7.草拟开发计划

8．提交“可行性分析报告”并进行审查

4．现有系统分析

对现有系统的分析是一个很重要的工作是仔细阅读相关的文档资料和使用手册。

结合系统分析，应该从现有的系统的物理模型出发，通过研究分析建立起高层的逻辑模型描述，然和在此基础之上综合考虑各种问题，发展成为新系统的逻辑模型，再根据新系统的逻辑模型建立起相应的物理模型。这里有个误区是容易花费过多的时间在对系统的细节了解上，我们只需要了解宏观即可。

5．需求分析

1．确定需求。利用需求工程的方法，并列出系统需求列表。

2.确定系统功能点：有几个问题，功能点是怎么出来的，如何进行表达，如何描述，应该包含怎样的信息等。

根据需求列出功能点，功能点有两种，就是做和不做两种状态。我们在设计的时候应该为不做的功能尽量预留接口，也就是保留将来做的可能。需求分析得出的功能列表只包括那些做的功能点，并针对每一个功能点加上详细的描述。对于面一般的软件开发而言，UML的用例图可以方便的进行功能点的描述。另外在编写《功能点说明书》的时候，要进行补充说明，包括功能点的名称和目标，以及各种约束。有些功能点还要写出主要的流程。

3.确定项目约束

4.流程分析和组织机构分析

流程分析就是要对客户的整个业务流程进行分解，最终变成一个个最小的单步操作，其中每个操作都可以简单的实现。流程的最小单元是一个个的任务，这些任务可由人机交互完成，也可以由计算机来完成。完成了这样的分析就完成了对软件的工作模式进行建模。

5.确定软件的使用方式

6.生成系统的软件需求分析说明书。

这样，需求的工作就算完成了，在以后的博客中我将说明我是怎么写《需求分析说明书》的 ，它实际是《功能点说明书》和《项目约束说明书》机流程分析和组织结构分析的合体。