项目范围说明书Word文档下载推荐.docx
《项目范围说明书Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《项目范围说明书Word文档下载推荐.docx（14页珍藏版）》请在冰点文库上搜索。
IT项目管理中最容易出现的范围蔓延现象，一般项目经理都比较容易意识到大的范围改变，从而及时采取措施，但是对于小的改变却很少能有这么敏感。
当项目接受了太多小的变化之后，所有这些小的变化结合在一起时，项目小组才意识到需要做的额外工作太多。
实际上和项目范围管理中反复强调的项目范围是.‘项目所包含的工作，且仅限于项目所包含的工作”是有很大出入的。
范围管理的重要性还体现在另外一个方面，即项目范围管理是时间、成本、风险等的管理基础。
影响项目成败有四个相互制约的条件，即范围、时间、成本和质量。
项目的质量是很难偷工减料的，牺牲质量的结果，轻的是收不回款，严重的是失去用户。
所以在质量要求不可能有太大变更的前提下，范围的增加将直接导致工期的延长，而在实际项目执行过程中，项目工期的延长将直接导致项目成本的增加。
1.1.3项目范围管理过程
图1.1项目范围管理主要过程
1.2项目范围规划
1.2.1项目范围规划的依据
1）环境因素
环境因素有组织文化、基础设施、工具、人力资源、人事方针以及市场状况，所以这些都会影响项目范围规划。
2）组织过程资产
组织过程资产是能够影响项目范围管理方式的正式和非正式的方针，程序和指导原则。
对项目范围规划有具体关系的组织过程资产包括：
Ø
与项目范围规划与管理有关的组织方针。
与项目范围规划与管理有关的组织程序。
可能存放于吸取的教训知识库中的历史信息。
3）项目章
项目章程是一份正式批准项目的文档。
项目章程给项目经理提供了授权，使他能获得进行项目活动所需的组织资源。
再项目前期，当项目被人为切实可行的时候，就需要确定和指派项目经理。
4）项目管理计划
依据项目管理计划中已批准的相关计划来创建项目范围管理计划，它们会对用于规划和管理项目范围的方法产生需要和约束。
1.2.2项目范围管理计划与需求管理计划
需求管理不是范围管理，他们之间的差别从各自的定义和所包括的过程就可以知道：
范围管理包含一系列子过程，用以确保项目包含且只包含达到项目成功所必须完成的工作，范围管理主要关注项目内容的定义和控制，即包括什么，不包括什么而需求管理是确保各方对需求的一致理解，管理和控制需求的变更，以及需求的跟踪。
所以需求开发和管理的目的是通过调查与分析，获取用户需求并定义产品需求，还要确保各方对需求的一致理解，管理和控制需求变更，需求的双向跟踪而范围管理的目的是确保项目包含且仅仅只包含项目所必须完成的工作。
需求管理是对已批准的项目需求进行全生命周期的管理，过程包括需求管理定义、需求管理流程、制订需求管理计划、管理需求和实施建议等，其主要的工作就是需求的变更管理范围管理过程包括范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制。
他们之间的联系：
首先通过需求开发来获取项目的需求，再次基础上确定项目的范围、进行项目范围管理，其次需求的变更会引起项目范围的变更。
1.2.3软件项目范围规划
范围规划是创立书面文件，阐述项目范围为未来项目提供基础条件的过程，特别是包括了用以确定项目或阶段是否成功完成的标准。
例如：
一个工程公司签订的合同是设计一个石油处理工厂，就要求在设计具体目标时，要界定好具体的工作范围。
范围阐述形式的基础是通过确认项目目标和主要项目的子项目，使项目团队与项目客户之间达成一个协议。
如果范围阐述的所有要素已经具备（如：
主要项目的子项目能够反映项目目标，项目证书能证明项目目标），那么，这个过程就仅剩实质性的制定书面文件的工作了。
1.3需求收集
1.3.1收集需求
需求获取工作的任务就是收集项目干系人的需求信息，为定义项目的范围奠定基础。
需求获取工作只能通过用户与开发人员之间进行高度的合作和交流才能成功。
在软件项目的需求获取活动中，一般要收集以下类别的用户需求：
（1）界面需求：
描述软件系统的外部特性，即系统如何从外部得到数据输入，如何向外部输出数据。
（2）功能需求：
列出软件系统必须完成的所有功能。
（3）性能需求：
响应时间、吞吐量、处理时间、存储空间等方面的限定。
（4）质量需求：
对安全性、保密性、可靠性、可维护性、可移植性、易用性等方面的要求。
（5）资源使用需求：
对硬件、支持软件、数据通信接口等方面的要求。
（6）软件成本消耗与开发进度需求：
即对时间和经济方面的要求。
（7）异常处理要求：
在运行过程中出现异常情况（如临时性或永久性的资源故障，不合法或超出范围的输入数据、非法操作等）时应采取的行动以及希望显示的信息。
1.3.2获取需求的常用方法
（1）访谈。
访谈是通过与干系人直接交谈来获取信息。
访谈的典型做法是向被访者提出问题，并记录他们的回答。
访谈经常是一个访谈者和一个被访者之间的一对一谈话，但也可包括多个访谈者或多个被访者。
访谈有经验的项目参与者、发起人、以及主题专家，有助于识别和定义项目可交付成果的特征和功能。
（2）讨论会。
讨论会把主要项目干系人召集在一起，通过集中讨论来定义项目需求。
讨论会是快速定义跨职能需求和协调干系人差异的重要方法。
由于群体互动的特点，被有效引导的讨论会有助于参与者之间建立信任、改善关系、改进沟通，从而有利于干系人达成一致意见。
在每次讨论会中，都必须记录所讨论的内容，并在会后加以整理。
在会前应提前发给参加人员有关讨论会的议题和内容等材料，以便有所准备。
（3）观察用户工作流程。
直接观察用户在其实际环境中怎样执行工作是一种行之有效的获取需求方法。
当产品使用者难以清晰说明他们的需求时，就特别需要通过观察了解他们的工作细节。
通常由观察者从外部来观看业务专家如何执行工作，也可由观察者实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
（4）问卷调查。
问卷调查是指设计一系列书面问题，向众多受访者收集信息。
当需要调查大量人员的意见时，向被调查人分发调查问卷是一个十分有效的做法。
经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。
调查者应仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。
（5）快速原型法。
快速原型法是指在软件开发的早期快速建立目标软件系统的原型，并据此征求用户对需求的反馈。
由于原型是可以操作的，它使得用户可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述，从而可以获得更为准确和清晰的需求。
快速原型法需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息。
分析和整理收集到的用户需求对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由。
将那种以“如何实现”方式表达的需求转换为“实现什么”的方式。
因为需求获取阶段关注“做什么”，而不是“怎么做”。
分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求。
2.项目产品范围管理
2.1产品范围描述
项目名称：
点餐系统
起草人：
艾斯凯尔、黄业鹏
项目经理（组长）：
艾斯凯尔
日期：
2019/4/14
项目发起人：
更新日期：
2019/4/18
项目的交付成果：
1.完善的点餐系统:
包括点餐功能，收银功能，数据分析功能。
2.顾客注册以及登陆页面设计图
3.餐厅菜品展示页面设计图
4.结账页面设计图
5.后台信息展示页面设计图
6.系统代码文本
7.点餐系统操作手册
8.规范的项目管理文档
完成项目的衡量指标:
1.点餐系统能够实现网上信息共享，用户网上点餐，网上结账以及产品评价等功能。
2.点餐系统的信息安全性。
实施项目的方法:
整体设计应该是依靠内部自己完成。
运用专业知识，着手系统设计开发。
首先小组成员学习搭建点餐系统的相关知识。
然后确定系统的基本需求分析和各功能概述。
例如业务需求，相关人员以及用户分析，顾客订餐功能分析，管理员后台管理系统功能分析，用户注册登陆，菜单详细信息设计，购物车以及结账功能分析，后台订单管理等。
然后着手于具体类的代码设计及交互。
最后再完善整个点餐系统，以达到设计需要。
项目范围变更管理的方法:
变更管理流程是该系统的一个重要应用组成，对于点餐系统的产生、计划、评估、审批、实施、记录等流程进行管理。
根据项目需求分析和范围管理分析小组确定，变更控制策略的工作主要包含：
根据需求报告和设计文档，设计系统的实体对象和工作流程，设计系统访问角色和分配权限，在原系统应用之上进行二次开发，对某些数据域和功能进行修改、删除和屏蔽，添加新的数据对象和新的功能，实现新的流程规则，撰写新的用户文档等。
依据相关知识，小组对点餐系统项目变更处理进行了简单的处理过程分析，如下图所示：
项目的工作范围：
1.进行方案设计
2.项目需求分析
3.项目概要设计
4.项目详细设计
5.编码实现
6.进行初步测试、调试
7.进行整体功能、性能测试
8.整体文档并归档
例外工作:
1.本项目为点餐系统的设计，不包括点餐系统应用于日常时的维护工作。
2.对于日后客户提出的新要求信功能，不在本项目的责任范围之内。
2.2任务概述
2.2.1系统概述
通过使用点餐系统提高点餐的电子化程度，顾客可以更快捷、方便的选择自己想要的美味佳肴；
为餐厅点餐的规范化和信息化管理打下坚实的基础。
据用户提出的需求归纳，本系统主要分为8个子功能模块，即接待开台模块、点菜模块、上菜划单模块、加菜模块、游戏模块、催单模块、账单统计模块、结账模块、提建议模块。
具体各模块功能介绍如下：
接待开台模块：
根据顾客所点菜的菜系将顾客分配到餐厅不同的区域；
点菜模块：
主要根据顾客点菜信息，生成菜单记录；
上菜划单模块：
厨师制作好菜品后，出菜时修改上菜记录；
加菜模块：
主要根据顾客后续点菜信息，更新菜单记录；
催单模块：
根据顾客的点菜记录，尽快实现端菜上桌；
账单统计模块：
选择合适的统计方式，根据相应的账单记录统计顾客的用餐费用；
结账模块：
根据顾客的点菜记录，生成账单，方便顾客结账；
提建议模块：
客户用餐完毕后，在上面可提出意见或建议。
2.2.2业务需求
餐厅点餐系统主要包括以下功能：
（1）根据顾客的需求，确定点餐单；
（2）后厨及时公布和调整菜肴信息并对收到菜单信息的进行确认；
（3）对于顾客就餐意见进行反馈。
2.2.3顾客点餐功能分析
根据对顾客网上订餐系统业务流程的分析，可以看出顾客点餐主要涉及到一些数据库的逻辑和程序应用逻辑。
具体的功能归纳如下：
（1）登录网上注册为会员；
（2）在订餐系统进行菜单浏览；
（3）会员对自己的个人信息进行更改，比如送餐地址和联系电话。
以及账户密码；
（4）顾客对已选的菜单进行更改选择的数量或者取消选择；
（5）当顾客确定订餐完毕后，顾客将其提交只服务器后台点餐系统，并生成订单。
2.2.4后台管理系统功能分析
（1）管理员在后台登录后，可以创建新的管理员；
（2）管理员可以对餐厅网上订餐系统上的菜单进行添加、删除和修改，比如更改菜单的图片，价格，菜单的描述，更换新品，添加新菜等；
（3）管理员对菜单进行管理，确定订单的生成；
（4）管理员根据不同的属性来查询订单，比如生成日期或者编号等；
（5）管理员根据不同的时间段统计处营业额，成本，同时还能统计出每道菜的销售量、任何时间段的销售情况以及每一个顾客的消费情况。
2.2.5用户注册和登录
用户访问本系统可直接进入系统主页，可选择登陆，若为注册可选择注册，只有注册用户方可点餐。
注册提供用户名和密码，用户名只能检测，若已存在也可进行提示。
另外加入记住密码功能，登陆一次可在两周内无需再次登陆，直接进入登陆状态。
登录界面：
用户直接输入桌号就行了。
点菜界面：
显示一张统一的菜谱，每个菜下面显示价格和份数，价格呈现灰色，表示此此菜没有了，呈现红色，表示还有。
点完后，点击结算按钮。
结算界面：
以表格的形式显示出来，左边菜名，中间是价格，右边是删除。
生成、修改、查看菜单:
餐厅人员其身份得到验证之后，他们就可以对菜单进行访问操作。
修改需要通过管理员验证后，操作有效。
用户生成、修改、查看菜单:
用户就座后，可在点菜界面进行操作，在提交点餐记录之前，用户可查看、选择或撤消菜品。
用户加菜：
用户在用餐过程中可以打开点菜界面，并在此界面中再次进行点餐操作，其消费金额将加到最终账单中。
服务员查看点餐及送餐：
服务员可随时查看点餐记录，并对点餐记录上的显示进行送餐等服务，对于点餐记录上已送达的菜品进行消除与记录。
2.2.6菜品详细信息
显示餐品中某一餐品的详细信息，包括菜名，配料，口味，价格等，以供用户放进自己的购物车。
2.2.7购物车
实现对已定菜品的管理，包括增加菜品，删除菜品，修改数量。
2.2.8提交购物车并生成订单
接受购物车信息，随即获取订单号，动态刷新顶单状态，固定时间（如30秒）完成一道菜，用户可继续修改为完成的菜品，已完成菜品无法进行操作，用户修改订单并保存。
2.2.9结帐付款
选择付款方式及对此次餐的评价。
2.2.10管理员操作
在后台系统中管理网上订餐会员管理和菜单管理。
3.项目工作范围管理
3.1工作分解结构（WBS）
由项目需求分析和项目范围说明书，小组对餐厅订餐系统进行了工作分解结构，如下所示：
（1）自顶向下法
把项目从粗粒度的任务逐层细化，得到整个项目的分解结构。
（2）类比法
已经完成的项目的WBS和以前的项目经验，根据当前项目特点做必要的调整，从而得到新项目的WBS。
一般来说，如果软件组织经常性地在某一行业或某一类产品中重复多个项目，则项目过程的重合度比较高，较适合采用类比法。
3.2工作分解词汇表
WBS编码
活动名称
过程
结果
责任人
1.1
确定系统需求
组员进行系统调查与需求分析
需求分析报告和系统设计初步方案
黄
1.2
点餐系统客户端初步设计
组员进行点餐系统的客户端页面的设
客户端页面设计图，包括顾客注册及登录页面、餐厅菜品展示页面和结账界面等
1.3
点餐系统服务器端初步设计
组员进行点餐系统的服务器段页面设计
服务器页面设计图，包括订单管理页面、公告发布页面和后厨相关信息页面等
1.4
点餐系统客户端详细设计
组员根据初步设计得到的设计图，用代码实现相关功能
可使用的客户端
1.5
点餐系统服务器端详细设计
可使用的服务器端
1.6
测试及调试
组员进行对系统的整体功能、性能测试
完善的点餐系统
1.7
整体文档
组员进行整理所有文档，完成归档工作
点餐系统相关文档
升级会员 