需求开发及管理

1、需求开发及管理第六章 需求开发及管理CMMI对应实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 3需求的定义在IEEE软件工程标准词汇表(1997年)中定义软件需求为1.用户解决问题或达到目标所需的条件或能力。 2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 3.一种反映上面(1)或(2)所描述的条件或能力的文档说明。 通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求管理（REQM）目的：管理项目产品和产品组件的需求，

2、并识别需求与项目计划和工作产品之间的不一致项需求包括：技术性需求、非技术性需求、功能需求、非功能需求，来自客户的需求、来自项目组内部的需求等。项目组应该管理需求变更（当出现变更时），并且识别在项目计划、工作产品和需求之间发生的不一致项。作为需求管理的一个部分，需求变更及其理由应填入记录文档，并且在最初需求与产品和产品组件的所有需求之间维持双向可追溯性。SG 1 Manage Requirements（管理需求），对需求进行管理，并识别需求与项目计划和工作产品之间的不一致项。SP 1.1 Obtain an Understanding of Requirements（取得对需求的理解）SP 1.

3、2 Obtain Commitment to Requirements（取得对需求的承诺）SP 1.3 Manage Requirements Changes（管理需求变更）SP 1.4 Maintain Bidirectional Traceability of Requirements（维护对需求的双向跟踪）SP 1.5 Identify Inconsistencies Between Project Work and Requirements（识别项目工作与需求之间的不一致项）需求管理（REQM）需求开发（RD）目的：产生并分析用户、产品及产品组件需求。需求作为设计的基础，在开发过程中，

4、需要收集软件需求、客户或其他利益同担者（stakeholder，或译成干系人）的需要，对所有可能的需求及需要进行分析，并对分析的结果进行评审，最终针对需求达成一致。共计三类需求，分别是客户需求、产品需求、产品组件需求，整体来说，这些需求侧重于相关干系人（含客户）的需要，包括那些与各个产品生命周期（比如，接受测试准则）及产品属性（比如，安全性、可靠性、可维护性）有关的需要。需求还侧重于由于解决方案设计的选择而导致的约束（比如，与第三方外购商业软件集成）。SG 1 Develop Customer Requirements（开发客户需求），收集干系人（包括客户、最终用户、供应商、构造人员、测试人员

5、、设备制造商、后勤支持人员等）的需要、期望、约束、接口，并把他们转化为客户需求。SP 1.1 Elicit Needs（引出客户需要），引出在产品生命周期内所有阶段干系人的需要、期望、约束和接口。SP 1.2 Develop the Customer Requirements（开发客户需求），把干系人的需要、期望、约束和接口转化为客户需求。RD（一）RD（二）SG 2 Develop Product Requirements（开发产品需求），对客户需求细化及描述以开发为产品及产品组件需求。SP 2.1 Establish Product and Product Component Requir

6、ements（建立产品和产品组件需求），基于客户需求来建立和维护产品及产品组件需求。SP 2.2 Allocate Product Component Requirements（分配产品组件需求），为每个产品组件分配需求。SP 2.3 Identify Interface Requirements（识别接口需求），识别功能（或对象）之间的接口，功能（或对象）之间的接口可能会决定在TS过程域中选择不同的解决方案。RD（三）SG 3 Analyze and Validate Requirements（分析并确认需求），针对用户预期的环境下分析和验证需求。SP 3.1 Establish Opera

7、tional Concepts and Scenarios（建立系统操作概念及场景）SP 3.2 Establish a Definition of Required Functionality（建立功能需求的定义）SP 3.3 Analyze Requirements（分析需求），分析需求以保证他们的必要性和充分性。SP 3.4 Analyze Requirements to Achieve Balance（分析需求以达到平衡），分析需求在干系人需要和约束之间进行平衡。SP 3.5 Validate Requirements（确认需求），确认需求以保证终产品将会在用户环境中按照预期运行。第六

8、章 需求开发及管理CMMI对应实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 需求来源直接来自机构外部（即合同甲方），此时，给定需求就是以委托方式或合作方式提交的任务书；或者是通过项目投标最终以合同形式确定的用户需求，其载体就是投标书、合同及其技术附件以及合同签订后编写的软件需求文档，当然还应包括项目开始后几乎难以避免的变更需求。也可以间接的来自外部机构，此时，公司内部不同部门或公司外部的委托方或合作方承接的整个集成项目分配给项目组的软件开发任务就是给定需求。来自部门内部的新产品开发，此时给定需求及其载体就是新产品可行性研究报告、软件需求文档（初稿）以及相应的软件立

9、项审批表。来自已发布产品或已提交项目的最终用户，此时，不同的最终用户或同一个最终用户在不同时间、不可预料地提出的产品的每一个缺陷报告或个性化修改要求都是给定需求，其载体可能是用户的传真或电子邮件，也可能是维护部门的电话记录，还可能是市场人员、工程人员的间接反映。需求开发及管理目的目的:在获得正确的用户需求基础上，经过分析和定义，最终生成项目的用户需求说明书和软件需求规格说明书。借助需求管理寻求客户与开发方之间对需求的共同理解，控制需求的变更，维护需求与后续工作产品之间的一致性。需求开发及管理内容将分配给软件的系统需求文档化；进行软件需求分析及评审并建立软件需求基线；管理和控制需求基线及需求变更

10、，保持软件需求和项目计划、工作产品及过程活动的一致性。在需求开发及管理准则通过整理获得需求，从而明确需求来源、确认需求类型（功能需求或非功能需求）、明确需求的优先级，形成用户需求说明书，并得到用户的确认。对给定的用户需求说明书进行分析以文档化的形式编制软件需求规格说明书软件需求规格说明书中每一项需求的描述，都必须确保是正确、最新、完备、必要、可验证、可追踪和可测试的。软件需求规格说明书必须通过相关组的评审，相关组包括：开发组、测试组、质量保证组、配置管理组、文档组及个人。只有相关组审批、确认后的软件需求规格说明书 ，才能作为项目开发计划以及后续项目工程和管理活动的基础。经过评审确认的软件需求规

11、格说明书的任何变更，都应得到控制和管理，一旦需求发生变更，项目计划、过程活动、工作产品等要随之变更与需求变更保持一致，并重新提交相关组和个人复审。第六章 需求开发及管理CMMI对应实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 需求开发及管理流程需求开发及管理活动主要分为四个阶段，分别是：1.准备阶段在项目初步计划书里明确需求收集及分析的进度安排及人员安排。2.需求收集阶段立项阶段用户需求收集不充分或有不明确之处，继续进行用户需求收集，并转化为产品需求。3.需求分析阶段对用户需求列表或/和用户需求说明书中的需求进行分析，给出详细的软件需求规格说明书。4.需求管理评审

12、通过的软件需求规格说明书，纳入基线，严格执行需求变更管理，对需求跟踪矩阵进行管理，要保证需求的双向跟踪。工作流程图 第六章 需求开发及管理CMMI对应实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 系统工程与需求工程的区别为了了解软件所处的外部“系统”，必须识别硬件、软件、人员、数据库、流程和其他系统要素的角色，对有效的需求进行提取、分析、说明、建模、确认和管理，这些是系统工程的基础。切忌“只见树木，不见森林”，这里的“森林”是系统，而树木是实现系统所需的技术要素（包括软件）。如果在理解系统之前就匆忙构造技术要素，毫无疑问将犯错误并让你的客户失望。在关注树木之前，必

13、须先了解森林。系统工程师通过和客户、未来用户以及其他共利益者一起工作以理解系统需求。需求工程是帮助软件工程师更好地理解将要解决的问题。需求工程首先定义将要解决的问题范围和性质；然后是引导、帮助客户定义需要什么；接下来是精练需求，精确定义和修改基本需求。需求来源1.访问并与有潜力的用户探讨；2.把对目前的或竞争产品的描述写成文档；3.用户招标文件；4.对当前系统的问题报告和增强要求；5.市场调查和用户问卷调查；6.观察正在工作的用户；7.用户任务的内容分析开发具体的情节或活动顺序，确定用户利用系统需要完成的任务，由此可以获得用户用于处理任务的必要功能需求。需求获取流程图合同类项目1.采取与用户会

14、谈、现场调查等方法详细记录用户给定需求，形成需求调研单，然后进行需求风险识别、分类、筛选、优先排序，整理形成用户需求列表，并在此基础之上形成用户需求说明书；2.研发部经理/项目经理组织会议讨论确认需求项，需要与用户方（/产品研发提出部门）就用户需求说明书的需求项达成一致意见，由用户或总工程师签字确认。需求获取方法新产品研发项目 1.对市场上已存在的同类产品/或超前产品进行调研，或从行业标准、规则中提取需求信息 ，形成需求调研单，然后进行需求风险识别、分类、筛选、优先排序，整理形成用户需求列表 ，并在此基础之上形成用户需求说明书； 2.研发部经理/项目经理组织会议讨论确认需求项，需要与用户方就用

15、户需求说明书的需求项达成一致意见，由用户或总工程师签字确认。需求获取方法（续）产品升级类项目1.分析从技术支持部或实施服务人员处反馈的用户新需求、系统缺陷，进行需求分类、评估、识别优先级，并考虑系统升级问题，形成用户需求列表 ，并在此基础之上形成用户需求说明书。 2.研发部经理/项目经理组织、讨论确定用户需求说明书，由研发部经理审核签字。需求获取方法（续）基于用例的需求获取步骤1.定义项目的视图和范围（用户需求列表）；2.确定用户类；3.在每个用户类中确定适当的代表；4.确定需求决策者和他们的决策过程；5.选择你所用的需求获取技术；6.运用需求获取技术对作为系统一部分的用例进行开发并设置优先级

16、；7.从用户那里收集质量属性和其他非功能需求；8.详细拟订用例使其融合到必要的功能需求中；9.评审用例的描述和功能需求；10.如果有必要，开发分析模型用以澄清需求获取的参与者对需求的理解11.开发并评估用户界面原型以帮助想象还未理解的需求；12.从用户中开发概念测试用例；13.用测试用例来论证用例、功能需求、分析模型和原型；14.在继续进行设计和构造系统每一部分之前，重复613步骤。1.谁是主要参与者，次要参与者？2.参与者的目标是什么？3.做事开始前有什么前提条件？4.参与者完成的主要工作或功能是什么？5.按照故事/业务场景所描述的还可能需要考虑什么异常？6.参与者的交互中有什么可能的变化？

17、7.参与者将获得、产生或改变哪些信息？8.参与者必须通知系统外部环境的改变吗？9.参与者希望从系统获取什么信息？10.参与者希望得知意料之外的变更吗？用例检查点1.太多的用例，注意合适的抽象级别。2.用例冗余，使用“包含”关系，将公共部分分离出来写到一个单独的用例中。3.用例中的用户界面设计，用例的重点就是用户使用系统做什么，而不是关心屏幕上是怎么显示的。4.用例中包含数据定义，比如数据类型、长度、格式和合法值等，这些应当放到数据字典里。5.试图把每一个需求与一个用例相联系，这是不可能的，需要使用规格说明书编写非功能需求、外部接口需求以及一些不能由用例得到的功能需求。常见用例陷井第六章 需求开

18、发及管理CMMI对应实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 需求分析提炼、分析和仔细审查已收集到的需求目的在于开发出高质量和具体的需求，以便作出实用的项目估算并进行设计、构造和测试需要从不同的视角检验需求，增加查明错误、消除不一致性、发现遗漏的机率创建分析模型之后，要不断改进，并分析评估其清晰性、完整性和一致性。需求分析（续）在用户需求描述(用户需求说明书)和软件设计之间建立桥梁目标详细描述客户需要什么为软件设计奠定基础定义在软件完成后可以被确认的需求内容详细的用例文本、用例图、活动图类图、状态图、顺序图数据流程、控制流程、处理说明需求分析流程图 32需求分

19、析方法面向结构分析法，结合获取的用户需求说明书，可采用数据流图等分析模型，把系统功能需求、非功能需求按事件流、数据流分析方式，逐层细化到系统操作及操作数据的存储方式，如数据的输入、输出，并考虑外部接口。结合数据流图和数据字典,详细说明系统功能间的输入、输出、系统活动及约束条件 ,编制需求规格说明书。面向对象分析法，使用UML辅助类图或其他分析方式来分析已获取的系统需求、用例模型、类图、数据字典等。结合图形化分析模型、类图、顺序图、关联图等进行说明，准确描述用户及系统的交互活动 ，编制需求规格说明书。快速原型分析法，分析已获取的用户需求，增量、迭代地明确用户工作流程、约束条件等，设定需求的优先级

20、排序，在风险较小的基础上分析、设计和实现系统构架结构或用户界面架构。结合立项时所选用生命周期，迭代进行分析活动 ，编制需求规格说明书。需求分析包含的元素基于场景的元素用户角度表现系统用例文本用例图活动图 泳道图带角色的活动图面向信息流的元素通过处理函数进行转换数据流图控制流图处理说明第六章 需求开发及管理CMMI对应实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 需求评审步骤1.用户需求说明书或软件需求规格说明书完成之后，由项目经理提出评审要求。评审之前项目经理准备评审相关资料，在总工程师或研发部经理的协助下，确定参加评审的人员，并把相关资料及评审通知一并发给参与评

21、审的人员。2.按计划进行评审，指定仲裁者、主持人、记录员。通过评审对需求中存在的问题进行讨论，主要针对各评审员提交的预审问题清单中的问题，达成一致意见。3.评审结束后，记录员整理会议内容，形成会议记录。4.项目经理或者指定人员整理项目评审表汇总评审发现的缺陷及其修改意见，并提交相关人员签字确认。5.用户需求说明书通过评审之后，由项目经理或者指定人员编写用户需求跟踪矩阵供后继项目开发过程中对需求跟踪时使用；软件需求规格说明书评审通过后，项目经理或者指定人员更新用户需求跟踪矩阵，填写相应内容6.建立需求基线，把软件需求规格说明书、项目评审表及相关文档纳入配置管理。第六章 需求开发及管理CMMI对应

22、实践需求开发及管理简述需求开发及管理流程需求获取需求分析需求评审 需求管理 需求变更控制变更步骤：1.变更提出者填写需求变更申请表说明变更内容、变更影响范围；2.提交CCB审批，必要时召开变更评审会议；对于不影响需求基线的小范围的变更，可以由项目经理审批；3.变更完成后，由验证人和质量保证工程师跟踪验证变更引起相关内容的调整是否正确无误；4.需求变更申请表纳入配置管理。l需求版本控制为评审通过的软件需求文档确定版本号；每一个经过变更软件需求文档应在修订页中描述其修正版本的历史情况，包括已变更的内容，变更日期，变更人姓名和变更后的版本号；项目经理和质量保证工程师负责检查软件需求文档版本的一致性。l需求跟踪矩阵在每次需求变更之后，必须更新需求跟踪矩阵；在每个阶段工作完成之后，亦需要更新需求跟踪矩阵。需求变更控制39需求开发及管理过程角色、活动、文档对照项目组长文档人员系分人员测试人员开发人员高级经理需求管理阶段（活动）1.需求获取之前制定项目开发计划初稿2.组织项目组成员进行项目