1.需求工作涉及到哪些内容

　　首先需求包括了产品需求，用户需求，软件需求。产品需求关注的是产品的标准化和通用化，会对收集到的用户需求进行分类和优化，结合业界标准系统模型进行抽象并通用化。用户需求反映的是用户面临的问题域，根据问题域用户期望的能够达到的解决效果；而对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。

　　需求工作涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型。对于基于面向对象的开发方法则涉及到业务用例，系统用例(涉众，基本流，扩展流，业务规则，界面，操作)等诸多内容。需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。

　　在我们需求分析和开发中，容易忽视的主要有两点，一个是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。CMMI把需求管理放到2级，需求开发放到3级，实际上真正的提高需求人员的需求分析和开发能力才是解决需求问题之道。需求分析开发做不好，需求变更或追踪管的再好也没有用处，在这点上一定不能本末倒置。

　　2.做好需求分析需要具备哪些知识

　　需求分析岗位主要承担的是系统分析员的工作，做需求分析的人员要有软件工程基础知识的积累，而且好有一定的软件开发经验积累。自己做过设计开发工作的才能够体会到如何才能够把系统做好，如何更好的把软件需求和后续实现更好的衔接起来。有一本《软件需求》的书讲的很系统，从事需求工作的都值得仔细阅读。对于采用面向对象的需求开发和分析方法的，一定要熟悉RUP统一过程和用例分析和建模。

　　对于管理软件都离不开其涉及到的业务领域，因此要做好需求分析工作必须要熟悉管理软件所涉及到的业务领域，对业务领域相关的标准模型进行分析和研究，对业界的一些标准和佳实践进行熟悉。比如做供应链管理系统和软件应该熟悉业界标准的SCOR模型，做ERP的应该结合现在的业界比较大的厂商的ERP产品进行学习，对于研发管理系统可以结合PACE和IPD等等。只有熟悉了业务领域才可能在需求调研和分析的时候提供很多有建设性的意见，或者说需求分析人员不是被用户牵着走，而是真正的可以引导用户。

　　3.需求分析的步骤和输出有哪些

　　开始首先是需求的收集，需求收集可以通过调查表，访谈，业界标准，会议讨论沟通等多种方式进行。需求收集第一是要能够很好的描述现状，第二是要搞清楚用户的期望。同时一定要弱化用户期望系统怎么做，因为用户并不熟悉系统实现和内部原理，我们的软件需求不仅仅考虑的是功能的实现，还需要考虑需求复用，业务抽象，可扩展和配置等多方面的问题。

　　收集回来的需求需要开始进行分析工作，分析包括了动态行为分析和静态数据分析。动态行为分析涉及到用例分析，业务流程和活动输入输出的分析，数据流分析，业务操作规则分析。静态数据分析设计到业务对象建模，数据字典，组织结构，权限等分析。在这一个阶段的重点是需求的系统化和结构化，好要体现到规范的文档中。在软件开发过程中我们强调的需要文档化的输出是需求文档和总体设计方案文档。

　　需求分析阶段还有一个重点的产出是原型和DEMO，为了更好的和用户沟通并挖掘需求，我们需要将我们理解后的想法更加形象的讲述给用户，所以原型显得额外重要。不管是否是抛弃的原型，都需要客户看到的原型和终实现的系统基本一致，因此原型开发需要投入一定的时间，并根据客户反馈的信息不断修正。在原型中多投入些时间，会多减少一份后期需求变更引起的返工时间。软件原型是降低需求变更风险的有效方法。

　　4.需求的抽象和建模体现在哪些方面

　　首先要理解需求分析和设计的目的在于满足现状并适应变化。要想适应变化则业务建模和需求抽象是必须的。当我们了解到业务的组织结构和流程经常面临变动和调整的时候，我们需要考虑引入标准的组织结构模型，权限模型和工作流模型。这些模型的引入使业务和需求的变动变化为通过系统的灵活配置来适应。软件系统要适应变化不是从设计阶段开始的，而是我们的软件需求本身需要适应变化。

　　需求的抽象包括了对业务对象模型的抽象，对业务规则的抽象，对流程的抽象。其中重要的是由业务对象抽象形成的概念模型，由流程抽象形成的数据交互模型。对于一些快速软件开发平台理解到的对象建模，流程建模，组织结构和权限建模，业务规则建模，BPEL业务流程编排恰好是需求抽象的主要内容。

　　要做好需求抽象必须具备两方面的知识，第一是真正的对所涉及到的业务领域及其标准模型足够理解，其二是对软件系统分析和架构设计有较多的经验积累。只有同时具备这两方面知识才能够做好需求建模工作。

　　5.需求的验证和确认包括哪些事情

　　我们可以再简单理解下验证和确认的区别，对于判断终开发出来的系统是否和用户想要的东西是一致的过程叫确认，对于你理解和描述的需求和我当初的想法是否是一致的过程叫验证。需求的验证包括了很多的内容，涉及到软件开发中上下游相关人员的参与。首先你结构和文档化后的需求需要用户来验证是否和他们的想法是一致的，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。对于后续设计开发阶段的人员也需要对需求进行评审以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中引入了较多的易用，较好，应该等不确定和不可测试的词语。对于大型的软件项目，如果有专门的产品化标准和UI组的话，还需要对需求的易用性和产品交互等方面进行评估，以评价整个软件系统的产品化。

　　确认主要是软件系统已经开发完成后交付给用户后验收的时候，用户确认系统是否实现了当初的需求。为了保证确认过程的顺利，必须重视需求验证的过程，需求验证不仅仅是需求阶段对需求文档的评审，还需要关注设计，开发等各阶段对需求的实现情况的验证。