用户需求概述.docx
《用户需求概述.docx》由会员分享，可在线阅读，更多相关《用户需求概述.docx（14页珍藏版）》请在冰点文库上搜索。
用户需求概述
ABC项目管理系统建设项目
用户需求概要说明
修订记录
版本号
修订日期
修订人
修订内容
0.1
2012-08-17
张三
初稿。
目录
第一章引言-4-
1.1编写目的-4-
1.2预期读者与阅读建议-4-
1.3文档结构-4-
1.4术语定义-5-
1.5参考资料-5-
第二章业务需求概述-5-
2.1业务背景-5-
2.2业务目标与愿景-5-
2.3主要用户角色-6-
2.4主要功能-6-
2.4.1知识管理-6-
2.4.2评审管理-6-
2.4.3计划管理-7-
2.4.4议题管理-7-
2.4.5人员信息管理-7-
2.4.6KPI采集与统计-7-
2.4.7邮件集成-7-
2.4.8统一身份认证-7-
2.5业务环境-7-
第三章项目范围与限制-8-
3.1项目范围-8-
3.2假定与约束-8-
3.3重大风险-9-
第四章接口与非功能需求-9-
4.1用户体验需求-9-
4.2外部接口-9-
4.3性能-9-
4.4安全-9-
4.5可用性-10-
4.6其它用户指定需求-10-
第五章附录-10-
5.1市场上已有项目管理产品分析-10-
5.2知识管理概念与系统-10-
5.3议题（Issue）管理概念与系统-11-
第一章
引言
本章为本文档的导读说明。
一.1编写目的
本文档是在项目早期，基于与客户的初步沟通而总结的概要性需求文档。
项目组将基于此文档做出初步的项目估算和计划。
并基于此制定详细的需求细化方案，完成项目需求规格说明书。
本文档是关键的项目基线文档之一。
本文档重点在于完整的描述用户需要的最终愿景，因此会有部分需求超出本项目的实施范围。
一.2预期读者与阅读建议
本文档中会以“本项目”指代ABC项目管理系统建设项目；以“本系统”指代本项目所要建设的系统，即ABC项目管理系统。
由于本项目要建设的系统本身的业务功能与项目管理紧密相关，请读者注意区分本项目与需求描述中的项目。
本文档主要针对如下读者
预期读者
阅读建议
项目领导小组
仔细阅读全部内容，确认最终愿景与项目范围，并签字生效。
评审专家组
仔细审阅全部内容，确保需求描述正确完整，范围界定清晰，假定、约束、限制、例外等条款合理完整。
业务分析师
仔细阅读全部内容，以便制定详细的需求细化方案。
系统设计师
仔细阅读全部内容，开始系统架构设计与关联产品选型
开发工程师
了解文档内容，熟悉项目背景。
测试组长
仔细阅读全部内容，估算测试人月，制定测试计划。
测试工程师
了解文档内容，熟悉项目背景。
一.3文档结构
本文档章节结构如下。
●第一章引言，指导用户阅读本文档。
●第二章业务需求概述，整理描述当前已经了解的业务需求。
●第三章项目范围与限制，详细说明本项目的工作范围。
●第四章接口与非功能需求：
整理并描述当前已经了解的接口、用户体验/用户界面、性能、案例、可用性等非功能需求
●第五章附录，对本项目涉及到业界产品、技术与概念进行澄清说明，补充说明本项目的意义与范围。
一.4术语定义
术语
解释
WBS
工作分解结构（WorkBreakdownStructure），一种标准的项目计划细化方法
SMART
S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound，一种制定目标的原则
知识管理
请参见附录
议题管理
请参见附录
KPI
关键指标
一.5参考资料
本文档写作过程中，参考了如下资料。
●《ABC项目管理系统立项报告》
●历次售前沟通会议纪要。
第二章业务需求概述
本章从用户和业务的角度描述本系统（即ABC项目管理系统，下同）应实现的愿景和目标进行描述。
二.1业务背景
ABC信息技术公司主要业务是进行企业应用IT系统的研发和服务。
项目是公司主要的交付方式。
应用软件开发类型的项目数量最多，其次的IT基础设施部署与运维服务。
公司目前项目管理的电子化工具使用比较零散，主要是电子邮件、Word、Excel，部分项目经理会局部的使用Project，OneNote,OnePath等MirosoftOffice套件。
这种方式自动化程度低，协同工作和过程管控的难度很大，也无法对项目的工作量、成本等进行准确的统计。
因此，公司期望建设一个项目管理系统，提高工作效率、优化协同方式、加强过程的规范程度。
二.2业务目标与愿景
本系统应极大提高ABC公司项目的管理和协同效率。
项目执行中的各类关键信息能及时便利的推送给各类干系人，消除工作沟通中的信息不一致现象。
项目中产生的各类关键文档和知识能有效的保存和分享。
本系统所提供的信息，应足够公司管理人员和新项目成员快速了解项目的情况。
项目管理人员可借助本系统制定、更新项目计划。
本系统可帮助团队简单明了的进行日常任务的分派与跟进。
本系统还可基于系统内已有数据，提供各类KPI统计。
按照制定目标的SMART原则，本系统必须实现业务目标如下：
（1）支持项目团队无缝协作。
（2）支持项目人员在办公室，家里和客户现场三种典型环境下的协同工作。
（3）有效提升协同工作的自动化程度和效率。
（4）支持项目计划的制定与持续调整。
（5）支持项目的过程审计、KPI采集与度量。
（6）支持任务、风险与问题的管理与跟进。
（7）支持项目文档及相关知识的共享与管理。
（8）支持项目相关的流程定义和管理。
（9）使项目相关的知识都尽可能的集中管理和访问。
二.3主要用户角色
本项目交付系统的主要使用者包括11类角色。
●项目管理人员，如项目经理、开发组长，测试组长。
●项目成员，如业务分析师，开发工程师，测试工程师。
●公司管理人员，如公司领导、技术评审委员会。
●关联部门管理人员，如研发经理，测试经理，销售经理。
二.4主要功能
本节展开描述本系统的主要用户功能需求。
二.4.1知识管理
对项目相关的文档、资料、音视频等知识载体进行有效管理和保存。
应当支持这些知识的协同开发，版本控制，权限控制。
用户应可方便的在系统中记录项目相关的各种知识，如文档、纪要、讨论、心得等。
应当支持大量知识内容的快速获取，全文搜索和标签化管理是这方面比较好的实践。
二.4.2评审管理
项目过程中的关键文档具有多种状态，如草稿、待评审、已批准、已基线等。
本系统应能清楚的记录和显示这些状态。
本系统应能定义多种文档的审批流程。
在关键的文档评审环节，应提供全方位的支撑。
审批时，可能将多份文档作为一个整体进行审批。
二.4.3流程管理
本系统应当支持项目相关的流程管理，允许用户自定义流程，如不同文档的审批流程。
项目的总体流程等。
二.4.4计划管理
支持制定各种类型的项目计划，包含WBS分解、任务依赖、关键路径、资源分派、里程碑等。
由于此部分人工工作量很大，必须有很好的用户体验。
最好能提供类似MicrosoftProject的客户端。
应尽可能将项目计划与议题管理在本系统中对照起来。
项目过程中计划的修订非常频繁，本系统最好能平滑支持此种修订，至少不能增加修订的成本。
二.4.5议题管理
本系统应能采用议题管理的方式，对如下议题类型进行有效管理：
需求、缺陷（Bug）、问题、风险、日常任务。
本系统必须支持自定义议题类别、内容与流程。
二.4.6人员信息管理
可对项目成员的信息进行有效的管理，方便项目组成员互相熟悉、增加团队融合度，也方便组外人员了解项目的人员情况。
这些信息包括但不限于：
联系信息、项目中的角色、个人特点、相片。
二.4.7KPI采集与统计
可按CMM/ISO2000等体系需求，基于系统内可采集的数据统计项目KPI，如项目规模、缺陷率、生产效率、挣值等。
二.4.8邮件集成
邮件系统是公司员工使用的首要沟通与信息传递工具。
本系统应提供强大的邮件集成功能，至少要可以通过邮件获取本系统中的项目关键信息的更新提醒。
此外，期望可以通过邮件向本系统发送更新内容。
期望尽可能将邮件中与项目相关的内容汇集在本系统中。
二.4.9统一身份认证
本系统应支持用户使用公司域账号（或邮箱账号）登录。
原则上不建议在本系统中新建用户。
但本系统应拥有完整的权限管理机制。
二.5业务环境
●公司项目实施人员约为100人。
可能在办公室，客户现场或家里访问本系统。
●公司主要业务在中国，不涉及国际化运营和多时区。
●公司同时实施的项目约为20个。
大型项目数量较少，中小型项目居多，基于产品的微型项目数量也较多。
●大型项目人数可达30人，周期为一年，各类文档可达数百份到上千份。
●中型项目人数一般在10人左右，实施周期半年左右，文档从几十份到一两百份不等。
●微型项目人数一般在1到3，实施周期一个月以内。
●与客户的沟通，主要采用邮件、电话、传真和QQ等手段。
第三章项目范围与限制
三.1项目范围
本系统的规模很大，难以在一期项目建设中全部完成，根据双方协商，本系统建设的总体路线图是：
首先选择合适的项目管理平台，然后基于平台搭建整体系统，最后逐个模块深化。
本项目为本系统的第一期建设，必须完成如下工作。
（1）从市场上较成熟的产品中，选择基本的平台产品，至少提供知识管理与议题管理的主体功能。
（2）组合、定制基本平台产品，形成完整的项目管理系统。
（3）完整实现一套项目流程，如V模型或Scrum模型。
具体模型定义在后续文档中明确。
本系统在后续建设中，应能继续开发如下功能。
这些功能不强制要求在本项目范围内。
（1）与特定的软件开发平台整合，如Eclipse、VisualStudio。
可自动统计每项任务的工作量和影响范围。
（2）与公司综合管理平台整合，为员工考核、项目管控提供数据支持。
（3）增加项目估算功能，如功能点法或代码行法。
三.2假定与约束
（1）从外网访问本系统，必须通过公司规定的VPN平台。
（2）公司邮件服务器可为本系统提供专有邮箱账号。
本系统通过标准协议调用公司邮件服务。
（3）公司域账号的身份管理采用AD方式。
（4）项目流程的详细定义由公司技术管理委员会负责提供和解释。
（5）本系统应当基于成熟的应用平台进行二次开发。
（6）本项目所设计的流程，仅针对应用软件研发类型的项目。
（7）本项目不涉及软件的分析，设计和开发工具。
（8）本项目只开放给有公司员工账号的项目成员。
三.3重大风险
本项目目标系统的同类产品较多，如最终产品设计与这些同类产品区别不大，可能导致项目失败。
用户对操作和体验方面的要求较高。
本项目可能选择基于一些成熟的基础平台来定制开发。
这些基础平台的用户体验水准会极大的影响用户对最终产品的满意度。
本项目有KPI采集的要求。
不同的KPI采集难度差很大，需要在设计中明确。
第四章接口与非功能需求
四.1用户体验需求
●本系统管理功能应采用B/S方式。
●因在浏览器中打开文档等附件的方式不方面，应尽量回避这种方式。
●议题管理中的所有描述信息应支持图文并茂的编辑与展现形式，推荐采用RTF或Wiki格式。
●如采用在线文档作为项目的主要文档形式，应支持离线创作与修改。
四.2外部接口
●本系统应能从公司的域服务器获取用户账号信息。
●本系统应能通过公司的邮件服务器收发邮件。
●本系统所有议题可按指定的接口方式与第三方系统交互，比如在Eclipse中显示和操作任务项。
●本系统所有统计数据可以指定的接口方式与第三方交互，比如输出缺陷率和生产效率到绩效考核系统。
四.3性能
本系统应能支持300人的总用户数。
在公司内网环境下，所有页面的响应时间在3秒以内。
四.4安全
本系统是公司未来主要的知识库和项目文档库，必须有高度的存储安全与保密措施。
四.5可用性
本系统每天应保证23小时可用。
允许累计1小时的停机维修，但单次停机不得超过30分钟。
四.6其它用户指定需求
本系统无其它用户指定需求。
第五章附录
五.1市场上已有项目管理产品分析
目前市场上项目管理的系统和产品很多，功能差异显著。
按其类别可分为：
单机产品、服务器产品和在线产品。
单机产品的的代表是MicrosoftProject。
但它只能在项目计划与跟踪方面满足本平台的需求工具。
缺乏协同功能，知识管理功能等。
服务器产品一般采用B/S结构，可细分为两类。
第一类基于协同门户产品构建，代表产品有MicrosoftSharePoint,LiferaySocialOffice。
第二类是基于议题管理平台构建,代表产品有@Task,JIRA产品族，Redmine。
这两类产品由于理念不同，都不能很好的支持另一类产品的功能，所以都没具备完整的项目管理功能。
在线项目管理产品是近年来兴起的SaaS应用，代表产品有ZohoProject（中国区产品名为百会项目），Fogbugz。
这类产品一般都源自基于任务管理的服务器产品。
功能相对完整，用户体验也好一些。
但目前企业对SaaS服务信息安全有较大的担心，故而市场不成熟。
此外，这类产品不提供客户端，在项目计划这个环节的用户体验很差。
本项目定义的系统，应以服务器产品为要参照，融合两类服务器产品的长处。
充分考虑信息技术公司和软件研发型项目的具体诉求。
五.2知识管理概念与系统
对知识及其载体进行全生命周期的管理，包括知识的创造、生产、保存、分享、发布和获取等。
这里的知识主要是指文档、网页、Wiki、讨论、课件、图片、视频、音频等各种人工创造和生产的内容。
知识管理是从早期的文档管理、内容管理概念中升华而来。
从文档管理到内容管理，再到知识管理，最显著的区别有两点：
知识种类越来越多，生命周期的管理越来越完整。
早期文档管理只关注PDF、TXT、DOC等文档，与Windows文件管理器的理念相同。
内容管理则扩展到基于网页的非结构化内容，如博客、Wiki，论坛、图片等。
知识管理在前两者的基础上，作了三个方面的各类扩展：
l专有知识载体，如课件、视频、笔记。
l结构化内容，如列表、清单、通讯录
l关联内容，如针对主内容的批注、评语。
在生命周期的管理方面，早期的文档管理重点关注版本控制、权限管理。
内容管理扩展到在线协同创作、审批发布流程管理。
知识管理除了全面增强了文档管理和内容管理的原有功能，重点提高的知识的分享与获取的便利性。
搜索、标签、SNS等技术的利用是知识管理的重要特点。
五.3议题（Issue）管理概念与系统
这里的议题管理，源自英语中的IssueManagement。
议题是指在项目实施过程中出现的各类问题、风险、缺陷，功能点、任务等需要清单化管理的对象。
它们的共同特点是：
l在相关的管理系统中，同一类议题以表格的方式汇集在一起。
l每一个议题项的本质就是一项需要处理的任务。
事件也是一种任务。
l每一个议题项都有明确的结构化内容，如标题、描述、优先级、负责人等。
l每一个议题项都有明确的状态标识和流程控制。
l对议题的数量统计可以清楚的反应出项目的状态，因而很受管理人员的重视。
传统的项目管理解决方案，对于不同的议题类型，采用了完全不同的管理方式。
比较好的典型的做法是：
l缺陷管理放在Bug系统中，采用议题管理机制。
l需求及其变更放在文档中，采用基于文档和邮件的管理机制。
l风险与问题放在风险登记表中，采用基于文档的半手工议题管理机制。
l其它各类任务放在项目计划中，采用WBS式的管理机制。
这种区别管理的方式，使得项目团队需要同时面对多份任务列表，经常顾此失彼。
如果项目经理的计划与控制能力不是非常好，或投入到计划与分派工作的精力不够，就出现遗漏关键任务、或做出不当承诺等失误。
同样，这种方式加剧的计划变更的突然性，对于团队成员的自我调整能力要求也很高。
在上述几中方式中，管理缺陷的Bug系统采用了清单化管理方式，简单明了。
业界逐渐基于这个套路，把需求变更、用户需求、日常任务、问题、风险等先后融入到同一平台，形成了议题管理平台。
继而在议题管理平台基础上，增强计划功能，增加内容管理和团队管理功能，形成了基于议题管理平台的项目管理系统。
这类系统的突出优点是：
l项目主要人员只需面对一两份任务清单。
l可灵活定制不同的议题类别的内容和流程。
有利于项目的精细化，规范化管理。
l无需复杂设计，就可自动生成准确的图表，表明项目的各种状态。
议题管理注重扁平的清单管理，对多级任务分解的支持较弱。
因此不能完全取代基于WBS的项目计划产品。
反之，由于WBS项目计划的颗粒度比议题管理的要大很多，WBS项目计划也不能完全取代议题管理。
项目经理仍需在项目计划和议题管理间进行人工对照。
升级会员 