6.需求的抽象和建模体现在哪些方面？
首先要理解需求分析和设计的目的在于满足现状并适应变化。要想适应变化则业务建模和需求抽象就是必须的。当我们了解到业务的组织结构和流程经常面临变动和调整的时候，我们就需要考虑引入标准的组织结构模型，权限模型和工作流模型。这些模型的引入使业务和需求的变动变化为通过系统的灵活配置来适应。软件系统要适应变化不是从设计阶段开始的，而是我们的软件需求本身就需要适应变化。
需求的抽象包括了对业务对象模型的抽象，对业务规则的抽象，对流程的抽象。其中最重要的就是由业务对象抽象形成的概念模型，由流程抽象形成的数据交互模型。对于一些快速软件开发平台理解到的对象建模，流程建模，组织结构和权限建模，业务规则建模，BPEL业务流程编排恰好就是需求抽象的最主要内容。
要做好需求抽象必须具备两方面的知识，第一是真正的对所涉及到的业务领域及其标准模型足够理解，其二是对软件系统分析和架构设计有较多的经验积累。只有同时具备这两方面知识才能够做好需求建模工作。
7.需求变更管理重要性体现在哪里?有哪些具体的内容
户不断的提交需求修改，项目进度无任何保证不断延期;由于一次需求的修改导致原来本来稳定的系统出现各种原来没有想到的错误和异常;这些都是需求管理存在缺陷的表象。需求管理的重要性就体现到项目计划的严肃性和可执行性，以保证项目目标的实现。通过引入了需求变更管理后，使软件需求文档成为一份大家都共同承诺和作为依据参考的文档，这个文档需要在设计，开发，测试等多种角色之间充分传递和共享。另外通过需求管理工作，使每个人意识到变更对项目的影响和变更的代价，反向去促进需求开发质量的提高。
需求变更管理包括了变更请求的提出，CBB委员会对需求进行影响分析确认是否变更，设计开发负责人确认需求变更将影响到的模块和代码和具体修改方法，开发人员对变更进行修改和测试，最后再有变更请求人对需求变更满足情况进行验证。对于变更的影响分析一般需要项目组的开发负责人进行，大型项目可以依靠需求管理中建立的需求追踪进行分析，但根据实践需求追踪在影响分析中的作用还不明显。
8.需求是否必须要文档化，其意义体现在哪里?
做人员多方沟通的基础，使大家对需求有一致的理解并依据该文档开展各项工作。即时是对于敏捷软件开发，我们也需要对用例场景描述，CRC卡片等文档化下来以方便沟通。
再次强调沟通，特别是面对面的沟通是信息传递最高效方式，但是当一个信息是需要在软件开发整个生命周期的不同阶段，由不同角色人员多次使用的时候，就必须文档化。而需求文档恰好属于这种类型。
9.需求优先级的作用，如何评估需求优先级?
需求优先级的作用在于项目管理和用户满意度提升的需要。一个系统上线后经常出现情况就是往往经常使用的功能都集中在20%的功能上很多功能使用很少。需求优先级让我们更好的把握重点和分配资源，真正的把20%最重要的需求，经常使用的需求做好做精，只有这样才能够真正的提高用户满意度和达到项目目标。
需求优先级对于用户往往最有发言权，但当一个系统涉及到多个业务部门和组织结构的时候，难免出现各个用户都站在自己的立场来看待需求的优先级和紧急程度的问题。但是一个需求究竟对效率提升，成本的减少，相关周期的缩短起到了多大的贡献和作用却没有衡量。因此对需求优先级的评估应该考虑引入价值工程的概念，一个需求的优先程度应该体现在需求实现后能够产生的价值和节约的成本。
10.中小型软件开发团队需求开发和管理工作的重点在哪里？
对于中小型的项目团队一定要使用轻量级的方法论和过程，过程是为了实现目标服务的，过程的目的是为了解决现在的问题和可能的问题。不在这个范围内做的过程，规则或工作都不会产生价值和意义。
对于中小型团队首先是要意识到需求工作的重要性，制定需求文档和DEMO界面规范，对需求进行文档化和结构化。其次是对开发完成的需求需要得到用户，实现人员，测试等多方的评审和认可。最后是需求文档化后该工件需要通过各种配置管理工具进行管理，需求完成后及时归档和受控，需求的变更需要受到管理而不是随意的。