用户需求概述

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