创新中心任务管理系统需求评审报告—第一小组-(最终版)
企业的信息化有三个层面的内容
小组编号经济管理学院管理信息系统实验报告名称;企业信息化研究企业的信息化有三个层面的内容，第一个层面是数据的信息化，第二个层面是流程的信息化，第三个层面是决策的信息化。
据不完全统计，我国企业中实现上网的只占所有企业的20-3 0％，全部实现CAD、OA、MIS系统的企业不足10％，作为企业电子商务最核心的ERP系统，目前已实现的企业仅占2.9％。
我国加入WTO，如何提高企业信息化水平，提高国际竞争力，成为各方关注的焦点。
一、当前企业管理信息化存在的主要问题1．相当数量企业对实施先进信息化管理系统的重要性认识不足，实施此类系统的主动性不强，系统实施仍然处于自发状态，存在一定盲目性。
2．企业改制和现代企业制度建设进程比较缓慢，企业的落后管理模式与信息化管理系统的先进管理理念相冲突，观念更新、企业业务流程重组和组织重组的任务非常繁重。
3．企业信息化管理系统的软件市场较为混乱，市场制度建设滞后；软件价格高，对环境要求高，超出相当数量企业的经济承受能力和管理基础环境；软件商的服务与企业的要求有较大差距，在实施过程中，企业需要依赖于软件商提供更全面和完善的服务，但大多数软件商提供的服务仍然停留在“以我为主”的理念，缺乏实施信息化管理系统的专业咨询机构。
二、推进企业管理信息化的措施和途径针对上述情况，为实现企业管理信息化的战略目标，应进一步明确推动先进信息化管理系统应用的最终目标是提高企业的竞争力，而政府的推动应侧重于营造有利于系统应用的行业和社会环境，这是设计政策措施的总体思路。
政府推动企业管理信息化的措施和途径有以下三个方面：1．通过有效的政府行为，进行直接倡导和推动——政府举措(1)进一步明确推动企业管理信息化的战略意义，将推动系统应用纳入发展规划，并切实加以落实。
(2)政府适当投入，建立并逐步完善支持系统应用的宣传、交流、研究的信息沟通系统。
（3)努力培养积聚软件开发的相关人才。
4)积极鼓励、推动软件开发商、用户与学术界的联合或合作，研究和开发适合我国国情和具有竞争力的先进的管理系统软件产品。
软件需求管理课后习题答案
第一章：软件项目管理概述1、项目的定义及项目的基本特征：项目：在既定的资源和要求的限制下，为实现某种目标而相互联系的一次性的工作任务。
项目的基本特征：1明确的目标；2项目的独特性；3项目的时限性；4项目的不确定性；5结果的不可逆转性2、项目与日常工作的不同点及共同之处：不同：日常工作通常具有连续性和反复性而项目则具有时限性和唯一性，每一个项目都有明确的开端和结束。
管理方式不同，日常大多是职能式的线性管理，项目存在大量的变更管理。
共同：受到资源的限制，它们都必须由人来完成。
还有责任人、组织机构、收益大小等。
3、项目的基本特征：1．明确的目标:期望的产品或希望得到的服务2．项目的独特性：唯一性3．项目的时限性：有明确的开始和结束时间、不能重复4．项目的不确定性：实施中有变化引起的5．结果的不可逆转性：项目结束，结果就确定。
4、软件项目的特点：目标渐进性；项目阶段性；不确定性；智力密集型。
5、软件项目管理的特点：项目管理的对象是项目；系统工程思想贯穿项目管理的全过程；项目管理组织具有一定的特殊性；项目管理的方式是目标管理；项目管理具有创造性。
项目管理的核心任务是为项目增值，一方面为项目建设增值另一方面为项目使用（运行）增值。
6、项目管理环境：从项目环境作用的直接性程度划分可分为内部组织环境（即项目组织文化）—项目成员团队精神工作作风及特点、项目环境—与项目有联系对项目实施有影响的因素、一般环境—对项目有影响的周围环境。
7、软件项目中常见问题：需求不明确，变化比较多；工作量估计过低；项目团队水平不足；开发计划不充分；项目经理的管理能力不足。
8、软件项目管理成功原则：平衡原则（错误是“多快好省”）；高效原则（需求、资源、工期、质量）；分解原则（化繁为简，各个击破）；实时控制原则；分类管理原则（因材施教）；简单有效原则（没有完美管理只有有效管理）；规模控制原则（人员贵精不贵多）。
第二章：项目的生命周期和管理过程1、项目生命周期：项目执行过程中的演化过程。
PLM系统功能说明
需求受理 /评审/预 算/分配
已分配任务的需求 项，通过任务的进 度完成对需求项的 跟踪
开发/测试任务的安 测试管理/bug管理/ 需求—任务—BUG的 排，日程表。个人 问题处理 进度追踪视图 团队任务中心
需求
项目需求
任务项
Bug/问题
进度
2产品、开发项目周期的串联
Requirement 产品从创意设计到开发完成的全过程管理
■PLMonWEB可以同时提供这两种方式的对应功能，并支持在同一时间段两 种方式的并存，很好地满足了企业针对重点、非重点项目采取两种不同的管 理方式。另外不管采用何种方式，PLMonWEB都能很详尽的保留各项操作的 历史记录。
PLMonWEB功能介绍
⊕需求与Backlog ■需求快速创建与严格的评审、受理可以通过工作流针对不同产品或项目进行定义 ■评审过的需求或是Backlog，PLMonWEB提供矩阵追踪功能，全方位了解进度 ■对不同管理深度的用户，可以自由选择是否导入需求管理模组 ■没有需求管理需求的用户仍然可以通过任务项的直接创建针对Bcaklog建立的要求 ■PLMonWEB提供多种格式数据导入Backlog的功能，如从JIRA/Bugzilla/Project.. ■PLMonWEB同时也提供标准格式数据资料的导出功能，如XML
PLMonWEB功能介绍 ⊕需求管理模块 相关需求
●
• 某单一需求项同其他需求项之前的依赖关系可以在系统中维护管理 • 所有需求页面均可以方便查看其相关需求信息。 • 如执行的任务或项目依赖于需求时，其任务如有变更如测试缺陷提交可以提醒用户是 否对相关需求进行处理。 需求变更 • 需求因特殊原因需要变动时，系统中通过“需求变更”进行管理
研发过程管理
山西省人民政府办公厅关于印发山西省科技计划项目管理办法的通知-晋政办发〔2021〕42号
山西省人民政府办公厅关于印发山西省科技计划项目管理办法的通知正文：----------------------------------------------------------------------------------------------------------------------------------------------------山西省人民政府办公厅文件晋政办发〔2021〕42号山西省人民政府办公厅关于印发山西省科技计划项目管理办法的通知各市、县人民政府、省人民政府各委、办、厅、局:《山西省科技计划项目管理办法》已经省委、省政府同意,现印发给你们,请认真贯彻执行。
山西省人民政府办公厅2021年5月9日山西省科技计划项目管理办法第一章总则第一条为贯彻落实我省科技体制机制重塑性改革有关要求,进一步规范山西省科技计划项目(以下简称“计划项目”)运行管理,结合实际,制定本办法。
第二条本办法中的计划项目,是指由财政专项资金支持、以项目化方式实施的基础研究、关键技术攻关以及其他支撑创新能力提升的科技创新活动。
第三条计划项目应面向世界科技前沿、面向经济主战场、面向国家重大需求、面向人民生命健康,以科技“自立自强”为目标,聚焦“新基建、新技术、新材料、新装备、新产品、新业态”(以下简称“六新”)突破,服务全省一流创新生态建设。
第四条省创新生态建设领导小组审定计划项目设置,省财政主管部门负责综合配置计划项目预算,省科技行政主管部门负责计划项目的统筹管理与服务,各市、省直有关部门具体组织实施,共同推进计划项目落实落地。
第五条计划项目统筹管理遵循结果导向、权责清晰、公开透明、鼓励创新、宽容失败的原则,充分激发全社会创新创造活力,持续优化科技创新资源配置。
第二章计划项目分类第六条计划项目根据全省创新规划和重点任务进行系统布局,建立产学研用贯通的完整计划项目体系,并根据创新战略需求及时调整。
需求管理
需求管理假定生产要素的供给为既定的条件下对总需求的调整和控制。
根据凯恩斯经济学的国民收入均衡分析，由于社会总就业量取决于总需求和总供给的均势，如果在短期内生产技术、资本设备的数量和质量、劳动力的数量和技能等不变，即假定总供给不变，则经济调节的重点就应在总需求一边。
按照凯恩斯主义经济学的说法，在通常的情况下，经济中的有效需求是不足的。
所以，充分就业状态下的国民收入均衡不可能自行实现，而只有通过对总需求，即对有效需求的管理，才能实现充分就业均衡。
简介需求管理（Requirement management）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。
一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。
对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。
不同的需求组合起来，构成了一套完整的需求模型。
用户需求决定了系统设计所要解决的问题，所要带来的结果。
可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。
需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最需求管理相关图片终产品同需求的最佳结合。
通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。
需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。
仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。
需求管理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。
通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
需求管理能够确证：●我们确知客户的需求是什么（质量）；●满足客户需求的最佳解决办法（统一性）；著名学者Crosby对于质量的定义是"同需求保持统一"。
管理评审报告(通用4篇)
管理评审报告（通用4篇）在经济发展快速的今日，报告有着举足轻重的地位，报告依据用途的不同也有着不同的类型。
那么一般报告是怎么写的呢？下面是为大伙儿带来的4篇《管理评审报告》，亲确实定与共享是对我们最大的鼓舞。
管理评审报告篇一题目：供应链风险形成机理及防范对策研究评价内容评价指标能独立查阅文献和从事其他调研；能正确翻译外文资料；能较好提出课题的开题报告；综合分析的正确性和设计、计算的正确性;论证的充分性。
有坚固结实的基础理论知识和专业知识；能正确设计试验方案（或正确建立数学模型、机械结构方案）；独立进行试验工作；能运用所学知识和技能去发现与解决实际问题；能正确处理试验数据;能对课题进行理论分析，得出有价值的结论；有较好的专业外语水平。
综述简练完整，有见解；立论正确，论述充分，结论严谨合理;试验正确，分析处理科学；文字通顺，技术用语准确，符号统一，编号齐全，书写工整规范，图表完备、乾净、正确；论文结果有应用价值；计算及测试结果准确；工作中有创新意识；对前人工作有改进或突破，或有独特见解；定期完成规定的任务，工作量饱满，难度较大；工作努力，遵守纪律；工作作风严谨务实。
该生论文选题新奇，条理清楚，结构明确，重点突出论文。
文章在对国内外有关供应链风险管理的研究近况进行评述的基础上，分析了供应链风险产生的机理并对其分类，最终针对供应链风险提出了几点防备和掌控措施。
在论文撰写期间，该生能够认真遵守学院的各项规章制度，定时提交论文初稿，虚心听取引导老师的看法和建议，并及时认真修改。
态度端正，表现良好。
管理评审报告篇二本报告依据20xx年管理审查会议记录、20xx年管理审查计划和会议发表声明进行整理，构成今年的管理审查报告。
1、会议目的：讨论评价一年内管理体系的适用性、适用性和有效性。
一、评价标准：1）《试验室资质认定评审准则》2）质量管理方案、资源配置方案报告、质量管理系统运营方案报告、内部审计报告、监督人报告二、评价包含以下信息:a）过去经营审查中采取的措施的方案；b）与管理系统相关的内部和外部因素的更改；c）客户满意度、投诉及相关当事人的反馈；d）实现质量目标的程度；e）政策和程序的适用性；f）管理和监督工作人员的报告；g）内部和外部审计结果；h）矫正措施和防备措施；D检查检查机构间比较或本领验证的结果。
软件需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？ 然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。
编辑本段需求的类型
下面这些定义是需求工程领域中常见术语的定义。 软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。 1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们 在项目视图与范围文档中予以说明。 2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本说明中予以说明。 3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的 任务，从而满足了业务需求。 在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件 需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大 型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部 件）。 作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和 执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或 实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是 通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为 重要。 下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中 的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户 需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该 拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现 整个文档范围的替换。 从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些 没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发 布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。
第七章_需求验证与评审
软件需求验证的内容
软件需求验证活动是为了确定以下几方面的内容：
❖ 软件需求规格说明正确描述（无二义性和模糊内容）了预 期的系统行为和特征。
❖ 从系统需求或其它来源中得到软件需求。 ❖ 需求是完整的和高质量的。 ❖ 对需求的看法是一致的。 ❖ 需求为继续进行产品设计、构造和测试提供了足够的基础。
两种最重要的验证技术：正式和非正式的需求评审
❖ 案例五 某软件公司在公司内部举行产品的需求评审
会时，需求报告的执笔人与产品策划主要策划人 员的想法差别很大，致使需求评审会没有必要继 续进行下去。
需求评审中常见的问题是：
❖需求报告很长，短时间内评审者根本就不能把 需求报告读懂，想清楚；
❖ 没有作好前期准备工作，需求评审的效率很低; ❖需求评审的节奏无法控制；
第七章 需求验证与评审
本章结构
7.1 软件需求验证 7.2 软件需求评审概述 7.3 软件需求评审过程 7.4软件需求评审问题与困难 7.5 如何做好软件需求评审
本章目标：
了解软件需 求评审的过 程
理解如何做 好软件需求 评审
软件需求验证
需求验证是需求开发的主要内容之一。
现象：检测出需求规格说明中的错误，所采取的 任何措施都将节省相当多的时间和资源。
了解软件需 求评审的过 程
理解如何做 好软件需求 评审
❖案例一 某领域专家A先生就某企业的成本管理系统
做用户需求报告的评审工作，在评审会开始时间 不长，就被在场的企业的一位副总B先生打断， 认为A先生提出的方案不适合本企业，A先生提出 的管理改进方案在企业中无法实施。该副总提完 意见后，与会的用户方人员纷纷跟随B先生的提 出了他们的反对意见，致使评审会无法再进行下 去，最终该报告被用户否决。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
块。
在模块划分整体第二层添加“任务日志” 和“任务日历”两个模块。
3.5在3.1.3功能权限分配中，组长权 限中缺少组长对组员任务的任务删除权 限，管理员权限中没有“删除用户”和
“删除组”的操作。
在组长功能列表中添加“组员任务删 除”，在管理员功能列表中添加“删除用 户”和“删除组”
3.6在3.1.4中的图没有清晰的说明整 个任务审批的流程。
应该改用标准流程图来对审批流程进行分 解建模
4.权限分配
4.1在3.2权限分配中对节点的定义与 “界面划分”以及“功能权限分配”中 不一致，在前面两项中一直称 组长 和“组员”，而在这里却称为“员工” 和“领导”
将“员工”改为“组长”，将“领导”改 为“组长”
应当用具体数据范围说明
9.2在3.6中有阐述语法错误，第三行 中“返回50行数据以内的数据，单次操 作响应时间要求在3秒以内”不够简 练。
改为“返回50行以内的数据，单次操作 响应时间在3秒以内”
9.3在3.6中没有对系统处理登录、分解 任务、删除等操作时的响应时间作说 明。
应该对系统对各项合理操作的响应时间做 出说明。
创新中心任务管理系统
文件状态：
[]草稿
[V]正式发布
[]正在修改
文件标识：
当前版本：
1.0
作者：
软件评审第一小组
完成日期：
2012-2-24
修订历史记录
日期
版本
说明
作者
<2012年2月24日>
<1.0>
＜详细信息＞
＜姓名＞
1.基本信息4
2.缺陷识别4
3.评审结论与意见8
4.评审问答记录9
5.评审过程中需要进一步确认的疑问10
10.故障处理 要求
10.1在3.7中没有说明系统可能发生的 故障以及不同故障处理所需要的时间范 围。
应添加更新系统可能出现的故障，并对处 理时间说明。
8.2在3.5中第三点说明过于局限，系 统涉及到的计算问题不仅仅只有完成度 计算，对计算错误的规定也不够明确。
详细说明系统所涉及到的所有计算问题， 并相应说明所要求的计算准确度，比如误 差不超过多少等。
9.时间特性要 求
9.1在3.6中“多人操作的时候，时间 和相应的要求同上”中的“多人”不明 确。
“管理员登录”下对管理员进行的操作进 行分解。
3.2在3.1.1“页面划分”中“组长登 录”-“员工任务管理”下缺少了 “任务 删除”界面的划分。
添加“组长登录”一“员工任务管理”下 添加“任务删除”界面。
3.3在3.1.2模块划分“任务流程”中 缺少“任务删除”操作。
在“任务流程”中添加“任务删除”
1.
待评审的工作成果
创新中心任务管理系统需求分析说明书
技术评审方式
小组讨论
评审时间
2012年2月24日
评审地点
北京交通大学学生活动中心三层
评审所需设备
组内成员自带电脑
参加技术评审的人贝
类别
名字
工作单位
职称、职务：
主持人
组长
评审 小组 成员
成员
成员
成员
成员
成员
成员
成员
记录员
成员
作者
评审时间
2小时
2.
已识别的缺陷
将标题“任务概述”改为“项目概述”
2.2在本部分中没有对项目成本进行估 算
应该对该项目进行全面的成本估算
3.模块以及功 能的划分
3.1在3.1.1“页面划分”中缺少了
“管理员登录”页面的设计，因为管理 员在系统中的操作与组员和组长进行的 操作不一样，管理员应该有更高层次的 操作权限
在用户登录中添加“管理员”登录，
1.4在1.4中，《架构设计说明书》、 《数据库设计说明书》不能作为参考资 料.
《架构设计说明书》、《数据库说明书》 都是在确认需求之后的设计阶段写的，不 能作为参考资料；参考资料可以是项目组 为之前做的需求分析说明书、双方签定的 合冋、需求方提供的公司内部机制说明 等。
2.任务概述
2.1本部分的标题命名不够准确
7.5详细功能设定中没有优先级划分。
注明系统功能重要部分和扩展部分并对优 先级进行说明。
7.6“任务日志”和“任务日历”两个 功能点重复又相互矛盾.
合并这两个功能点为一个，因为这两个功 能点基本功能相互联系很密切。
8.精度
8.1在3.5中对操作精度的需求说明不 完整
应当详细说明系统在进行删除、查询、修 改、添加等操作时不允许在因为系统故障 导致重复或者不成功操作。
具体说明SDC项目组提出该系统的需求 原因、系统将来运行的环境以及需求方的 工作条件。
1.3在1.3中“定义”不明确，不清楚 本项定义的是任务管理系统的stakeholders,还是参与本系统开发的公 司或部门的人员定义。
在1.3标题中申明是“XX定义”，内容中 也应重新分类，不能将开发方与需求方混 淆。
6.任务报表
6.1在3.3中任务报表导出结果为 “excel"，格式过于局限。
导出的结果文件格式可以为其他常见文件 格式可选
6.2在3.3中没有涉及到报பைடு நூலகம்以及相关 材料的导入问题，缺少交互。
添加导入功能，使系统能够完成与系统外 部的交互，并且对报表进行分类，对每种 报表的导出、导入格式进行说明。
7.详细功能设
疋
7.1任务日历和任务日志详细功能设定相 互矛盾（是否能修改日志内容）。
修改矛盾
7.2人任务管理和员工任务管理的业务 描述在是否能修改的疋义上相互矛盾、 重复。
重新对业务进行描述，注意两个业务之间 的关系
7.3系统应该可以定期清理数据库中的 任务，避免数据量堆积，给数据库造成 压力。
7.4详细功能设定不够详细，没有说明 功能划分中的全部功能点。
缺陷描述
建议缺陷解决方案
1.引言
1.1编写目的不明确，忽略了该文档为 需求方和测试人员提供参考的作用。
添加本文档为对需求方、测试人员、今后 需求的变更提供的参考作用。
1.2项目背景阐述不明确，文中的该部 分仅仅是简单对系统本身进行简单介 绍，不够详细，对任务管理系统提出的 具体原因、产品的使用环境等情况都为 具体阐述。
5.任务提醒
5.1在3.3任务提醒中，对任务提醒功能 阐述不够详细、明确，比如在个人设置 提醒方式的时候具体如何设置，怎样修 改提醒内容，各种提示信息包括哪些等 都没有明确说明；并且缺少对任务提醒 这一过程的直观展现。
对提示信息的类型、提醒方式和内容 设置等进行详细、准确的说明。
可以使用流程图对任务提醒的功能进 行一个直观展示，有助于理解。