[[
在QFD技术中以三种形式来定性地描述工程特征之间的相关影响关系，即正相关（向相同方向变化）、不相关和负相关（向相反方向变化）。对相关程度还可以进一步地细分为强相关、一般相关和弱相关几种关系，并给以标度值来表达相关程度，这样我们可以定义一些需求的强弱程度：如不确定需求、一般确定需求、强烈确定需求等，在这个HOQ中，还要用到其他技术工具，如：要素加权法等，这样做的好处是主次分明，可以把需求分析和管理做到随时间的推进客户的变更变限于固定的框架里，符合如下曲线，而不至于走向极端。
4.3需求说明书编写经验谈
目前需求说明书有固定的格式和要求,可以从专门介绍需求说明书的相关书籍中获得,在本论文中,我着重阐述需求说明书的经验，编写优秀的是没有公式化的方法的，这需要大量的经验，要从你在过去的文档中发现的问题学习。
1） 采用IT项目需求规格说明模版,要注意的是很多人拿来需求说明书模板就套用,这就有很大的风险,例如:会出现需求不全、需求范围界定不到位、需求分类不明确等因素，我们应该把需求规格说明书拿来后先罗列许多要点：约定、法律法规、需求分类、技术限制、采用的技术和工具等等全面考虑，与项目干系人特别是用户进行沟通，然后讨论，可以采用头脑风暴法和德尔菲方法来讨论，确定说明书大纲，而不能照本著书。
2） 附加文档的管理，值得注意的是需求说明书并非一成不变的，我们可以通过附加文档来跟踪用户的新的需求和需求变更，这样必须建立一个配套的文档集合，随时跟踪需求，保证开发团体步进统一，一般这些文件是要考虑的：《需求（或功能）变更申请书》、《需求（或功能）变更规格书》、《需求清单一览表》等。这样做的好处是对需求时实监控，保证项目的安排，同时让用户知道变更是一件很严肃的事情，可以防止个别人提出无法界定的需求（因为现实IT项目中，很多问题是其他系统的遗留而又超出本项目技术线路可以弥补的问题等）。
3） 编写需求说明书的时候，可能还会遇到一些解决不了的需求，我们也一定用专门的章节要罗列出来，防止漏项，同时也利于我们在做实施计划的时候来采取那种措施，采购其他设备、投入相关人力或其他办法。
4） 需求必须要客户确认，许多项目，可能开发商为了保护自己的“利益”很多事情都没有得到客户的确认，其实在需求阶段，我们的需求是要跟客户确认的，比如数据字典、界面选型、技术线路、功能模块等，这样做的好处是防止需求把握不得当，缺少了用户必要的功能，另一个就是防止了开发商需求镀金，提供了不必要的功能。
5 总结
经过以上各个方面来讨论需求管理在整个项目生命期所起到的作用，结合自身的经验，和一个案例《某市网上审批系统》综合分析了需求管理的办法和用到的工具，根据自身经验提出编写需求说明书要注意的地方。
[本文共有 3 页，当前是第 3 页] <<上一页 下一页>>
]]
您的位置：
