怎么做需分析下

[怎么分析当前时期下我国公路工程质量控制的现状]1。1前期准备阶段的质量控制现状前期准备主要包括公路工程的勘察与设计。所谓公路工程勘察，对施工现场的各种要素进行检查和分析，主要工作包括对施工现场的地质、地形、水文...+阅读

Ivar Jacobson(1992)把这种看法系统地阐述成用例（用例）的方法进行需获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思维过程带给需开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（actor）和用例（用例）。角色（actor）表示系统用户能扮演的角色（role）。这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。

用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以：用例捕获某些用户可见的需，实现一个具体的用户目标。用例由角色激活，并提供确切的值给角色。用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。

在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。

例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相关的用法说明的集合，并且一个说明（scenario）是用例的实例。这种关系就像是类和对象的关系。在用例中，一个说明被视为事件的普通过程（normal course），也叫作主过程，基本过程，普通流，或“满意之路” （happy path）。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种交互结束时，执行者也达到了预期的目的。在用例中的其它说明可以描述为可选过程（alternative coruse）。可选过程也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。

在交互序列中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。角色类和角色实例软件产品最终是给一些用户来使用的，而用户之间的差异是非常大的。造成差异的原因包括了对计算机的认知程度的不同，使用习惯的不同，在软件目标组织中所处的地位不同，地理位置不同，业务熟练程度不同。不同的用户都有自己一系列的功能需和非功能需。对电脑熟练程度不同的人可能就会有不同的要，熟练程度低的用户可能希望有一个友好的界面，熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。考虑到用户的差异性，将用户分类并研究用户类的行为特征是非常有必要的。所以在做具体的需之前，先将用户分局行为和特点进行分类，对于研究、收集用户的需是非常有帮助的。

可以利用一个简单的表格列出一些原始的分类，然后不断的完善这个表格。确认你的分类之间没有交集。并充分描述用户分类的行为，目的，要等。在企业分析中，比较常见的分类可能包括，供应商，客户，部门等。就像C++中的类和对象一样，我们把分析出的用户分类称为“角色类”，把实际的用户称为“角色实例”。在得到用户分类之后，最重要的就是要选出用户代表，用户代表不仅仅是在需阶段中参与项目，还必须对项目的全过程负责。用户代表能够代表用户分类的需。抓住用户代表的需就大致把握住了用户类的需。当然，需分析还是需要在用户中做大规模的调查的，只是要把重点放在用户代表上。确保和用户直接进行沟通！大家有没有玩过传话的游戏，可能看过。

一群人排成一列，一句话从排头挨个向后传，到最后，那句话已经是面目全非了。所以，一定要保证项目组能够直接和用户接触。对于和用户直接沟通这一点，一般的针对特定企业的应用系统当然是不成问题，可是如果是开...

如何才能把软件需分析做好

我的第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，听说这个项目之前是东软做的。当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。多么惨痛的教训啊！我常常听到网友抱怨客户总是对需改来改去，但客户对需改来改去的真正原因是什么呢？当我们对客户的需没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。

如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需。当我们提出更加合理的方案时，客户是乐于接... 我的第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，听说这个项目之前是东软做的。当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。

最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。多么惨痛的教训啊！我常常听到网友抱怨客户总是对需改来改去，但客户对需改来改去的真正原因是什么呢？当我们对客户的需没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需。

当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。

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

项目需分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，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）这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导...

软件需分析的作用及如何进行需分析

软件需是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需精确化、完全化，最终形成需规格说明，这一系列的活动即构成软件开发生命周期的需分析阶段。需分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。需工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需分析很少受到重视。后来软件开发引入了生命周期的概念，需分析成为其第一阶段。随着软件系统规模的扩大，需分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需工程（requirementengineering,RE）。进入90年代以来，需工程成为研究的热点之一。从1993年起每两年举办一次需工程国际研讨会（ISRE），自1994年起每两年举办一次需工程国际会议（ICRE），在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。一些关于需工程的工作小组也相继成立，如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，并开始开展工作。需工程是指应用已证实有效的技术、方法进行需分析，确定客户需，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需文档，并对用户不断变化的需演进给予支持。RE可分为系统需工程（如果是针对由软硬件共同组成的整个系统）和软件需工程（如果仅是专门针对纯软件部分）。软件需工程是一门分析并记录软件需的学科，它把系统需分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需转换成软件的需描述和一些性能参数。需工程是一个不断反复的需定义、文档记录、需演进的过程，并最终在验证的基础上冻结需。80年代，HerbKrasner定义了需工程的五阶段生命周期：需定义和分析、需决策、形成需规格、需实现与验证、需演进管理。近来，MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证。综合了几种观点，可以把需工程的活动划分为以下5个独立的阶段：

（1）需获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需；

（2）需建模：为最终用户所看到的系统建立一个概念模型，作为对需的抽象描述，并尽可能多的捕获现实世界的语义；

（3）形成需规格：生成需模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

（4）需验证：以需规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需规格的正确性和可行性；

（5）需管理：支持系统的需演进，如需变化和可跟踪性问题。