项目管理系统优化愿景
一、背景：
随着服务销售业务的迅速发展，原先的项目管理系统已经无法满足公司（国内及海外）及办事处/地区部的业务运作需要，急需进行系统优化。
二、愿景：（通过优化最终做到）
1、办事处/地区部、服务营销部、海外服务销售部、公司相关领导能及时掌握相关信息，
为决策、分析提供相关数据；
2、能够实现将信息管理、项目日常管理、项目监控、数据统计分析、业务经理考核、
总结计划等管理功能在一个平台上实现，减少不增值环节。
3、相关数据自动生成，减少公司及办事处/地区部一线销售人员的工作量，提高工作效
率。
三、项目管理系统优化总需求：
1、项目实时监控（从宣传引导到回款完成）；
2、相关信息提供（服务产品信息及资料、竞争对手信息、已回款信息等）；
3、业务数据统计；
4、月度、季度工作总结与计划；
5、项目总结与案例；
四、使用人群：
1、办事处：技术支援主任、服务业务经理、服务经理、秘书、产品经理
2、地区部：地区部主管、地区部服务业务经理、秘书
3、公司：相关部门主管、服务营销部人员、服务产品开发部人员、商务部人员、服务
策划部人员
五、项目管理系统优化具体需求：
导航区内容备注
国内服务销售管理、海外服务销售管理国内要分办事处，海外要分地区部及办事处。海外与国内的基本结构一样，只是部分内容进行调整。
有偿服务氛围营造实现公司、办事处在有偿服务宣传方面的统一的调度与管理
准项目一览表能分办事处、分产品线、分产品查询与统计，并有详细进展情况，模版见附表1运作项目一览表能分办事处、分产品线、分产品查询与统计；增加监控、沟通及邮件自动通知功
能，模版见附表2
回款跟踪一览表能实现对合同签订后的回款情况的详细查询及应收款提醒功能，模版见附表3已归档项目一览表能详细查询已归档的所有项目情况
统计增加灵活的统计功能，能按产品进行统计；
服务销售信息增加服务产品信息及竞争对手信息与资料；
月度与季度总结与计划要求有项目管理周报、月度及季度总结与计划，最好通过简单填写就能自动生成
WORD文档；
项目总结及案例便于办事处经验共享；
1.“有偿服务氛围营造”详细需求：
●能分公司、北京分部、办事处按季度显示；
●分服务理念交流与宣传、服务产品交流与宣传、客户关系建设与维系三部分，要求
有详细规划及具体的实施计划与总结；能粘贴办事处与客户的交流纪要或总结；
●能对办事处有偿服务氛围营造情况按照标准进行自动打分；
2.“准项目一览表”详细需求：
●在导航区中增加“准项目一览表”，对立项前的“准项目”进行录入，并进行有效
监控。这样可以避免原先对项目立项前的监控管理不力问题，同时也可以解决办事处因为担心考核时录入项目太多影响项目成功率而不录入项目的问题（成功率=成功的项目数/立项的项目数）；
●系统能自动分办事处（含北京客户群总部）、分产品线（五个）、分产品（首层：维
保、基础服务、专业服务、培训咨询、备件；维保下一层：一般维保、外购件维保、协维、代维；基础服务下一层：拆移机、升级等；专业服务下一层：系统安全、存储备份、网络优化等）进行查询与统计，可以对于没有的分类由管理员进行自定义添加；
●在准项目阶段，点击“立项”后，相关数据及资料可以自动转换到立项项目中，在
准项目一览表中不再存在。
●对于一些在准项目阶段就失败的项目，点击“取消”，并填写失败原因分析后，则
系统自动进行归档。
●增加关键字项目查询功能；
●系统能自动邮件通知相关人员。
附表一（以国内为例）：
●可以不通过准项目阶段直接立项；
●能分办事处（含北京客户群总部）、分产品线、分产品分别查询与统计。分产品时，
首层分维保、备件、专项。其中维保再分为一般维保、代维协维、外购件维保。专
项下面要再细分为基础服务、专业服务、咨询培训等；
●强化对项目运作的监控指导功能，增加项目自检及对口业务领导指导内容；
●增加项目运作中的自动邮件提醒通知功能；
●若点击“签单”，则须录入合同相关信息后进入回款跟踪一览表，同时系统将相关
过程文档按照项目编码进行自动归档（项目编码在首次填写准项目时由系统自动按
顺序生成）；若点击“失败”则需填写失败原因分析后，再进入归档项目一览表；
附表二：
办事处客户名称项目种类普通项目/重大项目立项时间刷新时间项目责任人项目编号
●在项目运作一览表中点击“签单”后进入回款跟踪一览表，填写人员必须全面填写
相关信息后方可退出；
●最好能与财务相关系统相连（以合同号），否则需人工导入或录入到款情况。系统
会实现以邮件方式自动提醒回款责任人应收款情况及到款情况，提醒回款责任人回
款；
●回款完成后，责任人点击“归档”，则系统将回款的相关信息再次归档入“已回款
项目一览表”
附表三：
办事处客户名称合同编码签定时间合同签定人原项目编号
5.已归档项目一览表详细需求：
●能分办事处、分产品线、分产品查询归档项目的详细信息及过程文档；
●未完成回款的项目，在已归档项目一览表中也能查询到，并且其相关文档中包含回
款跟踪一览表；
●能分年度、分季度显示；
●“本合同回款率”=本合同各次已回款金额之和/本合同金额
6.“统计”部分的详细需求：
●有每办事处季度考核目标，由服务营销部每季度初负责导入；
●能为考核提供数据，如：支撑率、成功率、回款率、闭环率等；
某办事处本季度维保目标支撑率=该办事处计划在本季度落单的维保“运作项目”预计金额之和/该办事处本季度维保目标*100%。
外购件维保、专项、专业、备件、培训的目标支撑率依此类推。
某办事处本季度项目成功率=该办事处本季度归档的成功项目数/计划本季度落单的项目数*100%。
回款率=本年度合同中已回款金额之和/本年度目前合同应收款金额。
某办事处本季度项目闭环率=本季度归档项目数/本季度项目总数。
●能实现灵活的统计查询功能，如：查询某办事处的项目支撑情况（需要有维保、专
项、备件等的细分）、某产品的全国项目支撑情况、某产品线的项目支撑情况等等；
7.“服务销售信息”部分的详细需求：
●增加服务产品介绍及相关资料内容，办事处可以远程下载；
●增加设备过保续签信息内容，并实现系统自动提醒相关人员准备续签；
8.周报、月度与季度总结与计划：
●实现服务业务经理的月度工作总结与计划、季度工作总结与计划在系统中的粘贴提
交。系统可以定时邮件提醒并提供模版；
需求说明书（软件项目管理系统） §1、前言 1.1概述 1.1.1 项目名称：软件项目管理系统 项目代码：ProjectManager 1.1.2 开发目的：本系统应能 a．管理软件项目和项目组； b．管理与项目相关的数据项和数据结构； c．管理与项目相关的系统功能描述和分组； d．管理与项目相关的项目任务和项目任务进度； e．管理与项目相关的问题，并且能进行问题跟踪； f．管理与项目相关的文档。 1.1.3 相关读者：部门经理，项目经理，测试人员，设计人员，编程人员。 1.1.4 本项目与其它产品（软件）关系。 1.2术语 本分析书所使用的专门术语定义： 部门经理——能建立项目和项目组的系统使用者； 项目经理——能进行§1.1.2.b - §1.1.2.f管理的系统使用者； 设计人员——能进行§1.1.2.b - §1.1.2.f管理的系统使用者； 编程人员——能进行§1.1.2.d - §1.1.2.f管理的系统使用者； 数据项——目标系统中的最小信息单位； 数据结构——数据项的有意义集合； 系统功能——通过目标系统能完成的有效活动； 项目任务——开发项目中要求完成的有效活动； 1.3参考资料 列举编写本分析书时所参考资料的详细信息、标题、作者、版本号、发表日期和来源等。 1.4运行环境 操作系统：Windows 2000 Professional； 数据库：MS SQL 2000 或Oracle。 1.5条件和限制 开发环境：Microsoft Visual Studio .NET 2003； 使用工具：C# §2、系统需求 1.1 功能说明 根据用户编码和用户密码校核该用户是否合法； 在校验用户密码后，可修改用户自己的密码；
酒店订房管理项目 项 目 说 明 书 荆州市职业技术学院国际信息技术学院 撰写：GX1202全体参赛人员 班级：GX1202
1项目背景 1.1目的 酒店客房管理系统在正常运营中需要对客房资源、客人信息、结算信息等进行管理，利用酒店客房管理信息系统对客房的各个操作进行管理,能够及时了解各个环节中信息的变更,有利于提高管理的效率 1.2 背景 组织本届软件编程大赛旨在激发武汉厚溥教育科技有限公司各合作院校学生学习软件知识的热情、运用软件技术的兴趣、检验软件编程的水平、推动软件产品的应用、提高学生的实际开发能力。同时通过此次大赛，期望激励学生的创新精神、团队合作精神、加强动手能力、培养创造能力、提高学生综合能力及社交能力、促进学生对软件开发的兴趣以及各合作院校计算机技术专业教学的交流与合作。 1.3运行环境 客户端：手机系统android 2.3以上,支持重力感应功能,手机内存10M以上. 前台及后台管理：cpu:奔腾4 1.6Ghz 内存:256M 硬盘:300M空余空间显卡无要求网络要求：最低56K Modem 操作系统：Windows 2000/xp/7 响应时间：<2s 存储速度：<4s 网络通信功能：联网实时更新,最低56k Modem. 开发环境：系统基于Java和MySql 的windows xp/7环境下. 以上以及更多
第二章项目整体需求概述 酒店订房大致框架图： 项目需求详细说明： 1.我们采用现在最流行的移动式设备手机为客户端,群体比较大,推广度比较强, 为酒店能够带来质的突破,解放了人力订房的千年陈规,可以实现远程登录 服务器订房,适合白领人群,搭车过车中都可以订房,节省时间 2.到达酒店后前台服务人员会询问您是否订房，如果有通过客户端订房的可以省 去一些步骤,通过前台直接可以入住,省去登记时间和流程,更快更高效 3.如果客户对于房间不是非常满意可以通过客户端提出换房的要求,只能换房三 次,如果超过三次换房,系统会默认扣除押金,也可以直接到前台提出换房或 者是退房要求,不收取任何手续费用 4.入住酒店之后可以选择给予该酒店服务,硬件设施等进行评价
项目管理：怎样做需求分析 如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。 获取用户需求 这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动（如图1所示）。 ●了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。 ●对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。 ●需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由； 图1 获取用户需求的活动
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”； ⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。 ●需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动： ⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）； ⑵使需求符合系统的整体目标； ⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。 分析用户需求 在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动： ●以图形表示的方式描述系统的整体结构，包括系统的边界与接口； ●通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价； ●系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等； ●以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。
项目管理应以需求为核心 这段时间，一直在负责一个项目的管理与开发。在时间短、任务紧，而团队人员又大部分是没有经验的菜鸟的恶劣情况下，我带领接近40人的团队，终于在客户规定的时间范围内如期交付产品。这其中，经历了需求变更、人员变动(因为其它任务，先后有近10人离开团队)等诸多问题，项目仍然取得成功了，不能不说有几分侥幸，但此外也有一些经验与教训可以与大家分享。 项目开发方面 需求 项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于EAS项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。 需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。EAS项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。
项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。从EAS项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。 项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。EAS项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。 注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。 注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了EAS项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。
I T项目管理需求分析说 明书 内部编号：（YUUT-TBBY-MMUT-URRUY-UOOY-DBUYI-0128）
IT项目管理需求分析说明书
目录 1.第一章引言 1.目的 本软件分析报告的目的是对根据客户的需求，对系统功能、性能需求向××客户、项目组开发成员、项目实施组和测试成员提供一个清晰的陈述。对IT项目管理功能的后续阶段等过程提供指导和工作原则。 2.IT项目管理内容简介 2.1.按管理目标 从IT项目管理的目标来看，IT项目管理需要管理项目费用/预算和项目过程。 项目费用/预算管理：对于项目费用/预算要求做到能够即时的查 询到本年度或者历史年度的预算以及费用付款情况，需要明细到 分公司的付款情况。目前具体的管理方法是由省局信息中心制定 编写年度预算，项目立项后制定付款计划。分公司实施付款计 划，在每次付款完成后将付款记录录入到系统中，省局信息中心 负责汇总。主要涉及到的文档/数据有，IT项目年度预算表，项 目立项表，项目付款计划，分公司付款记录，年度付款情况（报 表）。 项目过程管理：对于项目的过程要求能过做到能够将项目过程管 理中产生的文档/数据做统一的管理，在需要的时候能够随取随
用。并且做到能够查询到本年度或者历史年度计划的项目和实际 实施的项目对比报表。目前具体的管理办法是省局统一立项，制 定全省推广计划，分公司根据推广计划实施推进项目计划。主要 涉及的文档/数据有，IT项目立项表，全省计划表，计划明细表 （工作项/里程碑），招标表，合同表，年度项目完成情况（报 表）。 2.2.按IT项目的进程阶段 ××局的IT项目管理可以分为以下几个阶段：年度规划，项目立项，招投标管理，项目启动\建设，项目维护，每个阶段有特定的事务和对象需要处理，每个阶段又有特定的里程碑点来控制整个项目的进程。 1、年度计划：这个阶段主要是省局信息中心根据省局的各个部门和各地 市公司提交的信息化要求，和烟草局本身发展的需要，编制下一年度的IT项目预案，一般在三季度完成。涉及对象主要是IT项目年度计划。 2、立项管理：信息中心根据实际情况，在年度计划中挑选项目进行立 项，编制定立项表，招标表，合同表等。如果不在年度计划中的项目需要立项的话，要求先将其添加到年度计划中才能立项。 3、招投标管理：这是一个特殊的环节，管理项目中需要招投标的事务， 主要是管理招标表，甚至保留招标内容。一个项目中可能会有多个招标事务。招标完成和由省局和中标单位签订合同，也可能会要求各个
软件项目管理之需求分析 需求分析是项目开发的基础，所以在进行软件项目开发之前，我们必须要了解下用户的需求是什么，避免在投入大量人力、物力、财力、时间等之后，开发出来的软件没人要。本文将从需求分析的过程、层次、需求开发阶段的重点以及需求分析的任务做详细介绍： 1.需求分析的过程 需求过程包括需求开发和需求管理2个部分： (1)需求开发就是对开发前期的管理，与客户的沟通过程，可以分为4个阶段：需求获取、需求分析、编写需求和需求验证。 (2)需求管理：就是软件项目开发过程中控制和维持需求约定的活动。包括：变更控制、版本控制、需求跟踪、需求状态跟踪。 2.需求的层次 需求的层次包括：业务需求、用户需求、功能需求、非功能需求等4个方面。 3.需求开发阶段的重点 (1)提取业务对象 业务对象是指系统使用的真实对象，例如一个供应链管理(简称SCM)业务对象主要包括：生产批发商、零售商、送货商、顾客多个层次。 (2)提取业务流程 在了解业务逻辑的过程中，应该列举出所开发软件模块的各自职能，并细化每个工作流程，深入分析业务逻辑。 (3)性能需求 在分析的前期应该注意客户对所开发软件的技术性能指标，如存储容量限制、运行时间限制、安全保密性等。 (4)环境需求 环境需求是指软件平台运行时所处环境的要求，如硬件方面：机型、外部设备、数据通信接口;软件方面：系统软件，包括操作系统、网络软件、数据库管理系统方面;使用方面：使用部门在制度上，操作人员上的技术水平上应具备怎样的条件。
(5)可靠性需求 对所开发软件在投入运行后发生故障的概率，应该按实际的运行环境提出要求。对于重要的软件，或是运行失效会造成严重后果的软件，应提出较高的可靠性要求。 (6)安全保密要求 在需求分析时应当在这方面恰当地做出规定，对所开发的软件给予特殊的设计，使其在运行中，其安全保密方面的性能得到必要的保证。 (7)用户界面需求 为用户界面细致地规定到达的要求。 (8)资源使用需求 开发的软件在运行时和开发时所需要的各种资源。 (9)软件成本消耗与开发进度需求 在软件项目立项后，根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。 (10)开发目标需求 预先估计以后系统可能达到的目标，这样可以比较容易对系统进行必要的补充和修改。 4.需求分析的任务 需求分析的主要任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型，其流程如下： (1)确定对系统的综合需求(功能、性能、运行、扩充需求) (2)制作产品需求文档(PRD) (3)分析系统的数据需求(概念模型、数据字典、规范化) (4)导出目标系统的详细的逻辑模型(数据流图、数据字典、主要功能描述) (5)开发原形系统 (6)从PRD提取编制软件需求规格说明书(SRS) 总之，需求分析的任务就是解决“做什么”，在准确表达所接受的用户需求以后，根据用户需求来设计软件，避免我们开发出来的产品客户不要。
一、技术要求 工作条件 1．除非在技术规格中另有说明，所有仪器、设备和系统都应符合下列要求：2．适于在气温为摄氏0℃～＋40℃和相对湿度为90％的环境条件下运输和贮存。 3．适于在电源220V（ 10％）/50Hz、气温摄氏-5℃～＋40℃和相对湿度85％的环境条件下运行。连续正常运行的时间应不少于8小时。 4．配置符合中国有关标准要求的插头，如果没有，则需提供适当的转换插座。 5．如产品达不到上述要求，供应人应注明其偏差。如仪器设备需要特殊工作条件（如水、电源、磁场强度、温度、湿度、动强度等）供应人应在供应文件中加以说明。 其它要求： 1．为便于采购人进行接收仪器的准备工作，成交供应商应在合同生效后60天内向用户提供一套完整的使用说明书、操作手册、维修及安装说明等文件。另一套完整上述资料应在交货时随货包装提供给采购人，这些费用应计入总报价中。 2．对于需安装、校准、试运行的仪器设备，如果有必要的安装准备条件，成交供应商应在合同生效后一个月内向采购人提出详细的要求或计划。设备安装调试的费用由供应人承担，需计入成交总价中，并应单独列出，供采购人参考。 3．对于人员培训所需的仪器、设备，供应文件中应注明。 4．对于在采购人所在地进行的培训，供应人培训人员的旅费、食宿费用等费用由供应人自理。 5．对于需到制造厂家所在地进行的培训，供应文件中将注明培训日程和时间要求。受训人员的旅费、食宿费、培训场地费及培训资料费等培训费用均应由供应人支付。 6．在评审过程中，谈判小组有权向供应人索取任何与评审有关的资料，供应人务必在接到此类要求后，在规定时间内予以答复。对于无答复的供应人，谈
北京师范大学珠海分校管理学院 项目管理说明书 ——开发聊天软件 生存期中的各阶段定义如下： 项目规划阶段 阶段目标：根据初步的需求分析，确定项目的规模、时间计划和资源需求 输入：要求文本， 过程：项目规划，计划确认 输出：项目计划 需求分析阶段 阶段目标：确定客户的需求 输入：项目计划，SOW 过程：需求获取，需求分析，需求控制 输出：原型系统，需求规格 设计阶段 阶段目标：总体系统结构设计 输入：原型系统，需求规格 过程：总体设计 输出：系统设计说明书，数据库结构定义 增量1实现 阶段目标：实现系统的登录功能 输入：系统设计说明书，数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试
输出：详细设计说明书，源代码，可运行版本-1 增量2实现 阶段目标：实现系统的聊天功能 输入：系统设计说明书，数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本-2 增量3实现 阶段目标：实现系统的信息管理功能 输入：系统设计说明书，数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本-3 增量4实现 阶段目标：实现系统的文件传输管理功能 输入：系统设计说明书，数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本-4 集成测试 阶段目标：通过集成环境下的软件测试 输入：测试计划，测试用例 过程：集成测试，系统测试 输出：系统软件包，测试报告，产品说明书 产品提交 阶段目标：产品可投入使用 输入：系统软件包 过程：产品提交 输出：验收报告 2）资源配置情况： 人力资源： ?1个管理人员 ?2个开发人员 ?4个测试人员 ?2个设计人员 ?2个需求人员 设备资源： ◆3台电脑 ◆1台服务器
医院管理系统项目需求分析 目录 1引言 ............................................................................................................................................ 错误!未定义书签。 1.1编写目的......................................................................................................................... 错误!未定义书签。 1.2适用范围......................................................................................................................... 错误!未定义书签。 1.3背景................................................................................................................................. 错误!未定义书签。 1.4术语定义......................................................................................................................... 错误!未定义书签。 1.5参考资料......................................................................................................................... 错误!未定义书签。2项目概述..................................................................................................................................... 错误!未定义书签。 2.1目标................................................................................................................................. 错误!未定义书签。 2.2用户特点......................................................................................................................... 错误!未定义书签。3功能需求..................................................................................................................................... 错误!未定义书签。 3.1流程图............................................................................................................................. 错误!未定义书签。 3.1.1门诊管理流程图................................................................................................. 错误!未定义书签。 3.1.2住院管理流程图................................................................................................. 错误!未定义书签。 3.1.3药库药房流程图................................................................................................. 错误!未定义书签。 3.2功能表............................................................................................................................. 错误!未定义书签。 3.3用例................................................................................................................................. 错误!未定义书签。 3.3.1门诊管理用例图................................................................................................. 错误!未定义书签。 3.3.2门诊管理用例说明............................................................................................. 错误!未定义书签。 3.3.2.1门诊挂号人员登录：......................................................................................... 错误!未定义书签。 3.3.2.2门诊挂号人员修改密码：................................................................................. 错误!未定义书签。 3.3.2.3门诊挂号人员对挂号单的录入：..................................................................... 错误!未定义书签。 3.3.2.4门诊挂号人员对挂号单的查询：..................................................................... 错误!未定义书签。 3.3.2.5门诊挂号人员退号：......................................................................................... 错误!未定义书签。 3.3.2.6门诊挂号人员退出登录：................................................................................. 错误!未定义书签。 3.3.2.7门诊挂号人员结算：......................................................................................... 错误!未定义书签。 3.3.2.8门诊划价人员登录：......................................................................................... 错误!未定义书签。 3.3.2.9门诊划价人员修改密码：................................................................................. 错误!未定义书签。 3.3.2.10门诊划价人员对处方的录入：....................................................................... 错误!未定义书签。 3.3.2.11门诊划价人员对划价单的查询： ................................................................... 错误!未定义书签。 3.3.2.12门诊划价人员退出登录：............................................................................... 错误!未定义书签。 3.3.2.13门诊收费人员登录：....................................................................................... 错误!未定义书签。 3.3.2.14门诊收费人员修改密码：............................................................................... 错误!未定义书签。 3.3.2.15门诊收费人员收费：....................................................................................... 错误!未定义书签。 3.3.2.16门诊收费人员退出登录：............................................................................... 错误!未定义书签。 3.3.2.17门诊收费人员结算：....................................................................................... 错误!未定义书签。 3.3.3住院管理用例图................................................................................................. 错误!未定义书签。 3.3.4住院管理用例说明............................................................................................. 错误!未定义书签。 3.3. 4.1住院部管理员登录：......................................................................................... 错误!未定义书签。 3.3. 4.2住院部管理员修改登录密码............................................................................. 错误!未定义书签。
项目管理系统需求说明书
成都鼎域前沿科技有限公司 2015.4 目录 一引言 (1) 1编写目的 (1) 2范围 (1) 2.1软件系统的名称 (1) 2.2软件功能概述 (1) 二项目概述 (2) 1项目描述 (2) 2产品功能 (3) 2.1系统角色定义 (3) 2.2系统功能 (3) 3用户特点 (3) 3.1管理员及超级管理员用户 (3) 3.2企业领导、项目经理和项目成员 (4)
3.3用户使用本系统相关说明 (4) 3.4一般约束 (4) 三项目需求 (6) 1功能需求 (6) 1.1功能结构一览 (6) 1.2登陆 (7) 1.3项目管理 (7) 1.3.1项目立项 (7) 1.3.2项目新增 (7) 1.3.3项目过程管理 (8) 1.3.4项目群管理 (11) 1.4项目工具 (15) 1.4.1原因分析工具 (15) 1.4.2数据收集分析工具 (15) 1.4.3评估工具和决策工具 (15) 1.4.4TRIZ系列工具 (15) 1.5人才管理 (15) 1.6知识管理 (16) 1.7权限管理 (17) 1.7.1用户信息管理 (17) 1.7.2系统模块管理 (17)
1.7.3角色管理 (17) 1.7.4权限分配 (17) 2外部接口需求 (18) 2.1用户接口 (18) 2.2硬件接口 (18) 3性能需求 (18) 3.1静态数值需求 (18) 3.2动态数值需求 (19) 3.3硬件限制..................................................... 错误!未定义书签。4属性. (19) 4.1可用性 (19) 4.2安全性 (19) 4.3可靠性 (21) 4.4系统性能 (22) 4.5易用性 (23) 4.6可维护性 (23) 4.7其他需求 (24)
材供应部合同进行计算机的自动化管理计算，减少了管理人员的工作量，节省了人力，确保合同数据的安全和有效利用。本系统具有系统功能完备、使用简单、用户界面好、安全保密设置齐全等优点。 院实物保护监控中心安全、稳定运行 院实物保护监控中心 中国原子能科学研究院在基础设施改造一期工程中，建立了实物保护监控中心。该中心的功能在于防破坏、防盗窃，防非法转移核材料、放射源、机密档案，预防和制止敌对分子或团伙的入侵、威胁、破坏等犯罪活动，对全院的重点要害部位进行集中管理，实施24 小时不间断地布防监控。 院实物保护系统共有9 台录像机对各监控部位的图像进行录制，对院大门口和监控中心进行每日24 小时连续监控录制，对其他工号实行布防监控与录制。 中心在核技术所直接领导和院保卫处的监督管理下，坚持双人值班制度，严格规范运行记录，对涉及实物保护技防系统86 个监控点和消防报警系统1 153 个探测点的报警信号进行及时复核、确认，在第一时间通知有关部门进行处理。 在试运行至今的一年多时间内，共计处理实物保护系统报警3 万多次；消防系统报警3 千多次。在接到报警信号后，值班人员在第一时间通知有关部门进行处理，使得中心对全院重点要害部位的保卫和消防安全实施了有效的监控，体现了实物保护系统的可靠性和有效性。2006 年实物保护监控中心主要完成了以下工作。 1）严格培训，做到持证上岗。 2）建立健全运行制度，确保中心正常运行。 3）妥善处理报警信号，保障重点要害部位安全。 4）及时排除故障，确保系统有效运行。中心建成运行以来，多次妥善处理了接报警事件，充分发挥了对全院重要部位的监督管理作 用，保障了全院科研生产工作的顺利进行。 （执笔人：任宝玲） 科研项目管理系统需求分析 田君，王建平，吕建友 中国原子能科学研究院是一个大型的、综合性的核科学技术研究基地，承担核能开发、国防技术基础、国防预研、“863”和“973”、国家自然科学基金等科研项目，相关30 多个项目类别，涉及近100 个项目，其项目的研究范围涵盖了核物理、核化学与放射化学、反应堆工程技术等领域。这些科研项目涉及学科广泛，内容精深，难度高，管理模式多，工作复杂。同时，原子能院
品高项目管理系统 软件开发需求
目录 1引言 (2) 1.1编写目的 (2) 2功能性需求 (2) 2.1系统登录 (3) 2.2对内项目管理子系统 (6) 2.3对外项目交流系统 (22)
1 引言 1.1 编写目的 本文档可作为 1. 设计人员进行系统设计的输入源。 2. 开发人员对系统功能开发的依据。 3. 测试人员编写系统测试计划，测试案例编写的输入源。 4. 产品经理检查系统实现程度的依据。 5. 项目团队外人员进行沟通的外部接口，用于他们评审和理解系统。 6. 项目需求阶段的主要交付物。 7. 收集并记录所有的外部接口，以用于作为完成设计和实现系统的参考。 2 系统概貌 2.1 系统背景 随着公司发展，客户范围不断增长,项目数量多且繁杂,给公司的和客户了解项目实际情况带来很大不便,公司及客户之间缺乏有效快速的沟通交流环境. 基于上诉背景，我们提出需建立一套完善的项目管理系统，作为公司及客户之间对项目信息的了解及在线交流, 以满足公司发展的需求。 2.2 用户描述 本系统用户为我们公司业务人员、项目成员、项目经理、管理中心、财务合同管理员、部门经理，项目管理层等。 2.3 系统角色权限 系统的不同角色对信息的权限见附件表 角色权限表.xlsx 2.4 一般限制 ? 应用系统应采用B/S 结构，客户端支持IE6.0 以上的版本。 ? 应用系统的开发工具与技术应采用Microsoft .NET 的技术体系。 ? 应用系统中所有数据统一保存到SQL Server 数据库。
2.5出错处理 ?所有的应用系统错误都应记录到系统日志文件中。 ?所有的Windows服务错误都应记录到Windows服务日志文件中。 ?所有的Web服务错误都应记录到Web服务日志文件中。 2.6假设和依赖条件 ?本系统假设.Net Framework 4.0平台稳定可靠，性能满足实际需求。系统构建在Microsoft .Net Framework平台中，严重依赖于该平台的可靠性，稳定性和性能。 ?本系统假设Microsoft SQL Server数据库稳定可靠，性能满足实际需求。系统数据存储于Microsoft SQL Server数据库中，依赖Microsoft SQL Server数据库的可靠性，稳定性和性能。 ?本系统假设涉及的外部接口可靠运行，提供正确数据。系统部分数据展现依赖于外部接口，当外部接口不能正确工作时，可能会导致部分展示数据不正确或无法显示。 ?本系统假设网络状态良好。本系统和客户端交互时依赖于网络状况，当网络故障或者性能低下时，可能会造成系统无法访问，系统响应速度变慢，数据无法提交等现象。但不应出现数据完整性和一致性的损坏。 ?本系统假设工作流引擎稳定可靠，性能满足要求。 ?本系统假设硬件服务器工作状态良好。 3功能性需求 3.1系统登录 【REQ_1】使用系统的用户分2类,内部用户及外部用户 【REQ_2】内部用户访问系统的时候,需要输入AD帐号密码进行身份验证检查 【REQ_3】外部用户访问系统的时候,需要输入用户名和密码进行身份验证检查 3.2首页 【REQ_4】每个用户登录后都可进入自己所属角色的首页 3.2.1.1业务人员 【REQ_5】列出业务人员本人的预立项的项目列表，已完成的合同列表，个人待办事宜，如下图示：
文档编号: PRMS-2 版本号: V1.0 文档名称：需求分析设计说明书 项目名称：项目申报管理系统 项目负责人：董艳，苏丽，李瑞卿 编写：董艳2009年11月10日 校对：董艳，苏丽，李瑞卿2009年11月10日 审核：董艳，苏丽，李瑞卿2009年11月10日 批准：董艳，苏丽，李瑞卿2009年11月10日 开发单位：西北农林科技大学信息工程学院信管062班
需求规格说明书 1．引言 (3) 1.1编写目的 (3) 1.2项目背景 (3) 1.3定义 (3) 1.4参考资料 (3) 2．任务概述 (4) 2.1目标 (4) 2.2运行环境 (4) 2.3条件与限制 (4) 3．数据描述 (4) 3.1静态数据 (4) 3.2动态数据 (6) 3.3数据库介绍 (6) 3.4数据词典 (6) 3.5数据采集 (9) 4．功能需求 (9) 4.1功能划分 (9) 4.2功能描述 (9) 5．性能需求 (10) 5.1数据精确度 (10) 5.2时间特性 (10) 5.3适应性 (10) 6．运行需求 (10) 6.1用户界面 (10) 6.2硬件接口 (10) 6.3软件接口 (10) 6.4故障处理 (10)
1．引言 1.1编写目的 编写本文档的目的是根据系统分析工程师和客户沟通的结果，对用户需求进行了全面细致的分析，深入描述《项目申报系统》软件的功能和性能与界面，确定该软件设计的限制和定义软件的其他有效性需求。 该需求规格说明书的读者对象是信息工程学院订餐管理系统软件小组的研发工程师、测试工程师、销售工程师，版权归信息工程学院信管062班所有。 1.2项目背景 在计算机日益普及的今天，科技高速发展，国家对科技项目的研究也越来越重视，每年都有很多项目要上报国家或政府，纸制的项目申报报告的审批浪费了大量的人力、物力、财力等资源。 为了适应社会的需求，使市级重点建设项目月报信息统计工作更加科学、规范、高效、简便，我们小组打算开发“项目申报管理系统”。本系统是为方便重点建设项目业主单位报送项目月报，增强申报部门与项目单位间的信息沟通与反馈，了解项目的建设进度及存在问题，协调解决项目建设中存在的前期工作、资金筹措、征地拆迁、建设施工等问题而开发的应用软件管理系统。 项目申报系统PRMS 2.0将会成为一套功能完善的数据管理系统，可以再Windows、linux 系统上顺利运行。根据2009年重点项目申报工作的需要，由西北农林科技大学信息工程学院信管提出开发一套为重点项目申报工作服务的应用系统，于完成之日交付。 1.3定义 项目申报管理系统是指应用电子计算机和相关网络支持，为申报项目的相关人愿提供数据信息管理系统，从而优化项目申报，减少项目申报周期，提高工作质量。 文档中采用的专门术语的定义及缩略词简要如下： PRMS：Project Report Management System，项目申报管理系统。 1.4参考资料 [1]教学提供需求分析设计模板 [2]杨选辉《信息系统分析与设计》北京：清华大学出版社，2007。 [3]王珊，萨师宣。《数据库原理与应用》。北京：高等教育出版社，2003。 [4]耿祥义张跃平。《JSP实用教程》北京：清华大学出版社，2007。
软件项目的需求开发与管理需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1? 什么是软件需求和需求工程 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情
{ 项目名称} 产品需求规格说明书 Radfort Corp. - 某某公司 ?- 版权所有 - All Rights Reserved
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文档 (4) 0.5术语与缩写解释 (4) 1. 产品介绍 (5) 2. 产品面向的用户群体 (5) 3. 产品应当遵循的标准或规范 (5) 4. 产品范围 (5) 5. 产品中的角色 (5) 6. 产品的功能性需求 (6) 6.0功能性需求分类 (6) 6.M F EATURE M (6) 6.m.n Function M.N (6) 7. 产品的非功能性需求 (6) 7.1用户界面需求 (6) 7.2软硬件环境需求 (7) 7.3产品质量需求 (7) 7.N 其它需求 (7) 附录A：需求建模与分析报告 (8) A.1需求模型1 (8) A.N 需求模型N (8) 附录B：需求确认 (9)
0. 文档介绍 0.1 文档目的 0.2 文档范围 0.3 读者对象 0.4 参考文档 提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [SPP-PROC-PP] SEPG，需求开发规范，机构名称，日期 0.5 术语与缩写解释
1. 产品介绍 提示： （1）说明产品是什么，什么用途。 （2）介绍产品的开发背景。 2. 产品面向的用户群体 提示： （1）描述本产品面向的用户（客户、最终用户）的特征， （2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？ 3. 产品应当遵循的标准或规范 提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。 4. 产品范围 提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。 5. 产品中的角色 提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。