软件开发需求开发与管理过程流程全套.docx

《软件开发需求开发与管理过程流程全套.docx》由会员分享，可在线阅读，更多相关《软件开发需求开发与管理过程流程全套.docx（22页珍藏版）》请在优知文库上搜索。

1、软件开发需求开发与管理过程流程1.前言1.1意图和价值意图：明确需求,确保利益相关者的共同理解,并调整需求、计划和工作产品。价值：确保客户的需求和期望得到满足。1.2适用范围本过程文档是项目经理需求开发人员（包括:售前市场人员、需求调研人员等）执行需求开发与管理过程活动的依据和指导。本过程适用于公司所有软件项目，且贯穿于整个生命周期。1.3名词术语2用户需求是用户对要建立的系统的要求描述,它主要说明用户要做什么、想做什么的问题。2软件需求也叫产品需求，是软件产品能否满足用户需求的要求描述，它主要说明软件产品能做什么、不能做什么的问题。2.过程定义2.1角色和职责角色职责描述高层经1.评审、批准

2、用户需求、产品需求等过程产品，并理参与本过程域重要的活动；2.解决在实施本过程域中所遇到的无法解决的问题项目经1.为需求开发工作提供各种必要的环境和条件；理2.制订需求开发计划，并跟踪维护该计划；3.负责联系用户和需求人员进行需求开发工作；4.参与评审本过程域的工作产品；5.完成或协助完成本过程域的工作产品；6.对需求进行变更管理、跟踪控制；7.向高层经理报告本过程域的实施情况；需求开1.负责对市场、客户的需求调研；发人员2.收集、分析、细化、导出和描述用户需要、期望、约束和接口，并把它们转换成用户需求；3.完成需求开发，编写用户需求说明书和产品需求规格说明书等需求文档；4负责对需求的后期跟踪

3、；5.负责执行需求的变更。美工1.根据用户需求和产品需求，在需求开发人员的指导下，完成开发原型Demo的制作；2.和需求开发人员一起，向用户进行开发原型Demo演示。项目组参加需求开发与管理活动的评审。成员客户1.配合并参与需求的调研活动；2.评审并确认需求开发的所有文档；3.对用户需求说明书和产品需求规格说明书、需求Demo等进行确认；CCB1.评审需求文档是否满足了用户的真实意愿。2.审批需求变更申请。CM1.为评审后的需求文档进行配置管理。QA1.检查和监督需求管理活动的有效性和一致性。2.将检查出来的问题及时通报给项目经理及项目组成员，并跟踪问题直到关闭。2.2入口准则2需求开发人员已

4、经确定；2初步的项目计划已经通过评审。2.3输入2初步的项目计划；2项目合同；2技术解决方案；2客户原始需求文档。2.4过程活动需求阶段包括需求开发和需求管理两个过程活动。2需求开发过程需求开发过程是获取用户需求并对用户需求进行分析整理形成软件需求的过程。需求开发过程可以包括用户需求调研、用户需求分析、软件需求定义和软件需求评审四个过程，也可以根据具体情况对该过程进行裁减。需求开发的结果文档包括用户需求类文档、软件需求类文档、有时为了满足软件产品前期设计的需要，也会制作形成业务模型、数据字典、系统开发原型（Demo）文档等。所有的需求文档经过用户和开发方双方评审认可并签字后，形成项目的需求基线

5、。2需求管理过程需求管理是在需求文档基线化后,对需求实现的跟踪以及当需求发生变更时，对需求变更进行控制和管理的过程。需求管理包括变更控制、版本控制、需求跟踪过程。需求管理同时包括变更的需求及相关需求之间的关系管理。2.4.1需求开发过程2.4.1.1用户需求调研在项目正式立项后，项目经理组建需求开发团队，需求开发人员根据初步项目计划、客户原始需求文档（包括：市场人员从客户那里得到的初步需求文档，投标文件中定义的技术方案内容等），确定需求调研时间及需求获取相关干系人，并将此活动更新到干系人计划中，同时制定出需求调研计划。在识别需求获取干系人时，需求开发人员需考虑以下几准则：I相关干系人要具备足够

6、的业务经验。I相关干系人要具有较强的表达能力。I相关干系人至少具备初级的计算机水平。在需求开发人员开始进行用户需求调研之前，要进行充分的事前准备。需要准备的工作包括：I需求开发人员要提前了解该行业的标准、相关文件、公司规章制度等。I需求开发人员从组织资产库中寻找类似项目的需求资料，对相关需求资料有一个深入了解，以便迅速了解可以重用的业务需求内容，为与客户深入、专业的需求沟通打下基础。I需求开发人员确定需求调研方式，具体方式包括：客户主动提供的需求说明文档，与用户面谈或电话访谈或会议访谈、参观用户的工作流程、向用户群体发调查问卷、与同行专家交谈、分析已经存在的同类软件产品等。I需求开发人员根据选

7、定的调研方式,准备好用户需求调查单。需求开发人员根据需求调研计划开展调研工作。调研工作需要需求开发人员和用户协同完成。调研中需求调研人员要随时做好记录，事后填写好用户需求调查单，作为原始用户需求，有进行组织会议访谈的要填写需求访谈会议纪要。需求开发人员根据需求调研的访谈成果，对用户的原始需求进行分析整理，提取需求的精华，对用户需求进行归纳总结，把相同的需求进行归类，把文档尽可能的用用户容易理解的语言撰写（包括：用例图/用例简述/用例规约描述等）。按照归纳总结的用户需求点，需求开发人员编写用户需求说明书。用户需求说明书的主要内容包括：2需求产生的背景2需求目标要求2需求内容范围2用户角色2功能性

8、需求的描述2限制条件2非功能性要求等。用户需求调杳单、用户需求说明书编写完成后，需要得到用户和开发方双方的共同确认,确认的方式开始是正式的、也可以是非正式的。一般通过内/外部评审会议、用户签字或非正式的其他方式（如确认邮件等）确认即可。用户需求确认后，需求开发人员创建需求跟踪矩阵，并将用户需求项填入需求跟踪矩阵中。用户需求调研活动可参考需求调研指南O2.4.L2用户需求分析用户需求分析的目的是为了明确用户需求的具体细节以及软件产品实现的可行性，把用户需求合理的转化成软件产品需求。用户需求分析的主要内容包括：2分析用户需求的实现可行性在允许的成本、性能要求下，需求开发人员要分析每项用户需求进行软

9、件产品实现的可行性，同时明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍等。2确定需求的优先级别应用需求分析方法来确定系统特性或单项需求实现的优先级别。以优先级为基础确定软件产品将包括哪些特性或哪类需求。2建立业务模型（可选）有时为了满足软件产品前期设计的需要，或者需求开发人员对比较复杂的用户需求难以理解时，一般对需求进行建模分析，以帮助软件开发人员更好地理解需求。根据用户需求分析得到的需求描述，借助于需求分析工具建立相应的业务模型。根据项目的实际情况,选择不同的建模方法。如：采用结构化的需求分析方法或采用面向对象的需求分析方法，通过UML方法来进行创建业务模型

10、。建议使用RationalRose、MSVisio等建模工具进行需求的建模分析，通过分析系统的功能模型、结构模型和行为模型，进行系统建模。建模的过程包括系统功能建模、系统数据建模和体系结构建模，在需求开发阶段应至少完成功能建模。功能建模的方式包括静态建模和动态建模。静态建模要求画出用例图、主要的类图和对象图，动态建模要求画出主要的状态图、时序图、协作图和活动图等。另外在用例图中，需标明每个用例的业务描述、业务数据、业务流程、入口条件、输出结果、异常处理等要素。2建立数据字典（可选）数据字典是用户需求中的各类实体（业务对象、数据对象、业务流程对象等）的专业化名称解释，它能够保证用户和开发方对需求

11、沟通、理解的一致性，同时也是后续进行数据库对象设计的最重要依据之一。2.4.1.3产品需求定义首先，需求开发人员进行产品需求定义，把用户需求向软件需求转化前，要确认用户需求说明书已经通过了用户确认。由需求开发人员根据用户需求说明书，对用户需求进行更加详细的专业化定义，形成用户需求到软件需求的映射。完成产品需求规格说明书的编写。当需求开发人员或用户不能确定需求时，可以考虑实现一个系统开发原型（DEMO）,这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。系统如果建立原型，则需向用户演示原型，或请用

12、户试用原型系统，记录使用中的问题并修订原型直至客户满意。原型的格式和内容由项目经理、美工以及客户协商自定。由于用户需求说明书与产品需求规格说明书在内容上存在很多的共同之处，有时为了项目的具体需要，两个文档可以考虑合并成一个文档。但合并成一个文档时需注意：2要明确用户需求和产品需求之间的对应关系，建立起用户需求和产品需求之间的映射表（通过映射表可以建立起用户需求和产品需求之间的需求跟踪矩阵）；2用户需求和产品需求之间的对应关系，特别是软件产品无法实现的用户需求内容，要在合并文档中明确记录，并向用户详细说明情况，取得双方的沟通一致；2合并的文档内容要用用户易于理解的语言进行表述，切勿使用软件专业性

13、强而用户无法理解或理解有歧义的语言，一般考虑使用用例图/用例规约的方式。2合并的文档不仅仅给用户看,还要满足软件产品后续设计的需要,所以内容的描述尽可能正确、完整、易于理解、无歧义。2.4.L4产品需求评审产品需求评审的目的是为了确保用户和开发方双方对需求的理解一致，消除歧义，并取得双方之间的共同认可。评审时由项目经理邀请客户、相关干系人参加,要对产品需求规格说明书中的内容逐条逐项进行验证，如果发现存在问题，则由需求开发人员继续调研，加以修改，直至评审通过。软件需求评审要注意如下几点：2明确说明用户需求和软件产品需求之间的映射关系，对软件产品不能实现或暂时无法实现的用户需求，需求开发人员要向用

14、户详细说明原因，取得用户的认可。2可以通过演示系统原型（Demo）方式，直观形象的向用户进行软件产品需求的演示，取得用户的认可。2软件需求确认不同于用户需求的确认，用户需求的确认可以是非正式（如邮件确认），软件产品需求确认必须是正式的，产品需求规格说明书必须得到用户的书面确认。产品需求确认后,形成正式的软件产品需求基线，作为后续需求变更控制的基础。2.4.2需求管理过程需求管理过程包括：需求的变更控制、需求的实现跟踪两个方面。软件需求包括3个不同的层次-业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。需求的分类是软件需求阶段必不可少的工作，它可以指导开发人员理解不同的行业的

15、业务、了解用户的真实需求，清楚这些之后确立好功能项；当开发人员对整体需求有了明确的目标后，就可以按部就班快速有效地进行功能项开发，一般就不会背离系统开发需求的初衷。1、业务需求业务需求(Businessrequirement)表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围(visionandscope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(projectcharter或marketrequirement)文档。2、用户需求用户需求(userrequirement)描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件-响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。3、功能需求功能需求(functionalrequirement)规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有