如何做好软件项目需分析

[如何做好试卷分析]一、试卷分析的意义：考试是一个完整的教学过程中不可缺少的组成部分，是对教和学的质量的检验。考试对教学有巨大的指挥作用。特别是家长对考试成绩有强烈的反响。对于考试的...+阅读

如何做好软件项目需分析

需分析是介于系统分析和软件设计阶段之间的重要桥梁。一方面，需分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

需分析阶段的基本任务是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件其它有效的需。

最主要的原因是对于开发小组的使用成员（包括用户）来说，需确定是极具认知性和创造性的活动。需确定也许是仍在苦苦等待人工智能支持的最后领域之一。具体表现如下：

系统分析员对问题域的了解程度也是一大困难。

系统分析员感到需确定很困难的另一个原因是问题域的动态性。

生活是动态的，公司也是。

项目团队成员之间的沟通也一直是需确定的另一大困难。

每个问题域都有术语。

最后，需确定过程还会受到其它因素的影响。例如劳累、不舒服、开会时室内和窗外的干扰、团队成员的压力等等。

软件设计时什么是需分析

软件需

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需分析阶段埋下的“祸根”（Leffingwell 1997）。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。

在软件工程中，所有的风险承担者（stakeholder）（这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人）都感兴趣的就是需分析阶段。这些风险承担者包括客户、用户、业务或需分析员（负责收集客户需并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需分析过程。

软件需的定义

IEEE软件工程标准词汇表（1997年）中定义需为：

(1)用户解决问题或达到目标所需的条件或权能（Capability）。

(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

(3)一种反映上面（1）或（2）所描述的条件或权能的文档说明。

需的层次

下面这些定义是需工程领域中常见术语的定义说明。

软件需包括三个不同的层次—业务需、用户需和功能需—也包括非功能需。业务需（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要，它们在项目视图与范围文档中予以说明。用户需（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。功能需（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需。所谓特性（feature）是指逻辑上相关的功能需的集合，给用户提供处理能力并满足业务需。软件需各组成部分之间的关系如图所示。

作为补充，软件需规格说明还应包括非功能需，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

值得注意的一点是，需并未包括设计细节、实现细节、项目计划信息或测试信息。需与这些没有关系，它关注的是充分说明你究竟想开发什么。

Frederick Brooks在他1987年的经典的文章“No Silver Bullet:Essence and Accidents ofSoftware Engineering ”中充分说明了需过程在软件项目中扮演的重要角色：

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需是什么，这是千真万确的。如果你的用户告诉你需就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。

实例帮我解释下如何做软件的需分析

项目需分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80%是由于需分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需分析的把握程度。在原则上，需阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。为了保证项目的成功，监理方必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80%是由于需分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需分析的把握程度。

而项目的整体风险往往表现在需分析不明确、业务流程不合理，用户不习惯或不愿意去用承建方的软件。作为第三方的监理公司，必须提醒承建方、客户方重视需分析的重要性，采用必要的手段和方法来进行需调研，同时监理方也应深入具体的需调研中去。只有这样才能切切实实地把握用户的需和方向，才能在将来的功能界定、开发范围上有发言权。如何进行需分析需分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1,D2,D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。

Di={P1,P2,P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3，…Fk} 需说明书应该对于那些只想了解宏观需的领导，和需要了解细节的技术员都合适。在写需说明书时应该注意两个问题： 1.最好为每个需注释“为什么”，这样可让程序员了解需的本质，以便选用最合适的技术来实现此需。 2.需说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需。重点监控需分析由于项目的特殊性和行业覆盖的广阔性，以及需分析的高风险性，软件需分析的重要性是不言而喻的，同时需分析又的的确确难做。其原因基本是由于以下情况造成的。客户说不清楚需有些客户对需只有朦胧的感觉，当然说不清楚具体的需。

例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。此时，用户就会要软件系统分析人员替他们设想需。工程的需存在一定的主观性，为项目未来建设埋下了潜在的风险。需自身经常变动根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需提出新的要和需变更。事实上，历史上没有一个软件的需改动少于三次的！所以必须接受“需会变动”这个事实，在进行需分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需，哪些是易变的需，以便在进行系统设计时，将软件的核心建筑在稳定的需上，同时留出变更空间。

咨询监理方在需分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。分析人员或客户理解有误软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”所以分析人员知识的专一性也会造成需分析的误解和失败。

这时，咨询监理公司就必须根据实际的项目需调研计划，提醒承建方加强业务了解程度和注重沟通技巧。需分析方法论根据以往的工程经验，需分析工作方法，应该定位在“三个阶段”（也称“三步法”）。第一阶段：“访谈式”（Visitation）这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。实现手段：访谈、调查表格输出成果：调查报告、业务流程报告第二阶段：“诱导式”（Inducement）这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用...