什么是需求工程过程求大神帮助

1. 什么是需求工程过程求大神帮助

需求工程无疑是当前软件工程中的关键问题，但又是软件工程中最复杂的过程之一。完整的软件需求工程过程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求分析、编写需求规格说明书（SRS）、需求验证四个阶段，需求管理则主要包括需求基线的建立、需求变更控制以及需求跟踪等活动。需求获取是通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求 ；需求分析是为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述;由需求模型构件生成精确的形式化的描述，即需求规格说明书，它将作为用户和开发者之间的一致协议;需求分析的结果应该通过评审、测试等手段验证它的正确性、完整性和一致性，这就是需求验证。贯穿于整个过程中，需求管理中最基本的任务则是明确需求，并使所有相关人员达成共识 ；建立需求跟踪能力联系链，确保所有用户需求被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。  需求工程需要各类人员的参与，如领域专家、最终用户、系统投资人、需求分析员、系统开发人员等等，以不同的着眼点和不同的知识背景，获得对软件需求的全面理解。需求工程最大的难度就体现在全方位需求的获取以及非功能性需求与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性，而非功能性需求往往又决定了对软件产品的质量要求。因此，非功能性需求和质量特性的分析模型有待深层次的研究。  CMM3——软件产品工程体现TQM的过程控制

2. 简述需求文档的构成

 UML统一建模语言建立了一套采用图解需求的标准方法，用它来解析和呈现业务需求，就能事半功倍～接下来详细说下需求文档中用图说到的事儿。
   先简单讲讲画流程图的需要知道的基本元素
                                                                                   由于大家对这个超市结账的流程都比较熟悉，可以脑补出以上步骤所对应的角色，但是面对千千万万的业务场景，可能用以上简单的步骤图就描述不出来了，接下来简单介绍可以用到的泳道图。
   在描述流程中活动的时候，可以使用泳道来区分角色即“谁做的什么事情”。如图：
                                           产品经理在了解业务的流程后，为了便于后续的产品设计工作，还需要关注业务中的数据关系，接下来简单讲下可以用到的实体关系图。
   实体关系图，又称做ER图，用来描述实体间的数据关系。
                                           以上ER图（只画了一部分实体关系，像账单等实体省略掉了）表示：
   产品经理在需求分析时，还需要理清每个实体的属性，也就是对于一个实体【顾客】，它有哪些数据属性，比如顾客的手机号、性别、年龄、是否是VIP等等。B端产品经理经常会设计配置后台等产品，用户在配置后台进行创建、删除、编辑、搜索等操作就是对数据的CRUD（增删改查），理清了这些数据属性，我们可以试着从数据角度进行需求的探索，即对需求进行查漏补缺。    举个🌰-账单实体 ：
   数据流图可以呈现数据的扭转，用户在系统中的每一步操作可以说都存在数据的输入和输出，了解这些不仅能让产品经理自身更清楚产品的功能和范围，还能跟开发更好地沟通。完整的数据流图难度较大，一般不做要求，有兴趣的可以去了解 数据流图 。
   概括性地描述这是一件什么样的事情以及要实现的目标，这可能是产品的名称也可能是项目的名称。
   背景主要是说明为什么要做这个需求，通常是说明现状及现状带来的问题。
   讲清楚做了这个需求后预计达到的目标或是收益，比如能赚多少钱、能节省多少人力等等
   在这里可以把需求以列表的方式概括性展示出来，可以让团队成员大概知道这些需求包含哪些内容，便于后续评估工作量。
   这里需要放上实体关系图，以及每个实体的属性，有助于理清业务概念，也可以帮助开发拿到需求后设计数据结构。
   这里需要放上流程图和数据流图，用于描述业务流程和数据扭转。
   这是文档的核心部分，在这个阶段描述需求时，建议不要描述界面相关的内容，避免增加文档的复杂性，以下是对一个需求/用例的描述。
   除了功能性的需求，非功能需求是用户指对产品的期望，举例说明：

3. 下列关于工程项目资源需求分析的表述中，正确的有( )。

A,C,D,E
答案解析：
编制资源消耗计划首先要确定需要哪些资源以及需要的数量及使用时间，即进行资源需求分析。①在工程项目决策阶段，需要咨询工程师牵头，组织各专业技术人员对工程项目进行全面、系统的分析'为决策者提供决策的依据；②在工程项目准备阶段，要围绕工程项目的设计进行大量的工作，需要建筑、结构、水、电、暖等多专业工程师的参与，同时需要电脑（含软件）、绘图仪等设备；③工程项目实施阶段对管理人员、技术人员特别是一般劳动力的需求很多，对材料和设备的需求就更大，而竣工阶段对资源的需求则非常少。

4. 下列关于工程项目资源需求分析的表述中，正确的是( )。

B,D
答案解析：
在工程项目决策阶段，需要咨询工程师牵头，组织各专业技术人员对工程项目进行全面、系统的分析，为决策者提供决策的依据；在工程项目准备阶段，要围绕工程项目的设计进行大量的工作，需要建筑、结构、水、电、暖等多专业工程师的参与，同时需要电脑(含软件)、绘图仪等设备；工程项目施工阶段对管理人员、技术人员特别是一般劳动力的需求很大，对材料和设备的需求就更大。

5. 需求分析阶段产生的主要文档是什么

需求分析阶段产生的主要文档是需求规格说明书。
需求分析阶段的工作可以概括为：需求获取、需求分析、编写需求规格说明书、需求评审四个方面。软件需求规格说明书是需求分析阶段的最后成果，是软件开发的重要文档之一。
当我们做一个项目时，可能客户口头告诉你他想要做一个什么东西，或者给了你一些文档告诉你这就是需求。就根据几句口头讲述，或者一些文档，很难知道到底具体需要做什么。这时候就要对需求进行挖掘，以得到功能列表，或者用例图。这时候交流是非常重要的。
通过不断地与客户进行交流，将用例详细化，也不必要追求完整的功能或者用例。通过一次次的交流，不断将功能列表完善。

目标：
需求分析需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。
需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

6. 需求工程过程的工作基础存在哪些？他的工作成果有哪些

　需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档 (System Requirement Specification); 2.DRM 文档；3.Acceptance Plan.

　　从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

　　狭义上理解：需求分析指需求的分析、定义过程。

7. 需求工程的核心问题是需求分析对不对

需求工程的重要性主要表现在: 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解， 增强了项目涉众对需求( 尤其是复杂需求) 的掌握 ; 增进了项目涉众之间的交流， 减少了可能的误解和交流偏差; 需求管理能够更加有效地处理需求变更，提高了生产效率; 需求跟踪信息能够更加准确地反映项目的进展情况，以便进行更好的项目决策; 使得项目涉众认识到需求在项目工作中的重要性， 使得需求的作用得到重视和有效发挥。良好的需求分析和管理工作， 才能把系统的功能描述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础。

需求工程的内容

需求获取阶段
需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了 3 个至关重要的因素：应搜集什么信息；从什么来源中搜集信息；用什么机制或技术搜集信息。再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获
取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。

需求分析阶段
需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息的基础上，结合软、硬件实现方案，并做出初步的系统原型给承建方做演示。承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。同时，用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。