某集团软件项目需求管理规范
内部资料注意保密XX集团软件项目
需求管理规范
（版本：V1.0）
文档修订记录
目录
1基本概念介绍 (5)
1.1需求工作的重要性 (5)
1.2需求工程基本概念 (5)
2如何了解项目用户 (6)
3如何开展需求调查 (7)
3.1准备调研 (7)
3.2执行调研 (8)
3.3形成调研报告 (8)
4如何进行需求分析 (9)
4.1需求分析方法 (9)
4.1.1问题分析方法 (9)
4.1.2建模分析方法 (10)
4.2作出决策 (11)
5如何编写需求规格说明书 (11)
5.1正确 (11)
5.2清楚 (12)
5.3无二义性 (12)
5.4一致 (12)
5.5必要 (12)
5.6完备 (12)
5.7可实现 (13)
5.8可验证 (13)
5.9确定优先级 (13)
5.10阐述“做什么”而不是“怎么做” (14)
6如何做需求管理：确认、跟踪、变更控制 (14)
6.1需求确认（评审和承诺） (14)
6.1.1需求评审面临的困难 (14)
6.1.2需求承诺 (15)
6.2需求跟踪 (15)
6.3需求变更控制 (16)
7文档模板示例资料 (17)
1基本概念介绍
1.1需求工作的重要性
Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：
开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。
国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。
1.2需求工程基本概念
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。
把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理；需求开发的目的是通过调查与分析，获取用户需求并定义产品需求；需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求工程的结构图如下：
不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。
开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。
“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。
“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。
“领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。
2如何了解项目用户
找对人才能做成事，因此与市场部门做交接时从用户方组织结构入手详细了解本项目的客户、最终用户等项目干系人信息，即本项目中的哪些事情是由谁拍板。
“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）。掏钱买软件的用户称为客户（项目管理人员），而真正操作软件的用户叫最终用户（使用软件的业务人员）。客户与最终用户可能是同一个人也可能不是同一个人。
“现代营销学之父”菲利普?科特勒所著的《市场营销导论》是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。
因此在工作关系上保持一种平等心态，在工作态度上要尊重客户，以我们的经验技术切实为客户着想，深入了解不同用户在本项目中各自的诉求和关注重点，争取在工作成效上赢得客户的尊重。
3如何开展需求调查
项目启动会时务必请用户方领导参加，会上明确系统建设的大致思路安排，确定项目干系人以及双方的责任义务，树立双方协同共同努力建设项目的基调，为需求调研工作争取资源，做好铺垫。
根据合同约定以及对业务、系统的了解分析梳理出调研时需要了解的关键事项，围绕关键事项制定调研的计划；实际调研时立足系统目标、面向关键用户详尽的了解记录用户真实想法；最终梳理汇总成书面报告与用户再次沟通确认。以下分别进行描述：
3.1准备调研
准确阶段强调计划制定和思路方法。
对项目的范围内的功能，逐项落实，确定明确和不明确的需求。对系统的整体架构进行初步设计，把用户的需求，在系统的整体架构中进行分析；掌握提高项目相关业务知识，与用户有共同的业务知识背景，才能更好的进行沟通交流。
首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。
问题表可以有多份，随着调查的深入，问题表将不断地被细化。
根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。
制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。
其次，需求分析员应当确定需求调查的方式，例如：
与用户交谈，向用户提问题。向用户群体发调查问卷。
参观用户的工作流程，观察用户的操作。
与同行、专家交谈，听取他们的意见。
分析已经存在的同类软件产品，提取需求。
从行业标准、规则中提取需求。
从Internet上搜查相关资料。
最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。计划做细，责任到人才能有效抓住客户，保障调研工作的整体进程和成效。
3.2执行调研
执行阶段强调认真细致，充分沟通。
准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息。
需求分析员与用户面谈时应当注意以下事项：
?如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为
下次打扰他们埋下伏笔。（船员穿衣服的故事）
?需求分析员应事先了解用户的身份、背景，以便随机应变。IT人士不可貌相，有些大
企业的领导其外表很土气，象农民。如果你路上碰到他，以为是个勤杂工，说：“喂，老师傅，来帮我拎东西。”也许这笔生意就泡汤了。
?需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。
?如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某
些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。
?尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。
?避免片面地听取某些用户的需求而忽视其它用户的需求。
?发现有悖常理的需求时，一定要仔细搞清楚，可能是特殊的业务要求，也可能是传达的
信息有误，也要把我们的想法、了解的问题与用户充分沟通，可能用户的想法也是片面的或者不成熟的；若此时不讨论清楚，最终导致系统使用出现问题时还会给我们带来大麻烦。
?与客户发生争辩时也应心平气和指出问题和矛盾所在，目的在于使用户说出自己本质的
想法，而不是斗智斗勇，赢得没有意义的胜利；前期的业务争论可以有利于获取需求；
后续的技术争论要引导客户。
?做需求调研除了具备业务知识，沟通能力之外还要培养应变能力，客户错的时候摆事实、
讲道理的去纠正。有丰富的开发经验，需求归根到底要落实到程序里，一个根本不可能完成的需求，或者难度极大的需求能分解就分解、能引导就引导、能回避就回避。
3.3形成调研报告
汇总阶段强调综合分析，注意范围。
调研报告是对调研工作时收集信息的汇总整理形成书面报告，为下一步的需求分析工作提供基础支撑；用户想法可能笼统或零散，我们结合项目目标、合同约定等予以分析、细化、
纠偏，并与用户进行确认，最终获取真实、完备、可行的需求。。
进行书面化的过程中，会对收集信息再次进行消化分析。在这个消化分析阶段，考虑的内容会更加全面一些。有时候第一反应的内容经过消化分析之后会觉得不合理。有时候可能会认为需要进行进一步的调整与优化。总之口头的内容经过书面话之后，在质量上会有很明显的改善。
首先，当用户口头提出需求时，可以进行适当的记录。然后跟用户进行分析讨论。注意分析讨论完毕后，一定要让用户在提交一份书面的报告。报告的内容越详细越好。如需要包括提出这个需求的背景、现有的操作模式、如果按这么操作以后可能带来的收益、对其他用户的影响等等。
其次，项目管理员最好做一份格式化的文档，让用户根据文档来填写相关的内容。如可以在A4纸上根据需要做好相关的格式。如需求提出者、部门、原因等方面的内容。格式越详细越好。如此的话，用户在填写时才会写的比较详细。
最后，这个书面的报告还要经过多人的确认。有可能用户提出来的需求是其个人的建议，但是这个建议是否会得到其他人(如其直接领导)的认同呢?这个认同也非常的重要。因为一个需求可能会同时影响到多人(如多个人使用同一个作业)。在这种情况下，一个人提出的需求就可能会存在“自私”的情况。如会无意中撇开自己的责任等等。为此这些书面的需求，最终还需要在项目管理会议上进行讨论。让各个相关人员一起分析这个需求的合理性。
经过这几个环节之后，收集起来的需求一般就会比较立足于现实，同时又能够反映出企业未来一段时间内的需求。总而言之，就可以避免企业走极端路线。
4如何进行需求分析
需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图；
4.1需求分析方法
分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。
4.1.1 问题分析方法
?问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清
楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。
?问答分析最重要的问题是：“是什么”和“为什么”。
?每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。
?如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。
?追究“是什么”和“为什么”的目的是获得正确、清楚的需求。
?其它常见的问题有：
?需求存在二义性吗？
?需求文档的上下文有矛盾吗？
?需求完备吗？
?需求是必要的吗？
?需求可实现吗？
?需求可验证吗？
?需求的优先级确定了吗？
4.1.2 建模分析方法
?人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人
一目了然，所谓“一图低千言”就是这个道理。
?在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所
以将图形与文本结合起来描述需求是很自然的方法。
?需求建模就是指用图形符号来表示、刻画需求。
?建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。
?恰当地使用图形符号：
?现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表
示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。
世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描
述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。
4.2作出决策
?当需求从四面八方收集来后，需求的冲突在所难免。对于那些难以达成共识的需求
而言，经常会发生“公说公有理，婆说婆有理”的现象。那么需求分析员究竟应该听
谁的呢？
?如果一群人对需求有争议，并不是谁声音最响就听谁的。根据生活经验，最保险的办法是：先听官儿大的或者威望高的，如果大家的职位和威望都差不多，
那么采用“少数服从大多数”的原则。
?如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策应当以商业利益为导向，即哪一类客户出钱最多就
先满足他们的需求，以后再做那些获利相对较少的需求。
当开发者想象中的产品与客户所提的需求有冲突时，一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当纠正明显不合理的客户需求。如果产品很复杂，双方都不太明白需求，此时最好请开发人员快速构造软件的原型，双方看着软件原型再分析需求。
5如何编写需求规格说明书
需求规格说明书一般会作为验收范围、内容的依据，并直接影响后续的设计开发测试工作的开展，因此必须包含体现相关内容，并且要获得相关干系人的认可承诺。具体制定时需依据合同范围约定，结合对调研工作时获取的信息的分析结果，编写需求规格说明书；需求规格说明书请参考信息共享平台提供的文档模板以及示例文档，文档内容符合以下十点要求：
5.1正确
需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是
正确的，开发方和用户必须对《需求规格说明书》进行确认。
5.2清楚
清楚的需求让人易读易懂，不在于文档的厚度。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：
?文档的结构、段落是否乱七八糟？上下文是否不连贯？
?文档的语句是否含糊其词、罗里罗嗦？
?每句话都是对的，但是看了半天是否还不明白需求究竟是什么？
5.3无二义性
“无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。
为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。例如“小康”，“神圣不可侵犯”，“座右铭”
5.4一致
“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。
5.5必要
《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。
可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。
“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。
“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。
5.6完备
“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。
人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。
不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。
5.7可实现
《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。
“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。
营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被罚款的。
对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。
5.8可验证
《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。5.9确定优先级
为什么要确定需求的“优先级”？
?理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什
么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”
等问题，这时就乱套了。
?人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。
需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一
般地，由用户和开发方共同确定需求的优先级。
5.10阐述“做什么”而不是“怎么做”
《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。
国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。
6如何做需求管理：确认、跟踪、变更控制
6.1需求确认（评审和承诺）
需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。
项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。
需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》以签字盖章方式作出书面承诺。
6.1.1 需求评审面临的困难
需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。
需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。
开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。
开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。
人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。
6.1.2 需求承诺
需求承诺是指开发方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺，该承诺具有商业合同的效果。
需求承诺的“八股文”如下：
?本《产品需求规格说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化，我们
将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、
资源和进度等。
?甲方签字乙方签字
人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。
6.2需求跟踪
需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式：
?正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
?逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
可使用需求跟踪矩阵来进行此项管理。
项目管理人员必须要将产品需求传递给开发人员，并设定检查点进行确认和修正；开发
人员有必要了解相关模板的用户需求。
6.3需求变更控制
项目是双方共同的项目，共同努力才能成功，变更控制是为保障项目健康发展的一种举措；变更一旦失去控制，只会使项目进程陷入泥潭，直接导致项目目标难以达成，甲乙双方项目干系人员都难逃厄运。
需求发生变更的起因主要有：
?随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
?市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
需求变更控制的目的：如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”：
?开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补
偿开发方的损失。
如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。
拒绝是一种警戒和提示，可能本次不能成功拒绝，但还是可以使得后续更多的需求变更被用户自身扼杀；可以站在整个项目进展和风险的角度，借助甲方项目管理人员出面拒绝变更。
7文档模板示例资料文档模板、示例资料包括：
1、项目交接单
2、项目启动会PPT
3、需求调研计划
4、需求调研问卷
5、需求调研报告
6、需求规格说明书
7、需求跟踪矩阵
8、需求变更记录
9、
第2章 软件项目需求管理复习题
第2章软件项目需求管理复习题 一、填空题： 1、需求是从系统外部能发现系统所具有的满足于用户的特点、功能与属性等。 2、软件需求的四个层次依次分别是：原始问题描述、用户需求、系统需求、软件设计描述。 3、原始问题描述和用户需求的抽象层次比较高，能帮助我们的较高抽象层次上进行交流，而系统需求和软件设计描述则是具体的，可以根据它们的来进行编码。 4、通常情况下，在4个不同层次的软件需求描述中，由于原始问题描述和软件设计描述过于抽象和过于具体而不常出现，人们经常提到的是用户需求和系统需求。 5、系统需求一般分为功能需求、非功能需求和领域需求。 6、功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响应 及特定条件下系统行为的描述。 7、功能需求取决于软件的类型、软件的用户及系统的类型等。 8、功能需求应该具有全面性和一致性。 9、功能需求全面性指对用户所需要的所有服务进行描述。 10、功能需求一致性则指需求的描述不能前后自相矛盾。 11、非功能需求是指那些不直接与系统的具体功能相关的一类需求。它们与系统总体特性相关，如可靠性、响应时间及需要的存储空间等。 12、非功能性需求定义了对系统提供的服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。 13、非功能需求还与系统的开发过程有关，例如对在软件过程中必须要使用的质量标准的描述、设计中必须使用的CASE工具集的描述以及软件过程所必须遵守的原则等。 14、按照非功能需求的起源，可将其分为产品需求、机构需求和外部需求3大类。 15、产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程。 16、一个好的需求集应该包含用户解决问题需要的功能服务，而且尽量避免涉及软件设计与软件实现的细节。区分一个需求集质量的高低可通过软件需求质量度量的9个元素，即正确性、无歧义、完备性、一致性、分级别、可验证性、可修改性、可跟踪性、可理解性。17、需求工程可分解为需求开发和需求管理。需求开发关注需求的生成，需求管理关注需求变更的控制。 18、需求开发与需求管理之间的界限是基准需求规格。 19、需求管理是一个使客户与项目团队不断变更的软件需求达成并保持一致的过程。 20、需求开发的结果应该有项目视图、范围文档、用例文档、软件需求规格说明书及相关分析模型。 21、需求评审有两类，其中的正式技术评审也称为同行评审。 22、实现需求跟踪的一种通用方法是采用需求跟踪矩阵。 二、简答题： 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 获取用户需求的活动
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”； ⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。 ●需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动： ⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）； ⑵使需求符合系统的整体目标； ⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。 分析用户需求 在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动： ●以图形表示的方式描述系统的整体结构，包括系统的边界与接口； ●通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价； ●系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等； ●以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。
软件研发管理制度
武汉新英赛研发管理 第一节 软件研发岗位职责 一、软件研发部经理岗位职责 软件研发部经理在总经理或主管副总的领导下, 全面负责软件研发部的日常管理， 组织 开展软件研发与测试工作，完成企业研发目标和经营目标。其具体职责如表 二、高级研发工程师岗位职责 高级研发工程师参与建立研发工作标准与规范，协助部门经理组织完成软件研发工作, 管理软件研发项目，改良升级进行软件。其具体职责如表 8-1所示。 8-2所示。
表8-2 高级研发工程师岗位职责 三、软件研发工程师岗位职责 软件研发工程师协助高级工程师进行软件的设计与开发，收集整理相关行业信息与资料，为软件产品决策提供依据。其具体职责如表8-3所示。
四、软件测试工程师岗位职责 软件测试工程师主要负责软件测试工作, 根据软件产品规格和测试需求，编写测试方案、测试用例、测试脚本软件等。其具体职责如表8-4所示。 第二节软件研发管理制度 六、软件研发费用管理制度 第1章总则 第1条目的。 为了加强软件研发费用管理，规范资金的使用，减少公司不必要的损失，根据公司的实
际情况，特制定本制度。 第2 条研发费用管理原则。 1．计划统筹安排原则。 2．节约使用、讲求经济效益原则。 第3 条职责分工。 1．公司财务部负责研发费用的审批和报销，并随时监督费用的使用情况。 2．软件研发部负责研发费用的预算与使用控制。 第2 章研发费用的来源及使用范围 第4 条研发费用的来源。 1．公司对重点研发产品的专项拨款。 2．公司成本列支的研发费用。 3．从其他方面筹措来用于研发的费用。 第5 条研发费用的使用范围。 1．研发活动直接消耗的材料、燃料和动力费用。 2．研发人员的工资、奖金、社会保险费、住房公积金等人工费用以及外聘研发人员的劳务费用。 3．用于研发活动的仪器、设备、房屋等固定资产的折旧费或租赁费以及相关固定资产的运行维护、维修等费用。 4．用于研发活动的软件、专利权、非专利技术等无形资产的摊销费用。 5．用于中间试验和产品试制的模具、工艺装备开发及制造费，设备调整及检验费，样品、样机及一般测试手段的购置费，试制产品的检验费等。 用。用。6．研发成果的论证、评审、验收、评估以及知识产权的申请费、注册费、代理费等费7．通过外包、合作研发等方式，委托其他单位、个人或与之合作进行研发而支付的费8．与研发活动直接相关的其他费用，包括技术图书资料费、资料翻译费、会议费、差 旅费、办公费、外事费、研发人员培训费、专家咨询费、高新科技研发保险费用等。 第3章研发费用的使用管理 第6 条专款专用。
软件项目实施方法
项目实施方法 目录 3 文档范围 6 1. 项目实施总论 6 1.1 项目实施目的和意义 6 1.2 项目实施阶段说明 6 1.3 项目经理 6 1.3.1 任职资格和职责 6 1.3.2 项目经理权利 7 1.3.3 项目经理负责制 7 1.3.4 项目经理动态聘任制 8 1.4 项目组 8 1.5 项目实施流程 8 1.6 项目实施内容 8 1.7 项目管理文档/工件清单 9 2. 项目商务 9 2.1 项目可行性分析 9 2.2 项目立项 9 3. 项目策划 10 3.1 项目目标和范围 10 3.2 项目合同 10 3.2.1 承包合同 10 3.2.2 分包合同 11 3.3 项目组织 11 3.3.1 项目前期组织 11 3.3.2 项目开发实施组织 11 3.4 项目策略 11 3.5 项目计划 11 3.5.1 项目任务计划 11 3.5.2 项目成本计划 13 3.6 项目启动会议 13 4. 项目实施 13 4.1 项目进度控制 13 4.1.1 项目例会 13 4.1.2 项目状态报告 14 4.1.3 项目里程碑/阶段评估验收 14 4.1.4 项目审计 14 4.1.5 项目收款进度 14 4.2 项目质量控制 14 4.2.1 软件质量 14 4.2.2 过程质量 15 4.2.3 质量措施 15
4.3 项目成本控制 16 4.3.1 项目预算 16 4.3.2 月度预算 16 4.3.3 备用金管理 16 4.4 公司项目风险控制 16 4.5 变更管理 17 5. 项目收尾 18 5.1 项目收尾的前期准备 18 5.2 部署 18 5.2.1 计划部署 18 5.2.2 部署 18 5.2.3 部署总结 19 5.2.4 系统试运行 19 5.3 验收 19 5.3.1 计划验收 19 5.3.2 验收 19 5.3.3 验收结束 19 5.4 项目维护 19 6. 项目综合管理 19 6.1 项目风险 19 6.1.1 常见风险和应对措施 19 6.2 项目沟通 21 6.2.1 客户沟通 21 6.2.2 公司沟通 22 6.2.3 项目组内部沟通 22 6.2.4 项目问题跟踪 22 6.3 项目文档 22 6.3.1 项目文档格式标准 22 6.3.2 标准文档工件清单 22 7. 项目考核 22 1.3 项目经理 1.3.1 任职资格和职责 任职资格： 通常情况下，项目经理是需求设计组成员； 在项目主要相关业务上有一定工作经验，研发项目必须有较深的技术背景； 具备系统思考能力，能合理权衡项目目标，能对项目中出现的问题用全面的、长期的眼光进行考虑； 具备良好的沟通协调能力，包括充分利用资源、组织和组建团队能力、应对风险危机和处理问题能力，谈判和沟通能力； 符合公司《技术人员项目考核及职业发展标准》其他要求； 职责： 对项目的成功负主要责任； 保证项目目标的完成，并保证项目完成和目标一致；
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
论软件项目中需求管理的重要性
需求管理对软件项目的重要性 信息技术革命正以迅猛之势更新着我们生存的社会。信息技术不再仅作为一项独立技术而存在。各行各业中信息化手段与技术的采用越来越突出，软件需求量越来越大，与此蓬勃发展的软件产业前景相反的是，软件行业落后的生产方式无法满足目前信息化时代飞速增长的软件需要，大型信息系统的成功率持续低迷。 以计算机软件、集成电路技术为主导的信息技术革命正以迅猛之势更新着我们生存的社会，信息技术不再仅作为一项高科技技术而存在，而是广泛渗透于各个行业领域的生产、经营、管理等过程，成为它们发展的辅助手段和管理工具。 信息的采集、分析、处理、整合、发布是信息产业的核心内容，它们都离不开软件。软件是计算机的核心，信息社会需要众多功能灵活的软件系统。 但是，自20世纪60年代以后，全球软件行业落后的软件生产方式无法满足目前信息化时代飞速增长的软件需要，传统的软件开发方式与软件产品设计过程已不能满足当今对软件产品多样化的业务需要，从而导致软件开发与生命周期维护过程中出现一系列严重的问题。 所以我认为“软件项目中的需求管理”是软件项目成败的关键，对项目成败具有决定性的作用。以下将阐述软件项目中需求管理的重要性。 现阶段需求管理的问题主要体现在以下几个方面：
1.软件项目中范围、进度、成本估算准确率低。 软件项目开发的实际成本远远高出估算成本高出；同时实际进度比预期进度延后几个月甚至几年。这种现象降低了软件组织的信誉。 2.客户对最终交付产品满意度低。 软件开发人员在对用户需求未有清晰了解的基础上，对所面对的问题领域还没有确切分析与设计的情况下，即着手进行开发、编写程序。造成实际产品与客户期望功能产生偏离，无法解决客户的真实需求而造成客户满意度降低。 3.软件产品质量差强人意。 软件质量保证技术没有贯彻地采用到软件开发的过程中，这必会导致软件产品发生质量问题。缺乏审核、复审和全面测试的软件难免质量低下，出错率高。 4.软件不可维护、生命周期短。 软件程序中错误难以改正，出现新的需求或者需求变更时原有架构不易于维护，不能根据用户的新需求在原有架构中进行改变。造成软件的使用年限缩短，软件成本加深。 5.软件缺乏配套文档资料。 软件产品应具备整套文档资料。然而在进度与成本的制约下，文档的编写与更新工作也使得软件组织疲惫不堪，每个人对文档内容的深度与阐述程度不尽相同。加之企业缺乏与之配合的文档制度、文档模板，更为文档编写带来困难之处。而缺乏相关文档对软件的二
软件项目管理之需求分析
软件项目管理之需求分析 需求分析是项目开发的基础，所以在进行软件项目开发之前，我们必须要了解下用户的需求是什么，避免在投入大量人力、物力、财力、时间等之后，开发出来的软件没人要。本文将从需求分析的过程、层次、需求开发阶段的重点以及需求分析的任务做详细介绍： 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 范围适用于新产品的软件开发设计以及定型产品的改进升级。 3 职责与权限 研发中心负责： a)编制软件开发过程的实施、协调和控制工作； b)编制各阶段的技术文件； c)组织软件的测试、验收、升级和维护工作。 各部门参与软件开发过程中有关的设计评审。 4 内容 软件项目的开发实施过程管理要求 软件项目实施过程总体要求 本部分主要要求工程师制定软件开发工作计划，对过程进行控制，一般包括以下的内容。a) 工程师提交软件开发工作大纲，项目组织者对工作大纲进行评审，并提出整改意见。 b)通过评审后，工程师根据整改意见完善工作大纲，经过项目经理认可后组织项目组进行 软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，工程师需分阶段提交相关文档。 c)在软件开发工作完成后，工程师应向项目组提交完整的软件文档，相关人员组织验收组对软件进行验收审查。 软件项目实施变更要求在开发过程中，需求或设计不可避免地需要发生变更，相关变更必须提交《软件变更申请》经过项目组书面同意方可进行。在需求或设计发生变更时，需要对原有文档进行修改，并提供完整的变更记录，以使变更处于可控制的状态。 软件项目实施里程碑控制本部分主要对软件开发过程中的重要节点进行控制。项目组将分四个阶段进行把关，召开审查会。 a）需求分析（结合原型进行审查）确认；
b）概要设计+数据库设计； c）预验收（样机测试时）； d）正式验收（产品定型后）。 软件开发 软件开发必须严格按照软件工程的要求进行。开发过程包括工程师的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。 软件的需求分析 需求分析 需求分析要求开发人员准确理解用户的需求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约《软件需求规格说明书》的过程。 在《软件需求规格说明书》必须描述的基本问题是：功能、性能、强加于实现的设计限制、属性、外部接口。 需求报告评审在软件需求分析工作完成后，软件工程师应向项目组提交《软件需求规格说明书》。项目组组织有关人员（系统客户和系统开发人员等）对需求进行评审，以决定软件需求是否完善和恰当。项目组严格验证这些需求的正确性，一般从一致性，完整性，现实性，有效性四个方面进行验证。评审完成后，就可以进入软件的设计阶段。 软件的概要设计 概要设计 概要设计也称为系统设计，需要确定软件的总体结构，应该由哪些模块组成，以及模块与模块之间的接口关系，软件系统主要的数据结构和出错处理设计等，同时还要制定测试方案，形成概要设计说明书，为软件的详细设计提供基础。在概要设计时一般从以下几方面来考虑，遵循以下的流程。 概要设计和需求分析、详细设计之间的关系和区别需求分析不涉及具体的技术实现，而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计，是编码的依据。概要设计是指导详细设计的依据。 概要设计的评审 在软件概要设计工作完成后，软件工程师应向项目组提交《软件概要设计》。评审通过后，即可进入详细设
软件配置管理计划示例
软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理
2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
软件项目管理系统要求规范
软件项目管理规范 一、软件项目管理的定义 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等，所有这些活动都必须进行管理，软件项目管理贯穿于软件工程的演化过程之中，如图1所示。 图1 软件工程的演化过程 二、软件项目管理的过程 为保证软件项目获得成功，必须清楚其工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程分为如下几个步骤： （1）启动软件项目 启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。 （2）制定项目计划 软件项目一旦启动，就必须制定项目计划。计划的制定以下面的活动为依据。 ·估算项目所需要的工作量 ·估算项目所需要的资源 ·根据工作量制定进度计划，继而进行资源分配 ·做出配置管理计划 （3）跟踪及控制项目计划 在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控制和调整，但要确保计划的完整性和一致性。 （4）评审项目计划 对项目计划的完成程度进行评审。并对项目的执行情况进行评价。 （5）编写管理文档 项目管理人员根据软件合同确定软件项目是否完成。项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。 三、软件项目管理的内容
IT项目管理需求分析说明书
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、招投标管理：这是一个特殊的环节，管理项目中需要招投标的事务， 主要是管理招标表，甚至保留招标内容。一个项目中可能会有多个招标事务。招标完成和由省局和中标单位签订合同，也可能会要求各个
公司软件项目管理规范标准
公司软件项目管理规范 V1.0
研发中心软件项目管理规范 1.1.项目实施原则 ?项目实施过程要遵守标准规范的项目管理体系进行 ●项目执行的规范性是项目成功的保证。 ●项目执行的规范性可以有效保证项目质量。 1.2.项目实施方法 金山顶尖在多年的应用软件项目实施过程中，积累了丰富的项目实施经验，曾先后组织实施了多个上千万元的复杂项目，同时也积累了丰富的项目实施经验。 1.2.1.管理目标与指导思想 ●管理目标 以客户体验为中心，持续改进产品生产及交付过程，面向客户提供优质产品或服务,持续提高客户满意度。 ●指导思想 通过持续的过程改进，逐步提高项目交付的产品（服务）质量与生产效率，更好的满足客户的需求，提升公司客户满意度。 1.2.2.质量保证体系 依据ISO9001:2008的规定，金山顶尖质量体系文件划分为4层层级结构，自上而下分别为纲领性文件、制度性文件，作业指导性文件和质量记录模版，下级文件的制定和修改必须符合上级文件的要求，如下图所示：
手册、方针 过程文件 作业规范、指南文件 质量记录、模板文件 质量体系文件层次示意图 ●第一级为质量手册和方针文件 质量手册和方针文件是公司质量管理及过程改进体系的纲领性文件。它依据GB/T19001-2008质量管理体系要求、系统工程生产过程域的目标要求，规定了公司提供产品及服务的过程质量控制标准及其工作产品质量目标要求。 ●第二级为制度性文件 制度性文件是规范公司生产管理过程的一系列规章制度和办法文件，它适用于公司所有部门，是公司所有员工工作沟通的平台，主要包括项目管理控制程序文件、软件及系统工程管理控制程序文件、销售管理控制程序文件、服务保障体系文件、客户满意及投诉管理体系文件以及其他业务支持体系文件。 ●第三级为作业规范及指南文件 作业规范及指南文件是针对过程控制体系文件对公司各业务领域的作业规范要求制定的具体的设计、开发、实施、服务及运营保障管理作业说明书，是对过程控制体系文件的进一步细化和补充。 ●第四级为质量记录及模版文件 质量记录及模版文件体现了ISO9001-2008的基本质量要求及过程质量控制要素，为公司员工执行作业程序提供了一系列的参考模板、质量记录和工具表单文件。 金山顶尖质量保障体系如下图示意表示：
软件项目实施保障措施
项目实施保证 为确保项目的顺利开展和实施，我们分别制定了项目组人员保证方案和软件开发质量保证方案以及项目进度保证方案。 1项目组人员保证方案 为确保项目的顺利开展和实施，项目组的人员配备既有高层次的技术带头人（专家、教授等），也有中坚力量（博士、工程师、研发经理等），还有一般工作人员（具体开发设计工作的人员、试验人员、管理人员等），并实行项目经理、技术负责人质量负责制，加强技术管理的有效性和研发过程的科学性、准确性。 2软件开发质量保证方案 2.1质量管理内容 2.1.1 编制和评审质量计划 制定质量保证计划：依据项目计划及项目质量目标确定需要检查的主要过程和工作产品，识别项目过程中的干系人及其活动，估计检查时间和人员，并制定出本项目的质量保证计划。 质量保证计划的主要内容包括：例行审计和里程碑评审，需要监督的重要活动和工作产品，确定审计方式，根据项目计划中的评审计划确定质量保证人员需要参加的评审计划。明确质量审计报告的报送范围。
质量保证计划的评审：质量保证计划需要经过评审方能生效，以确保质量保证计划和项目计划的一致性。经过批准的质量保证计划需要纳入配置管理。当项目计划变更时，需要及时更改和复审质量保证计划。 2.1.2 “过程和工作产品”的质量检查 根据质量保证计划进行质量的审计工作，并发布质量审计报告。 审计的主要内容包括：是否按照过程要求执行了相应的活动，是否按照过程要求产生了相应的工作产品。本项目中对质量的控制主要体现在不同阶段的审计当中。 2.1.3 不符合项的跟踪处理 对审计中发现的不符合项，要求项目组及时处理，质量保证人员需要确认不符合项的状态，直到最终的不符合项状态为“完成”为止。 2.2质量管理责任分配 我公司在开发项目上按照规范化软件的生产方式进行生产。每个项目除配备了项目开发所需角色外，还专门配备了质量保证小组、配置管理小组、测试小组来确保质量管理的实施，下面针对这三种角色进行说明： 2.2.1 质量保证小组职责 质量保证小组作为质量保证的实施小组，在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组的主要职责是：以独立审查方式，从第三方的角度监控软件开发任务的执行，分析项
软件配置管理规范.doc
软件配置管理规范1 1．简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退
出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能 通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.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住院部管理员修改登录密码............................................................................. 错误!未定义书签。