需求变更文档
办公系统需求文档
-版本V1.00
GTEC
编写人:李亮
广东国通电子商务有限公司
2011年09月
修订历史记录表：
一、目标
通过OA办公系统实现人员沟通顺畅，部门协调，内部管理实现办公的无纸化。二、项目组成
具体参考厂家提供的文档.
三、内部系统需求
3.1. 提供一个公共文档目录，让文档可以共享，可以通过设置相应的权限限制上传，
下载，删除功能。所对应的OA系统中已经该部分功能修改部分可能实现，是否需要新增？
3.2.部门成员对部门组长/经理、公司领导层的工作日报、周报、月报表的提交功能，
要求能选择日期后直接填写及递交；每个部门有个提交报表的目录，部门组长，经理，或更高权限有权限查看，提交人可删除不能修改。类是于公共文档，区别在于查看权限不同。对应的功能可以通过修改工作管理-我的汇报可以实现该部分功能。
注:工作日志，周报，月报我们理解上就是向上级汇报的，并不需要审批，只是让上级知道下属的工作情况。如需要审批可以在工作流程中定义工作审批流程。
3.3.部门内成员间、对其他部门(组长及以上职务才有权限)的工作委派单，包括委派者、委派对象、任务描述、完成期限、完成效果评价等功能；委派单下发之后在相对应的委派对象的工作任务中展现。可以通过修改工作流程—表单设计实现次功能是否令增加新的菜单功能？
3.4.问题提交功能，如内部员工发现系统有bug 或者OA系统已经不能满足部门的使用，可以通过提交功能提交上来，领导审批之后，任务直接下发到产品技术部负责人的工作任务中。
3.5 .工作管理-菜单中增加汇报类别如：工作日志，周工作总结，可以实现自定义类别. 添加工作汇报的时，可选择具体汇报的类别，如每日工作日志提交，可选择工作日志，周报提交可以选择周报类别，类别可通过有权限的用户自定义。实现该功能后，在汇报管理中就能很清晰筛选出下属向上级汇报的工作，不会出现不具体的类别。
增加：汇报类别
汇报类别方便上级筛选具体的工作汇报类别进行查看。
3.6 工作管理-当前状态用不同颜色区别分开如：审批不通过可以用红色，正常完成用
黑色等。
四、时间进度安排计划
如何做好需求变更管理——需求变更流程规范
如何做好需求变更管理——需求变更流程规范 一、引言 由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。 二、目的 控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。 三、角色与职责 1、市场人员 1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2）负责与客户的沟通确认，并及时反馈客户最新需求。 3）负责与项目经理的沟通 4）负责与客户协调沟通需求变更中需求部分存在的差异 5）负责将需求变更中的需求提供给客户签字确认 2、项目组长 1）负责协调变更的需求并对变更的需求有拒绝的权利 2）负责对变更的需求部分设计的修改 3）保证项目的开发与需求的一致性 4）确定开发进度是否需要进行变更 5）分配新需求给相关开发人员 3、测试组长 1）负责相应测试需求分析书的修改 2）负责把最新需求及时传达到测试人员 3）保证测试进度与开发进度一致性 4）负责与项目组长及时确认最新需求 4、测试人员 1）负责更改测试用例，保证用例与需求同步 2）调控测试进度，保证任务的正常完成 5、项目经理 1）参与需求修改的评审工作 2）最终确认需求是否进行修改 6、配置管理员 1）负责更新需求文档，记录需求更改记录
2）负责需求变更信息的发布与跟踪 四、需求变更处理流程图 需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图： 1、需求变更流程(客户提出需求变更) 1）执行条件： 客户提出需求变更 图：需求变更流程(客户提出需求变更) 2）流程说明： 需求来源：客户提交相关需求变更
软件开发项目需求变更管理及应对之
软件开发工程需求变更经管及应对之道研究 变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。 需求变更经管的需求 需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。 需求变更的出现主要是因为在工程的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。 随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想
到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。 这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来经管需求变更，那么很可能造成工程进度拖延、成本不足、人力紧缺，甚至导致整个工程失败。当然，即使按照需求变更控制流程进行经管，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更经管的目的所在。 六大原则 实施需求变更经管需要遵循如下原则： 1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
需求变更申请表模板
项目需求变更申请表 项目需求变更申请表 填表说明 1.变更类型为：增加、删除、修改； 2.变更阶段为：需求阶段、详细设计阶段、开发阶段、测试阶段； 3.变更原因为：业务改变、新增需求、需求取消、其他（需明确原因）； 4.需求确定时间以QC人员收到项目负责人发送的项目需求确认文档的工作邮件时间为标准，项目需求文档 包括但不限于项目需求原型和项目需求说明书。 5.项目需求确认文档必须发送到开发负责人、QC人员、开发部经理邮箱，QC人员做好备案管理。 6.变更优先级为：特级、普通、建议，对于建议级的变更“不参与讨论，不做处理”，仅作为给开发人员的参考， 项目开发不做任何变动，QC人员做备档处理；特级和普通级的任何一个变更一经提出必须有明确的处理结果，QC人员做好全部过程中的备档处理。 7.基线影响只能填写“有”或者“没有”影响； 8.增加工作量：明确增加的具体工时，以“人/天”为标准计量单位，最低为0.5人/天； 9.项目进度影响：明确项目进度受影响的时间，明确项目要延期交付的时间，以天为计量单位，最低为一天； 10.项目性能（功能）影响：明确对某一个功能（性能）产生的影响； 11.QC(quality controller)质量控制员职责：在产品（项目）生产（开发）各个过程的（质量、规范）管理控制， 并协同相关部门开展工作的职责。工作范畴为：原料（需求分析）生产（开发）过程成品产出（项目验收交付）。项目中所有的工作邮件包括但不限于需求变更邮件、人员异动邮件、人员外出支持申请邮件、需求（原型）变化邮件、项目会议记录邮件等必须抄送项目QC人员备案，未抄送邮件视为无效邮件。QC人员对所有的项目邮件进行收集、整理、统计备档。 12.对于无效邮件所有项目人员均可以不予理会，QC人员只对有效邮件做处理。 13.工作邮件的回复必须标准、简洁、明确。邮件第一行必须包括但不限于这行内容“邮件已收到，收到时间： 2011-10-20 12:01。”时间小时采用24小时制，精确到分钟。 14.项目基本信息、变更需求编号、分析者、需求分析日期由QC人员填写； 15.变更类型、变更阶段、变更原因、变更优先级由项目负责人填写； 16.变更申请人、变更申请日期、变更模块、变更前后内容（或者功能、性能、界面展示）描述由产品人员填 写； 17.进度影响分析、功能影响分析由开发负责人填写； 18.审核签字：每位签字人员必须明确表示“同意变更”或者“不同意变更”并签名； 19.分析者包括但不限于产品人员，开发负责人，项目负责人，开发部经理； 20.所有填表处严禁出现语义表述模糊字样，必须明确表态“同意”“不同意”“是”“否”“有”“无”等；
工程变更联系单格式
工程联系单 建设单位：安徽电信芜湖分公司编号工程名称：中国电信芜湖数据中心工程 施工单位：中国建筑第四工程局监理单位安徽省建设监理有限公司 联系内容 内容：芜湖数据中心工程内外墙砌体材料生产供应厂家确认 根据图纸设计要求，芜湖数据中心工程外墙采用空心混凝土砌块，内墙采用加气混凝土砌块。2010年11月22日上午，我单位对芜湖市有资质的三家砌体材料生产厂家进行考察，第一家是安徽治宇建材有限公司，第二家是安徽省中龙建材科技有限公司，第三家是芜湖鑫耀建材实业有限公司。现将考察结果报告如下： 一、安徽治宇建材有限公司： 生产规模能够满足本工程需求；加气混凝土砌块质量较好，此公司只生产加气混凝土砌块，不生产空心混凝土砌块。 二、安徽省中龙建材科技有限公司： 生产规模能够满足本工程需求；砌体质量基本合格，其中外墙材料空心混凝土砌块质量较好，内墙材料加气混凝土砌块质量比第一家要差一些。 三、芜湖鑫耀建材实业有限公司： 生产规模属于中等，但此厂正进行机械维修，白天不生产，晚上才进行生产，无法确是否能满足本工程施工需求；外墙材料空心混凝土砌块和内墙材料加气混凝土砌块质量比以上二家砌体材料要差一些。 针对以上事项，这三家公司的生产规模、材料质量、产品服务等方面综合考虑后，建议外墙材料空心混凝土砌块生产供应优先考虑第二家安徽省中龙建材科技有限公司，其次考虑第三家芜湖鑫耀建材实业有限公司。建议内墙材料加气混凝土砌块生产供应优先考虑第一家安徽治宇建材有限公司，其次考虑第二家安徽中龙建材科技有限公司。以上事项报于业主、监理进行确认。 施工单位（章） 日期 监理单位: 监理单位（章） 日期 建设单位: 建设单位（章） 日期
项目需求变更分析和解决之道
一、令人烦恼的需求变更 作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。甚至要重新设计现有的架构。 而面对这种情况，作为项目经理的你是否会说：“我们无法拒绝客户，但也无法立即满足他的新需求，所以只好是推到以后再进行完善。”或者，更极端些的想法：客户总是在异想天开，客户的需求在技术上根本无法实现…… 在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。因为在一开始已经多次和客户沟通，也在没有任何异议的情况下得到了明确的答复，但当开发项目在不断演进，客户对系统的理解逐步加深之时，他们最终还是推翻以前自己想要的需求。而这时你会认为对于需求，只有获取，没有确认。 而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。你还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求变更只会令项目组中的开发人员疲于奔命，无所适从。 在你的软件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次软件项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更？ 首先，这种想法和认识是错误的，软件项目开发中的需求变更是不能被完全消除的。无论是项目经理还是项目开发人员，最好在项目开始之前就消除这种想法。需求变更是不可能被消除的，而“消除需求变更”的想法却需要被消除。消除需求变更的所有的努力和想法，在项目开发进行中通常都是费力不讨好。 项目开发过程中，需求的变更是不可避免的 虽然一般情况下，项目经理花费了大量的心力和气力去避免需求变更，可最后需求变更总是会出现。但这并不意味着项目不应该做这方面的工作，无论是项目经理，还是开发人员对于需求变更的正确态度应该和对待软件测试的态度一样，在需求变更发生之前尽量减少需求变更发生的情况，以将需求变更带来的风险降到最低。 二、需求变更的产生原因 在软件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也可能来源于项目组内部。 对于需求变更发生的原因，细细追究起来无外乎以下几种原因： 1、范围没有圈定就开始细化 细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。 当细化到一定程度并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是人工手动添加的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。 2、没有指定需求的基线 需求的基线是指是否容许需求变更的分界线。 随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来，是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少）。 3、没有良好的软件结构适应变化 组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻
工程变更签证管理办法及流程修试行版
设计变更签证管理办法及流程 第一章设计变更管理规定 第一条目的 为了加强设计变更管理，规范工作流程，有效地控制成本，确保工程质量和工程进度，特制定本流程。 通过对设计变更申报资料进行审查、审批，确保设计变更的及时性、合理性和经济性，消除设计变更对工程成本和进度带来的消极影响。 第二条设计变更是对设计内容进行完善、修改及优化，一般需要设计单位的签字、盖章。特殊情况可以由发包单位的有关职能部门（设计部或工程部）签字确认。设计变更共分为两类： （一）一般设计变更：不改变设计原则，不影响使用功能，不影响工程的质量和安全，不影响美观，变更发生费用在5000元（含）人民币以下的； （二）重大设计变更：变更发生费用在5000元以上，对原方案、原系统、主要结构布置、主要尺寸、坐标、主要标高、主要设备及主要使用功能改变及变更发生费用在100000元以上的。 第三条设计变更的体现形式分为四类： （一）由设计单位提出的设计变更；设计单位在提交施工图后，因设计内容自身的错、漏、碰、缺等原因，而导致做法变动、材料代换或其他变更事项，提出的建筑、结构、水、电、景观、装修等专业的修改要求； （二）由建设单位提出的设计变更；设计部门为改进设计效果提出的变更；市场营销部提出基于销售需要提出的变更；成本部开展成本优化工作，而导致做法变动、材料代换或其他变更事项；商管公司根据后期运营以及招商需要提出的变更；公司管理层提出的变更； （三）由施工单位、监理单位提出的设计变更；监理、施工单位采用新工艺、新材料或其他技术措施等，而导致做法变动、材料代换或其他变更事项；施工单位为了方便施工，或施工过程中发现的 地质、水文实际与勘察报告、资料不符而提出变更；工程质量事故引起的变更； （四）由客户提出的变更申请，商管公司根据运营及招商需求提出的设计变更； 第四条对上述提出的工程设计变更，提出部门备齐相关原始资料，工程部、设计部、成本部以及相关部门（前期部、营销策划部、商管公司）应认真审查，确定是否进行变更，如确实需变更，走设计变更流程后由设计单位出具设计变更联系单。 第五条设计变更应将工程变更内容描述清楚。如：工程名称、变更原因、变更时间、变更部位、图纸比例、图示尺寸、规格型号、材料材质等，应达到根据变更单可准确计算工程量。 第六条设计变更控制相关部门的职责： 1 工程部：作为现场管理部门负责对设计变更的实施及验收的管理工作，同时做好设计变更工程 量的核实、记录工作，所有设计变更的实施均应有现场记录（附简图、尺寸）或照片（如需要），为设计变更（签证）处理，准备基础性工程资料。 办理工程部、监理公司和施工单位提出的设计变更申请手续； 办理正式变更手续并下发成本管理部或营销策划部；
软件开发项目需求变更的管理
软件开发项目需求变更的管理 变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。 需求变更管理的需求 需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。 需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。 这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚
至导致整个项目失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。 六大原则 实施需求变更管理需要遵循如下原则： 1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 2.制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。 3.成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB 由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。 4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。 5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。 6.妥善保存变更产生的相关文档。 应对之道 需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程，笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策： 相互协作很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。 充分交流需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。 安排专职人员负责需求变更管理有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。 合同约束需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。 区别对待随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。