最近有朋友让我将我写论文的经验写出来，并写个例子给她。拗不过，只好回忆。本文以我自己在2009年下半年项目管理师考试的论文题目为例，说明如何写论文。

论文的编写其实不难，关键是要将题目的内容都覆盖到，并掌握一些技巧就可以。

在这次考试中，我选择了试题二。这题要求论述三个方面。其中，第一个问题，基本可以在第一段，项目介绍中说明。第二个问题，则是主要的阐述内容，这里需要从三个方面：制定需求管理计划、需求变更管理、需求跟踪三方面来描述。每个方面，都应该平等，即字数应差不多。这个问题，以项目为例子，结合理论方面进行阐述。第三个问题，则是纯粹的对我所要阐述项目的需求管理过程过程进行总结与评价。

在这里，我以某行信贷管理项目为例进行描述。（我忘记实际考试中是否是采用这个项目了。这里就假设我重新考试时如何写的吧。）

论文编写注意事项：

1.       字数必须够，就是要填满纸张中对应的格数，而不是真正的去数字数。摘要一般要求200字以上，500字以下，正文要求2500字以上。

2.       项目名和客户名不能写出，用类似“某某”或者“XX”来表示

3.       通常先写正文，最后再写摘要。而且，摘要一定要字体工整，写要呼应题目。正文中，可以通过分节如：1、2、3、之类的描述。也可以有图片。另外，正文中，一定要将所选论文题目要求的内容要都覆盖到，并且，每个问题的阐述字数应差不多。避免某一问题用很多字描述，但是发现时间不够，所剩字数也不太多时，还有问题没回答这种情况的发生。所以，在写论文时，需要不时地回头看问题，还有关注全局。

4.       充分利用题面的文字，在找不到合适描述或字数不够，缺乏衔接时，可以参考或者直接抄题目。

5.       网上有很多类似的论文编写指南，可以仔细参考一下。这里写出的仅是我认为最关注的地方。

下面是我网上copy的一个关于正文第一段，即论点与项目概述的引出方式。

模板一：（论点——项目概述）
本文以我主持（或参与）的××××××（项目名称）为实例，探讨了××××××（论文论题），认为××××××（论点）。在此项目中，我担任了××××××（角色），参与了××××××（任务），实施后×××××（用论文中的方法实施后的效果）。
模板二：（项目概述——论点）
×××××（项目名称）是×××××（项目说明），在此项目中，我担任了×××××（角色），参与了×××××（任务）。对于项目的×××××（论题），本文认为×××××（论点）。该项目实施后×××××（用论文中的方法实施后的效果）。

下面给出模板一的一个实例，以供参考：（论信息系统项目的需求管理和范围管理）
本文以我主持的某商业银行网上银行系统项目为实例，探讨了作为开发方公司在信息系统项目的需求管理和范围管理方面碰到的问题及解决的办法，文章首先解释了需求管理和范围管理的基本概念，认为需求工作做得不扎实，项目范围把控不好是导致项目难以成功的主要原因，提出应以CMM过程改进的思想指导项目的需求管理和范围管理，项目在需求分析阶段应确定需求可以决策的人，充分和客户沟通以正确把握需求，对于需求和开发范围的变更管理提出了解决的办法。我在该项目中担任了开发方的项目经理，自始至终参与了整个项目的建设，自2004年4月项目启动至2004年12验收历时8个月，系统至今运行稳定，取得客户的好评，很大程度上得益于项目成功的需求管理和范围管理。

论信息系统项目的需求管理

摘要

本文以某发展银行信贷管理项目（以下简称本项目）为实例，阐述了信息系统项目的需求管理工作的重要性。在本项目中，我担任需求分析师，参与了需求分析、需求管理工作。该项目从项目启动到项目验收，共历时10个月。

本文结合本项目，阐述了在制定需求管理计划、需求变更管理和需求跟踪等方面，需求管理应实施的活动。文章最后，对本项目的需求管理过程，进行评价，包括经验教训等

正文

本文以某发展银行信贷管理项目（以下简称本项目）为实例，该项目是某发展银行，为适应数据的大幅度增长，满足信息系统能实现行里对数据的统一管理及分析需要，特与我司合作开发该项目。本文阐述了信息系统项目的需求管理，认为需求管理在信息系统项目中目的是确保项目各方对需求的一致理解，管理和控制需求的变更，实现从需求到最终产品的双向跟踪。在本项目中，我担任需求分析师，参与了需求分析、需求管理工作。该项目从项目启动到项目验收，共历时10个月。该项目目前正在稳定运行中，通过该项目的成功实施，为我司与该客户后续的长期合作奠定了良好基础。

一、制定需求管理计划

在本项目启动时，在制定项目计划时，项目经理安排我负责该项目的需求管理管理工作。需求管理计划对于需求管理工作的成功实施，起来重要作用。因此在项目启动后，我通过如下步骤，完成制定需求管理计划工作。

1.       与相关人沟通，梳理并明确需求管理工作内容。包括需求的沟通并达成一致、需求变更控制方法、需求跟踪频度及触发时机等。

2.       明确需求管理涉及的干系人、角色及职责。因需求管理涉及到干系人较多，为避免需求缺乏一个统一的入口及出口。在本项目中，我们要求客户方安排一名的需求接口人，我方也安排一名需求接口人。所有的客户需求均由客户接口人收集并整理后发给我方需求接口人。对于需求的反馈意见，也由该接口人统一对外传递。通过该约定，避免了因客户直接面对开发人员，导致需求零散且随意变化的情况发生。

3.       明确需求管理采用的平台，如需求管理工具等。在本项目中，我们采用IBM Rational RequisitePro（以下简称RP）作为该项目的需求管理工具，主要实现需求双向跟踪管理等。采用IBM Rational ClearQuest（以下简称CQ）作为需求变更管理工具。这两个工具的组合，很好的帮我们团队实现了需求跟踪管理及变更管理。所有达成一致的需求我均会将其导入RP中进行管理。

4.       编写需求管理计划。在本项目里，采用公司CMMI体系的需求管理计划模板，进行计划的编写。重点描述了上述内容。完成了需求管理计划编写后，由项目经理、各小组组长、QA、客户共同对该需求管理计划进行评审，并得到客户的认可。

二、需求变更管理

随着软件技术的复杂化，架构的多样化，业务的灵活化，以及随着客户对所需系统目标及需求的清晰化，变更时不可避免的。管理变更是目前项目成功的关键因素。因此，需求变更管理在整个项目的需求管理工作中显得尤其重要。

在本项目中我们采用如下需求变更管理流程。

1.       首先是客户需求接口人提出需求变更清单（记录需求变更项），我方需求接口人接收到该需求变更，并在CQ上发起需求变更流程，并分配给技术负责人。

2.       项目技术负责人接收到需求变更，对该变更进行技术评估，如果技术上可行，进入下一节点；否则给出相关的技术解答，也同样进入下一节点。

3.       项目经理接收到技术分析通过的需求变更，进行资源分析、进度分析等，分析通过的需求变更项，进入CCB审核环节。对于技术负责人分析不通过的需求变更，项目经理经过确认后，结束来流程，处于驳回关闭状态。针对这部分需求变更，需求接口人将给客户予以答复。

4.       对于项目经理审核通过的需求变更，CCB安排人员进行复核，复核通过后，该需求变更将由后续的实施人员（如开发修改代码、需求人员修改需求文档等）进行实施，并安排相关人进行验证。因实施及验证不属于需求变更管理流程，故这里不赘述。

通过上述手段，本项目保证了所有的需求变更都有据可依，同时，也通过该完整的需求管理过程，为后续的需求跟踪及相关的测试提供了信息保障。

三、需求跟踪

在实际项目开展中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户UAT（用户接收测试）时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。

本项目需求双向跟踪，包括从用户原始需求到系统需求、设计、编码、测试用例等之间的双向跟踪。如下图所示：

双向跟踪包括：

l  正向跟踪：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。一旦某个需求需要变更，就可以快速找到所有影响的范围。

l  反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。

在本项目里，我们采用RP实现了上述双向跟踪。通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。而且通过RP和CQ集成，在进行需求变更时，我们可快速找到需求关联项。

在我参与的这个项目里，作为需求管理负责人，我的工作主要目的是确保项目所有干系人对需求的一致理解，通过CQ管理和控制需求的变更，采用RP实现从需求到最终产品的双向跟踪。主要的工作流程包括制定需求管理计划，并通过评审得到客户的认可，求得项目所有干系人对需求的理解，求得对需求的确认、通过CQ管理需求变更，维护对需求的双向跟踪，并且通过RP的双向跟踪功能，协助我们识别项目工作与需求之间的不一致等。虽说该项目严格按照CMMI的需求管理过程要求实施，但是在实施过程中，也有我们自己的心得体会及教训，下面各列举一两点：

经验：

1.       一定在项目启动时，就要和客户就需求接口人予以明确。经过该项目的实践，发现，这个角色的设置，是相当正确的，避免了客户所有业务人员直接面对开发人员的情况，保证了开发所使用的需求都是有依据和证据的。

2.       有效的需求跟踪是避免需求遗漏的有效办法之一。可以避免在类似UAT时才发现需求未实现或者实现不全，减少项目上线压力，同时也减少了客户对公司项目团队的不满。正因为如此，通过该项目的实施经历，客户与我们又签订了后续的合同。通过该项目的成功实施，为我司与该客户后续的长期合作奠定了良好基础。

教训：

由于客户工作较忙，在进行需求分析，并对需求达成一致阶段，客户无法保证时间进行配合，无法逐个需求与我方进行沟通，同时，由于客户对需求的理解也有个过程，所以刚开始，客户提供的需求较泛。针对该情况，我方根据类似项目经验，结合我方对客户提供需求的理解进行开发。在提交第一版本给客户时，客户发现该版本与实际需要有一定偏差。此时客户对我们有很大意见。在碰到该问题情况下，我们及时调整需求分析及需求理解策略。经过双方沟通，客户同意我方就关键需求，先开发原型，并就原型与客户进行实际演示，客户针对原型上细化需求，并说明潜在需求。通过迭代式方式，当原型实现的业务与功能达到客户需求时，我们再针对这部分关键需求进行开发。通过需求开发方式、需求达成一致策略的调整，该项目终于如期上线，并按计划通过验收。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13180590/viewspace-669563/，如需转载，请注明出处，否则将追究法律责任。