第9章需求开发
需求开发（Requirement Development，RD）的目的是通过调查与分析，获取用户需求并定义产品需求。
需求开发过程域是SSP模型的重要组成部分。本规范阐述了需求开发过程域的两个主要规程：☆需求调查[SPP-PROC_RM_SURVEY]。
☆需求定义[SPP_PROC_RM_DEFINE]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
需求分析是需求开发过程域的重要活动之一，但是不宜用“规范”这种形式来论述。本章对需求分析方法做了概括性的介绍，请读者阅读更加专业大需求分析论著。
本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
9．1介绍
需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程，需求开发和需求管理的流程图如图9－1所示。
图9－1 需求开发与需求管理流程图
需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”，“需求分析”则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发的工作的人员称为需求分析员（也叫系统分析员），避免与其他开发人员混淆。
1．需求调查
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
2．需求分析
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常用的需求分析方法有“问答分析法”、“结构化分析法”和“面相对象的分析法”。
3．需求定义
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将根据《产品需求规格说明书》开展系统设计工作。
需求开发过程域产生的主要文档有：
☆《用户需求说明书》，模板见[SPP-TEMP-RD-UR]。
☆《产品需求规格说明书》，模板见[SPP-TEMP-RD-PRS]。
9.2 用户需求调查
9.2.1 目的
●获取用户（客户与最终用户）的需求信息，经过分析后产出《用户需求说明书》。
9.2.2角色与职责
●需求分析员调查、分析用户的需求。
●客户与最终用户提供必要的需求信息。
9.2.3启动准则
●需求分析员已确定。
9.2.4输入
●任何与用户需求相关的材料
9.2.5主要步骤
『Setp1』准备
●需求分析员确定需求调查的方式，例如：
☆与用户交谈，向用户提问题。
☆参观用户的工作流程，观察用户的操作。
☆向用户群体发调查问卷。
☆与同行业、专家交谈，听取他们的意见。
☆分析已经存在的同类软件产品，提取需求。
☆从行业标准、规则中提取需求。
☆从Internet上搜查相关资料。
●需求分析员准备调查问卷（问题表）。
●需求分析员与被调查者建立联系，确定调查的时间、地点、人员等。
『Setp2』调查与记录
●需求分析员调查用户需求，随时记录调查过程中所获取的需求信息。
『Setp3』分析需求信息
●需求分析员分析已经获取的需求信息，消除错误，归纳与总结共性的用户需求。
『Setp4』撰写用户需求说明书
●需求分析员按照指定的文档模板撰写《用户需求说明书》，主要内容包括：
☆产品介绍
☆描述用户群体的特性
☆产品应当遵循的标准或规范。
☆描述产品的功能性需求。
☆描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。
提示: 调查过程中获取的需求信息可以作为《用户需求说明书》的附件。
[后续活动：需求确认]
●项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《用户需求说明书》，尽最
大努力使《用户需求说明书》能够正确无误的反映用户的真实意愿。
●需求评审之后，开发方和客户方的责任人对《用户需求说明书》做书面承诺。
提示: “需求确认”活动属于需求管理范畴，详见[SPP-PROC-RM]。
9.2.6输出
●《用户需求说明书》
9.2.7结束准则
●需求分析员已经撰写完成《用户需求说明书》，并做了内部审查（消除拼写、排版等错误）。
9.2.8度量
●需求分析员统计工作量和上述文档的规模，汇报给项目经理。
9.3 产品需求定义
9.3.1目的
●定义准确无误的产品需求，产生《产品需求规格说明书》。
9.3.2角色与职责
●需求分析员定义产品需求
●客户与最终用户提供必要的需求信息，并确认产品需求。
9.3.3启动准则
●《用户需求说明书》已经撰写完成。
9.3.4输入
●《用户需求说明书》
9.3.5主要步骤
『Setp1』细化并分析用户需求
?需求分析员对《用户需求说明书》进行细化，以便产生详细的产品需求。
?需求分析员对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好的理解需求。建议采用Rational的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明书》的附件。
提示:建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。
『Setp2』撰写产品需求规格说明书
●需求分析员按照指定的文档模板撰写《产品需求规格说明书》，如果待开发的产品分为软件
和硬件两部分的话，则应当分别撰写《软件需求规格说明书》和《硬件需求规格说明书》。
●《产品需求规格说明书》的主要内容包括：
☆产品介绍。
☆描述用户群体的特征。
☆定义产品的范围。
☆阐述产品应当遵循的标准或规范。
☆定义产品中的角色。
☆定义产品的功能性需求。
☆定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求。
[后继活动：需求确认]
●项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，
尽最大努力使《产品需求说明书》能够正确无误地反映用户的真实意愿。
●需求评审之后，开发方和客户方的责任人对《产品需求说明书》做书面承诺。
说明: “需求确认”活动属于需求管理范畴，详见[SPP-PROC-RM]。
9.3.6输出
●《产品需求规格说明书》
9.3.7结束准则
●《产品需求规格说明书》
●已经对产品需求进行了审判，并且获得了开发方和客户方对需求地承诺。
9.3.8度量
●项目经理统计工作量和上述文档地规模。
9.4需求分析地方法概述
很多时候用户说不清楚需求、说错需求或者提出一些无法实现地需求。
需求分析是指在需求开发过程中，对所获取地需求信息进行分析，及时排除错误、弥
补不足，确保需求文档正确地反映用户的真实意图。
需求分析是需求开发过程中“最费脑子”的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用，很有实用价值。
9.4.1问答分析法
问答分析法很简单：刨根究底地问，如果解答了这些问题，那么需求分析也就分析清楚了。一个人可以“自问自答”的分析需求，几个人分析需求则称为“研讨”。
问答分析最重要的问题是：“是什么”和“为什么”。
每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应该解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正、清楚的需求。
其他常见的问题有：
?需求存在二义性吗？
?需求文档的上下文有矛盾吗？
?需求完备吗？
?需求是必要的吗？
?需求可实现吗？
?需求可验证吗？
?需求的优先级确定了吗？
9.4.2建模分析法
人们都有这样的感受：有时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一纸抵千言”就是这个道理。
在需求开发过程中，对于某些类型的信息，用图形表示要比文本更有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是只用图形符号来表示、刻画需求。建模分析法主要有两大类：“结构化分析法”和“面向对象分析法”。
1．结构化分析法
软件的建模分析兴起于20世纪60年代末期、70年代初期。结构化分析法并不是由里程碑式的、明确的涉及这个问题的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的单一方法。相反的它是发展了二十多年的一个混合物。结构化分析方法在20世纪70年代和80年代非常流行相关论著也很多。对结构化分析方法有较大贡献的学者有DeMacro,Gane,Sarsen,Yourdon,Constantine,Ward,Mellor,Hatly,Pirbhai等人。文献[Pressmen99,P206~P214]对结构化分析方法作了高度概括（如兔9-2所示），我们不妨称之为“一个中心三种图”：
?“数据字典”是中心，它包含了软件中所有数据对象的描述。
?“实体-关系图”是用图形符号来标识数据对象以及它们之间的关系。
?“数据流图”指明了数据在系统中移动时如何被变换。
?“状态-变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。
图9－2 结构化分析方法示意图
2．面向对象分析法
面向对象分析设计（OOAD）方法兴起于20世纪80年代，从20世纪90年代起至今它已经在分析设计领域占据了无可争议的主流地位。
我在读本科（1990年至1994年）时就感觉到了人们对“面向对象”的狂热。关于“面向对象”的课堂、学术报告往往人满为患。高软件研发的人都“言必谈对象”，并引以为荣。
面向对象分析设计领域有一些比较著名的学派，如：
?Coad和Yourdon学派，其代表作为[Coad91]。
?Booch学派，其代表作为[Booch94]。
?Jocobson学派，其代表作为[Jaconbson92]。
?Rumbaugh学派，其代表作为[Rumbaugh91]。
有趣的是，这些学派的掌门人就像上帝、真主、如来佛，他们用各自的方式定义了这个世界，并留下一堆经书来解释这个世界。这种混乱的局面被学术界称为百家争鸣，每年都诞生了许多论著和教授。叫苦的是软件企业和开发人员：没有统一的方法，不好干活啊！
终于等到了那一天，Rational公司招纳了Booch,Jocobson,Rumbaugh,这三位“面向对象”业界的权威强强联手，制定了“统一建模语言”（UML）。1997年11月，UML被国际对象管理组织（OMG）采纳，此后UML成为OOAD建模语言的国际标准。
UML吸收了各种OOAD方法的精髓，对于OOAD中的语义、图形表示法和使用规则作了完整而详细的定义。UML的建模能力超过了以往任何一种OOAD方法,当然其复杂性也随之膨胀.大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档(如[ RUMBANGH99])。真正使UML 流行的是Rational公司基于UML的建模工具Rose。Rose易学易用，它能交互地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等，深得开发人员的喜爱。
介绍UML和Rose的书籍非常多，读者可以自己选择、学习，这里不再论述。
3. 恰当地使用图形符号
现代建模工具如Rose有非常丰富夫人图形符号和文字标注，能很好地表达模型的细节。要注意的是，在建模时使用过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。
世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在
需求规格说明书中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求规格说明书的附录中，便于正文引用。
9.5实施建议
●先对需求分析员进行培训，让他们掌握必要的需求开发技能。
●对需求开发过程域产生的所有有价值的文档进行配置管理。
●对于非合同项目，本规范中有关客户的活动可以简化。
●需求的建模分析有较高的技术难度，需求分析员应当根据自身水平进行取舍。建议企业购买
Rational Rose作为需求建模分析的工具。
●需求分析员根据产品的特征，适当地修改《用户需求说明书》和《产品需求规格说明书》的
模板。
需求管理（Requirements Management ）是属于CMM2中的过程域，简 称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM 的一些基础知识、基础术语不再介绍。 需求管理与需求开发的分界线： 市场营销 用户需求 管理层 需求开发 需求管理 市场 营销 管理层需求变更项目环境 项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。 需求管理 在CMMI 中，需求管理的目标定义为： a. 把软件需求建立一个基线供软件工程和管理使用。 b. 软件计划、活动和工作产品同软件需求保持一致。 更高的目标： 软件需求的复用
需求管理的原则和方法 a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的 c. 只要需求变化了，需求变更的影响就必须被评估 d. 需求必须分优先级 e. 需求一定要分类管理 需求管理的主要工作： 特定目标和特定实践 特定目标 ●管理需求 管理需求并识别需求与项目计划和工作产品之间的差 异。 ●SP 1.1 取得需求理解 ●SP 1.2 取得需求承诺 ●SP 1.3 管理需求变更 ●SP 1.4 维护需求的双向追溯性 ●SP 1.5 识别项目工作与需求间的差异 REQM特定目标的关系
SP 1.1 取得需求理解 SP 1.1 和需求提出者一同来了解需求。 l 识别出谁是需求的提供者 l 识别出需求的接受标准： a. Clearly and properly stated得到清晰和恰当的定义 b. Complete完整的 c. Consistent with each other相互一致的 d. Uniquely identified得到唯一标识的 e. Appropriate to implement适宜实现 f. Verifiable (testable)可以验证（测试） g. Traceable可追溯 l 分析需求，确保符合已建立的准则。 l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺 SP1.2 取得项目成员对需求的承诺。 ●评估需求对现有承诺的影响。 需求变更或新需求发生时，评估它们对项目成员的影 响。 ●协商并记录承诺。
Q/ZSZDXM01新产品开发项目管理办法 版本号： 标准化： 审定： 批准： 重庆宗申宏立座垫制造有限公司发布 新产品开发项目管理办法 目的
为建立健全公司制度、规范新产品开发流程，使新品项目按计划进行，特制定本管理办法。范围 本办法适用于公司所有的新产品开发项目全过程的管理。 定义 新产品开发是指从研究选择适应市场需要的产品开始到产品设计、工艺制造设计，直到投入正常生产的一系列决策过程。 职责 公司领导 4.1.1对项目立项、项目撤销进行决策； 4.1.2任命项目主管或经理； 4.1.3对项目计划进行评审；对项目进行过程中的重大里程碑、重大变更计划做出决定； 4.1.4对项目的绩效进行考核。 项目部 4.2.1项目立项前期组织各部门对项目进行可行性评价； 4.2.2召集成立项目小组，召开项目阶段性评审会（主要指手工样件、工装样件、小批送样评审）； 4.2.3适时更新项目进度表，确保新项目按照客户的要求顺利投产，有异常情况时向客户报告。4.2.4定期或不定期组织召开以产品工程师、供应商质量工程师、采购工程师、物流工程师、客户质量工程师、生产管理等为主要成员的项目推进会，督促、协调各部门及供应商按时、保质、保量完成各项工作； 4.2.5协调客户与公司内部各部门的沟通，最大程度地满足客户合理的需求。 4.2.6对开发阶段客户提出的座椅交样数量及试验样椅等各种需求的座椅，项目部下达计划到物流计划部（5套以下手工样件下达计划到技术部）。 4.2.7按照《项目管理考核办法》Q/ZS-MSZDRY03，进行考核。 财务部 4.3.1立项前期对产品进行投资回报分析，确定从财务角度出来该项目是否可行； 4.3.2按客户要求对产品进行报价和议价，并对各种费用进行审核。 4.3.3按项目费用预算计划准备资金。 4.3.4对新产品材料提出目标价格。 技术部 4.4.1项目立项前期对该产品进行技术分析，确定从技术角度出发该项目是否可行，能否满足客户
E-Storage Management System Software Requirements Specification 电子化仓储管理系统软件需求规格说明书 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved
Revision Record 修订记录
Catalog 目录
错误!未找到引用源。 Keywords 关键词：仓储管理 Abstract 摘要：本文主要描述电子化仓储管理系统的设计需求，包括功能需求和性能需求，以及其他设计约束等。 List of abbreviations 缩略语清单：
1Introduction 简介 1.1Purpose 目的 1.2Scope 范围 本文档包含电子化仓储管理系统V1.0的对外接口和功能描述，以及和外部的约束关系。2General description 总体概述 2.1Software perspective 软件概述 2.1.1About the Project 项目介绍 2.1.2Environment of Pruduct 产品环境介绍 2.2User characteristics 用户特征 2.3Software function 软件功能 2.4Assumptions & Dependencies 假设和依赖关系 3Specific Requirements 具体需求
3.1Functional Requirements 功能需求 我们采用面向对象分析的方法来作为主要的系统建模方法，使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。 Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成时，该模型将来可 派生出动态对象模型。 设计Use-case时，我们遵循下列步骤： 第一步： 识别出系统的管理员。管理员可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者是谁。尽可能地确保所有管理员都被完全识别出来。 第二步： 描述主要的Use Case。可以采取不断地问自己“这个管理员究竟想通过系统做什么？”来准确地描述Use Case。 第三步： 重新审视每个Use Case，为它们下了详尽的定义。 电子化仓库管理系统是通过对入库业务、出库业务、仓库调拨、库存调整业务信息的管理，提高仓库管理信息的实时性和准确性，达到即时库存管理的功能，并有效控制并跟踪业务的物流和成本管理全过程，实现完善的企业仓储信息管理。系统中设计了装箱算法，为客户提供合理有效的装箱方案，保证了货物集装箱的利用。本系统可以提供有关库存情况的准确信息，增强了作业的准确性和快捷性、减少了整个物流中由于商品误置、送错、偷窃、损害和库存、出货错误等造成的损耗，并最大限度减少存储成本。 总体功能时序图：（如图3-1所示）
软件需求开发与管理 1概述 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段, 需求开发活动包括以下几个方面： (1)确定产品所期望的用户类 (2)获取每个用户类的需求 (3)了解实际用户任务和目标以及这些任务所支持的业务需求 (4)分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 方法和附加信息 (5)将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 (6)了解相关质量属性的重要性 (7)商讨实施优先级的划分 (8)将所发现的用户需求编写成规格说明和用例模型 (9)评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组 接受说明之前将问题都弄清楚。 需求管理活动包括以下几个方面： (1)定义需求基线(迅速制定需求文档的主体) (2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 (3)以一种可控制的方式将需求变更融入到项目中 (4)使当前的项目计划与需求一致 (5)估计变更需求所产生的影响并在此基础上协商新的承诺。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪 (7)在整个项目过程中跟踪需求状态及其变更情况。 2需求工程的推荐方法 需求工程推荐方法 需求开发
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
需求开发和管理流程范例 目录 1.目的 (3) 2.适用范围 (3) 3.名词和缩略语 (3) 4.角色和职责 (3) 5.过程综述 (5) 5.1. 流程图 (5) 5.2. 过程说明 (5) 6.过程活动 (6) 6.1. 活动一：获取用户需求 (6) 6.2. 活动二：建立系统需求 (7) 6.3. 活动三.需求分析与建模 (9) 6.4. 活动四.形成需求规格说明 (10) 6.5. 活动五.需求验证 (11) 6.6. 活动六：需求变更 (12) 6.7. 活动七：需求跟踪 (12) 7.过程度量与改进 (15) 8.过程裁剪指南 (15) 9.相关文件 (15)
10.质量记录 (16) 11.附录 (17) 11.1. 附录1：需求优先级说明 (17) 11.2. 附录2：需求状态说明 (17)
1.目的 本程序文件定义了本组织的需求与管理的过程，目的是实现有计划地收集、分析顾客的需求，并保证所有共利益者在项目进展过程中始终保持对需求一致的理解和承诺。 2.适用范围 本过程适用于公司所有合同项目和自主研发项目。 3.名词和缩略语 4.角色和职责
5.1.流程图 5.2.过程说明 需求开发与管理过程包括首先获取用户需求，然后对用户需求进行分类和整理，形成系统需求。通过对系统需求进行分析和建模，形成需求规格说明书，并将分析后的需求以模型或原型方法与用户进行确认，以此建立设计开发基础。最后采用原型、测试验证、评审等方式验证需求。同时，在开发活动中有序的管理需求变更，并通过需求跟踪确保需求的可追溯性和一致性。
6.1.活动一：获取用户需求 通过与用户交流、对现有系统的了解以及对项目任务的分析，开发、捕获和修订用户的需要。 6.1.1.进入准则 经过市场扫描活动、售前支持、客户反馈等活动，产品经理经过基本分析，确定要进行某产品的开发和较大升级； 6.1.2.输入 市场分析报告、售前和售后服务相关记录 6.1.3.任务 任务1：产品市场扫描。市场服务部会同产品经理针对特定产品进行市场扫描工作，主要包括与该产品相关的其他产品的名称、主要功能、市场情况；产品的领域，相关标准情况；产品主要涉及的技术领域和技术发展概况。产品经理根据市场扫描的结果确认是否需要进行产品开发和升级。 任务2：需求调研。产品经理根据《需求调研规程》组织相关人员实施需求调研活动，形成相关调研记录和《需求特性列表》。评审小组对调研结果实施结构化审查。 任务3：产品路线图设计。产品经理根据产品的需求特性列表和市场情况初步确定产品功能特性的优先级，优先级划分参见附录1，并且将优先级的划分与高级经理进行沟通，得到初步的确定后，对需求特性列表按照优先级进行分类整理，形成《产品路线图》。 对于项目而言，此任务可以演化成考虑项目分阶段实施的需求划分。 6.1.4.输出 《需求特性列表》、《产品路线图》 6.1.5.退出准则 《需求特性列表》通过审核，与高级经理沟通后初步明确项目经理
中国ⅩⅩ银行产品研发项目组管理细则 第一章总则 第一条为提高产品创新工作质量和效率，明确产品研发项目组工作职责，规范中国ⅩⅩ银行产品研发项目组工作流程，依据《中国ⅩⅩ银行产品创新与管理委员会工作规则》、《中国ⅩⅩ银行产品创新与管理办法》等制度，制定本细则。 第二条本细则所称项目工作是指根据《中国ⅩⅩ银行产品创新与管理办法》立项并审批通过后进行的产品研发活动。产品研发项目组是具体实施项目的业务团队，具体任务为完成业务需求和制度办法的编制、需求解释与变更、业务测试、验收试点等工作。 第三条本细则适用于项目实施过程中所组建的产品研发项目组。 第二章产品研发项目组构成 第四条总行各部门、分行(分中心)在申请立项时提出项目组组建方案，包括项目组人数、项目组成员来源部门/分行、具体职责及工作任务、技能要求、到位时间等建议。 第五条项目组人员构成 根据项目需要，项目组由总行各部门、分行或外部合作伙伴委派专业人员构成。项目组成员须具备项目所需专业知识，项目经理还需具备组织协调能力和项目经验。 （一）产品研发部是产品研发的综合管理部门，需派出产品经
理或产品经理组参加所有的产品研发项目组，全程参与项目实施。产品经理服从项目组管理，重点进行产品概要设计与把关、对需求说明书规范的应用进行指导和讲解、参与需求说明书编写工作。 （二）项目牵头部门是产品研发的组织实施部门，负责组建项目组，派项目经理和专职人员参加产品研发项目组，负责和参与项目实施全流程的管理工作和相关具体工作。 （三）业务主管部门需派专职人员参加产品研发项目组，参加需求编写，负责制度办法、产品宣传培训方案、广告设计方案的制定，并为接手产品上线后的相关工作做好准备。 （四）科技部门需派专职人员参加需技术开发的项目组，参加需求讨论与技术实现可行性的评估，保证项目进入技术开发阶段的工作效能。 第六条项目实施期间，各部门应保持项目组成员的稳定，不得随意抽调或变更，项目组成员需服从项目组调配。如需调整，各部门应提前与项目牵头部门沟通，在不影响项目组工作进展的前提下，酌情予以变更。如需更换项目经理，项目牵头部门需报产品研发部核准后进行。 第三章产品研发项目组工作职责 第七条项目组职责 （一）负责拟定需求工作计划，报项目牵头部门批准后予以实施； （二）负责分析讨论产品创意，按照需求说明书规范完成业务需求编写工作，完成《XXX产品需求说明书》；具体要求参见《关于规范我行产品需求说明书编写工作的通知》（农银办发【2009】259
1软件开发实施方案 系统开发严格按照软件工程的方法进行组织，系统的开发过程按照需求分析、系统分析与设计要求、系统编码、系统测试几个过程有序推进。下表所示系统开发流程图，采用原型及迭代方式开发，根据用户需求持续改进，直到最终用户确认满意。 1.1开发流程总述 如下图示流程定义了我公司内部的软件开发过程，以指导和规范软件项目中开发过程的定义和相应的实施。 该过程可划分为一系列子过程，包括：软件需求分析、设计、编码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如设计过程又可分为结构设计和详细设计。但是在实际开发项目中，情况仍然会是千变万化的，因此我们也并不是一成不变的死板执行一个僵化的工作流程，我们的原则是在一个规范流程的指导和约束下，根据具体工程项目的实际要求，为每一个项目评估并制定真正能够最好的满足该项目要求的开发流程。
图 1.1-1 软件开发流程总图
在应用系统软件开发项目中，我们仍将遵循这一思想，这一点将在随后的项目开发实施计划部分有具体的体现，在这里和下面的相关章节中，我们仍将围绕着这个完整的开发流程来分析说明，以此来阐明我们对项目开发的完整过程管理思想和相关实践。下面我们对这个软件开发工作流程进行简要地分解说明。 1.2软件需求分析 （1）概述 由于应用系统与众多相关应用软件需要进行交互，因此需要先对这些应用系统进行分别梳理，充分做好需求调研工作，编写经项目单位认可并评审通过的《系统需求规格说明书》。 软件需求分析是按照项目定义的软件开发过程，根据系统分配给软件的需求（见《系统需求规格说明书》），进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定义。 本元素在整个过程中的位置如下图所示： 图示：软件需求分析在软件开发过程中的位置 （2）入口准则和出口准则
研发部需求开发流程管理
管理目标 1、所有关系人清晰明确地了解项目的需求和 期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量）， 即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发 快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行， 初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计 划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推 动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集
中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队 成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统
设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB 审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上
产品开发项目管理规程 1目的 本规程基于产品开发系统CPD流程，用于规范产品开发团队在产品开发过程中的管理。目的是保证产品开发的顺利实施，为PDT团队进行项目管理操作提供快捷帮助，统一项目管理步调，提高项目管理效率。 本规程整体上将项目管理各要素按项目启动、项目计划制定、项目执行、项目控制及变更、项目结束过程进行有机融合；各要素的相关详细操作均以模板和附件形式出现；本规程也涵盖了项目依赖管理、对外合作项目管理和项目管理IT指南。 2适用范围 本规程适用于所有产品和技术开发项目过程管理。 3 项目启动 项目概念阶段开工会作为项目管理活动起点。如图1所示：
图1 项目计划制定与CPD流程阶段对应关系 4 项目计划制定 项目计划包括主项目计划（进度计划）、人力资源计划、物料计划、风险计划、质量计划、项目预算。项目计划制定须严格按照对应的模板和规范进行。项目计划归档在IT管理系统中，作为项目过程管理和项目控制的基线。 4.1 主项目计划制定 如图1所示，PDT经理和PDT核心组在CPD主流程相应阶段共同制定主项目计划。
主项目计划由概念阶段项目计划（WBS）、端到端项目计划（WBS）构成，计划一旦经过评审就形成基线，并以此作为项目度量计算进度偏差的基线。 其中，端到端项目计划（WBS）与人力资源计划、项目预算在计划DCP完成后基线化。 主项目计划各基线确定一周内，PDT须在产品开发项目管理IT系统上发布。 计划评审通过后须及时发布，具体操作说明见表1： 表1 项目计划发布操作
4.1.1 主项目计划（进度计划）制定操作指导 项目计划制定的流程图、步骤和方法分别如图2： 图2 项目计划制定流程图 4.1.2 概念阶段项目计划（WBS）制定 计划制定前提：完成概念阶段项目开工会 计划制定责任人：PDT经理（LPDT） 计划制定参与者：PDT核心组成员 输出：《概念阶段项目计划（WBS）》 模板：《概念阶段项目计划（WBS）》模板 计划制定步骤： 1）获取《概念阶段项目计划（WBS）》模板； 2） PDT经理组织PDT核心组成员进行概念阶段的活动分解（WBS）、确定概念阶段主要活动/里程碑和重要的依赖关系； 3） PDT经理分析关键路径，并和PDT核心组成员共同确定主要活动/里程碑的时间； 4）各PDT核心组成员分别制定各功能领域的工作计划。步骤如下： 根据活动分解（WBS）的结果对项目计划模板中的任务进行裁剪；
普通话考试报名及成绩查询系统 需求分析 项目名称：普通话考试报名及成绩查询系统撰写人： 专业： 指导老师： 2012年3月19日
摘要 网络技术的飞速发展正无时无刻影响着人们的工作、在教育体系中,网络的应用也成为现代教育发展的基础.网络教育逐渐发展起来,校园网建设逐步成熟,基于Web的也伴随着网络技术的发展应运而生.它即简化了传统的考试模式,节约人力物力,也可以有效利用校园网资源,辅助教学. 该系统采用了目前流行的B/S模式,即浏览器、应用服务器、数据库服务器三层体系结构，后台数据库采用SQL Server 2005,客户端采用IE浏览器和服务器连接,最终形成了基于 B/S模式的在线考试系统.该系统具备了以下功能:学生信息管理、成绩查询等功能. 论文以基于B/S模式的在线考试系统为研究对象,按照软件工程的开发思想,用UML来构建在线考试系统模,后台采用数据库相结合. 际需求出发,论述了开发普通话等级考试报名及成绩查询系统的背景、目的及意义,讨论了开发系统的关键技术,并通过UML分析对系统设计及实现。 设计思路和方法采用瀑布模型开发，用统一建模语言 UML进行描述，经历了文献检索，需求分析，分析模型设计，数据模型设计，构建级设计，系统部署，系统测试六个个环节。。实现了用户登录、注册功能，出题组卷功能，考试评卷功能以及用户信息查询功能。 关键词：普通话等级考试报名及成绩查询系统； SQL SERVER2005
目录 一．摘要 (2) 二．背景 (5) 三．简介 (5) 1.设计目的 (5) 2.开发环境 (5) 3.程序功能 (6) 4.系统实际需求特点 (6) 四．整体规划思路 (6) 五．整体性需求分析 (6) 六．功能需求 (9) 1.业务规则 (9) 2.普通话等级考试报名及成绩查询系统登录 (10) 七．数据库设计 (12) 1.概念模型设计 (12) 2.数据表结构 (12) 八．系统结构设计 (14) 九．对性能的规定 (15) 1.灵活性 (15)
软件项目的需求开发与管理需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1? 什么是软件需求和需求工程 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情
产品委外合作研发管理 规范 SANY GROUP system office room 【SANYUA16H-
产品委外合作研发管理规范 XX有限公司 2015年8月 {项目名称} 项 目 合 同
目录 1.合同介绍 (3) 2.开发内容 (3) 3.乙方开发计划 (4) 4.甲方监控计划 (5) 5.甲方验收计划 (6) 6.乙方维护计划 (7) 7.禁止转委托开发 (7) 8.保密 (7) 9.知识产权归属 (7) 10.第三方知识产权 (8) 11.风险责任的承担 (8) 12.报酬及支付方式 (8) 13.违约与赔偿 (9) 14.不可抗力 (9) 15.解除合同 (9) 16.争议解决 (10) 17.一般条款 (10) 18.合同确认 (11) 附件 (11)
1.合同介绍 1.1甲方 1.2乙方 1.3合同目的 甲、乙双方经友好协商,一致达成本协议。双方申明，双方都已理解并认可了本合同的所有内容，同意承担各自应承担的权利和义务，忠实地履行本合同。 2.开发内容 2.1开发内容 （此处将简单描述项目开发内容，详细内容将在附件中包含。） 2.2技术指标和质量要求 （此处为甲方填写，对项目的具体指标和质量要求） 2.3应当遵循的标准和规范 1、此项目将严格按照软件开发标准和规范进行研发。
3.乙方开发计划 3.1开发期限和开发地点 本项目的开发期限为个月，自年月日至年月 日为止。 本项目的开发地点是。 3.2任务与进度 1、甲、乙双方将根据甲方为其业务开发项目及其所需功能的描述和甲方所提供的资料与信息共同制作项目需求分析。甲方在提交有关需求说明、资料和信息时，可以就其中所涉及的软件功能、目标、需求构成及相关技术问题向乙方咨询或征求意见，乙方应当及时予以解释和答复。 2、乙方在获取上述需求信息和资料后，应及时完成需求分析书。该需求分析书经甲方认可，并由甲、乙双方签字后作为本合同的附件。 3、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成需求说明书， 4、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成概要设计说明书， 5、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成详细设计说明书。 需求说明书、概要设计说明书以及详细设计说明书在完成后，均应提交甲方审核。 3.3开发进度报告
需求分析报告 1.引言 1.1目的 需求，指的是系统提供的能力必须遵从的条件，一个系统能否达到预期目标，系统需求做的好坏起着决定性作用，因此，他无疑是该平台开发过程中的重要一环。按照传统的软件工程理论，需求分析的目标就是确定要干什么，而不是怎么干，按照统一软件过程的理论（RUP理论），该平台的需求分析就是要致力于高效的正确的开发系统。必须足够详细的描述出系统需求，同时也要详细的描述系统必须达到的条件或实现的功能，使得用户就系统产生的问题一致。 本章将要对”基于教学POI的校园公共服务平台设计与开发”的需求进行分析,再此基础上将会对系统的各个功能进行建模,并且给出模型模型描述的图例序列图等模型。建立系统目标和需要解决的问题。 1.2背景 本设计将对基于教学POI的校园公共服务平台设计与开发进行详细的需求分析；基于教学POI的校园公共服务平台设计在兴趣点软件或APP中属于较为新颖贴近学生生活与教学内容的软件在这方面有大量的资源可循但是并没有与之相关的软件。作为本次软件工程设计的需求总体分析我们需要在POI、教学以及手机软件开发进行基本的融会贯通。 1.3术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 POI信息平台系统的建立,最直接的提供了非常好的查询管理平台,极大的方便了学生的查询教学点\课程等方案的选择,为学生教师等提供了海量的便利教学信息;学生再也不用考虑担心自己找不到有疑问而大费精力. 通过对用户需求分析以及POI流程研究我们应该解决以下问题 在APP中搜索到正确的\合理的POI信息; POI信息的充分展现,包括地图展示并标记POI点的特殊标记;
需求开发流程管理规定 1. 目的 通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。 ，
4. 流程图 图1：需求开发流程图
5. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 在需求文档中，一般取二级类别进行标识。 5.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：
●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； ●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。 提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。 5.2 需求评审确认及开发流程 需求评审是指程序开发方和需求提出方共同对《立项需求说明书》进行评审，双方对需求与商业目的达成共识。
在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。 5.2.1 需求评审 评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。 需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由信息技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： ●评审组长：总裁及总裁办相关领导、信息技术总监； ●评审成员：项目经理、程序员及其他相关人员； ●输入：《立项需求说明书》初稿 ●输出：《评审结果报告》 当需求文档评审通过后，程序开发方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。 未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。 经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属 界定： A.因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现 的功能与预期需求不一致，由需求方承担主要责任。 B.因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现 的功能与预期需求不一致的，由程序开发方承担主要责任。 5.3 需求变更 对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原因： 1. 系统所应用的外部环境发生变化； 2. 随着对软件的熟悉和应用，又提出新的需求； 3. 进行需求分析时未能彻底分析原始需求，或分析错误； 4.在开始时不能很全面的知道所需软件的功能。 需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。 只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。 需求受理人应适当拒绝一些不合理的变更。如：提出的变更不是由于程序开发方的过错引起的，此变更可能造成程序开发方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。 变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。
软件需求分析与设计复习题 一．判断 1、( × ) 程序设计语言种类很多，在进行软件开发时可以随便选择一种语言进行编码。 2. ( x ) 软件需求规格说明书在软件开发中具有重要的作用，是软件可行性分析的依据。 3、(× ) 在软件开发的各个阶段进行过程中，增加人员肯定会对整个项目提前完成有好处。 4．( x ) 好的测试用例应能证明软件是正确的。 5．( x ) 软件功能测试的测试用例主要是由需求阶段的功能说明部分转化而来。 6、( x ) CoCoMo模型可以用来估算系统的工作量和软件开发所需时间。 7．( x ) 有时为了测试的方便，而可以局部地修改软件系统。 8、( v ) OOA方法的核心思想是利用面向对象的概念和方法为软件需求建造模型，大致步骤是识别对象（属性和方法），识别类及其结构，定义对象之间的消息传递等。 9．( x ) 面向对象方法更适合于软件重用的根本原因在于它是软部件唯一的合成技术。 10、( v ) 系统需求分析员应该具有开发软、硬件系统的经验并且了解用户领域的知识。 11．( x ) 在软件的生命周期中，工作量最大的一个阶段就是编写程序。 12、( x )软件运行正确，可见软件中没有缺陷（fault）。 13．( x ) RUP（Rational Unified Process：统一软件过程）本质上是轻量级的软件过程规范。 14、( v )软件失败（failure）在系统交付之前和交付之后都可能被发现。 15．( x ) 基准测试（benchmark test）是非正式的用户确认和验收测试。 16、( x )开发人员和客户对软件质量因素的认可是完全一致的。 17．( x ) UML语言支持面向对象的主要概念，并与具体的开发过程相关。 18、( v )里程碑（milestone）就是开发过程中的某个活动(activity)。 19．( v ) 好的软件测试是用少量的测试用例运行程序，发现被测程序尽可能多的错误。 20、( x )在软件开发中一定要不惜代价避免风险。 21．( v ) 在需求分析中，分析员要从用户那里解决的最重要的问题是明确软件做什么。 对功能的具体实现。 22．( v )用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部 23．( v ) 软件过载缺陷就是当运行程序时，软件内部定长的数据结构被溢出，系统任务无法 24．( v ) 结构化程序设计方法能改善程序结构，提高程序的运行效率。 二、选择从供选择的答案中，选出正确的答案填入（）内 1．白盒测试法常用的方法是A方法，黑盒法中常用的方法是B方法和C方法，C方法根据输入的关系设计测试用例。供选择的答案：（②③⑤） A、B、C：①综合测试②路径测试③等价分类④归纳测试 ⑤因果图⑥追踪⑦回溯⑧排错 2. 软件工程的出现是由于（ A ）。 A．软件危机的出现 B. 计算机硬件技术的发展 C．软件社会化的需求 D. 计算机软件技术的发展 3. 系统技术可行性研究涉及的技术应该是（D）技术。 A．现在已提出的 B. 现在在研究的C．不一定可以获得的 D. 一定可以获得的 4．模块综合测试的方法有A和B两种，A是从下层模块向上层模块依次结合进行测试，为测试需要C 以便调用被测模块，但从开发的初期就能并行进行测试作业，并且每个模块的D都很容易做，是这种方法的优点。其缺点是直到测试的最后阶段，程序的缺陷都难以发现。B是从上层模块向下层模块依次结合进行测试，为了测试需要设计E模块模拟被测模块所调用的下级模块。 供选择的答案：（A：⑦ B：⑥ C：⑥ D：① E：①） A、B、D：①功能测试②组合测试③综合测试④可靠性测试 ⑤结构测试⑥自顶向下测试⑦自底向上测试 C、E：①仿真②模拟③生成④转贮⑤跟踪 ⑥驱动模块⑦宏模块⑧支持模块
精心整理 管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、 2、 3、跟踪设计/开发/测试/回归/ 4、/跨部门协 调等几个方面。 5、 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 2 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。
跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态) 定情况执行补丁升级。 6、收尾阶段 产品交付，项目总结会。 常见问题 1、开发时间的估算 算，通常单个模块开发时间取决于以下因素： 1 2(包括对框架和应用的熟悉程度)。 3 开发者没有相关的代码可以参考，自己也没有经验， 1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。 2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下： A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开 发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。 B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。