A、你能检查你的需求质量吗？
针对功能的需求：
- 是否详细定义了系统的全部输入？（包括其来源、精度、取值范围、出现频率、客户怎么输入、客户计算机文化结构、审美观。）
- 是否详细定义了系统的全部输出？（包括目的、精度、取值范围、出现频率、格式、符合面对不同计算机文化客户习惯、残疾设计）
- 是否详细的定义了所有的输出格式？（包括Web页面、报表、图像、视频、声音、帮助的人性化）
- 是否详细的定义了所有的外部硬件和软件接口，并符合业界规范？
- 是否详细的定义了全部的外部通信接口?（包括握手协议、纠错协议、通信协议、交互协议）
- 是否列出了客户想要做的全部事情？
- 是否详细定义了每个任务所用的全部数据，以及每个任务得到的数据？
针对非功能的需求（性能需求）：
- 是否为全部必要的操作，从用户的视觉，详细描述了期望的时间？
- 是否详细的描述了其他与计时有关的考虑？（如处理时间，数据传输率、系统吞吐量等）
- 是否详细的定义了安全级别？
- 是否详细的定义了可靠性？（包括软件失灵的后果，发生故障后需要保护的至关重要信息，错误检测和恢复的策略）
- 是否定义了机器内存和剩余磁盘空间的最小值？
- 是否详细定义了系统的可维护性？（包括适应特定功能的变更、OS环境的变更、与其他软件的变更的能力）
- 是否包含对“成功”的定义和“失败”的定义？
需求的质量：
- 需求是用用户的语言写的吗？用户也这样认为吗？
- 每条需求都不与其他需求冲突吗？
- 是否详细定义了相互竞争特性之间的权衡了吗？（健壮性和正确性之间的权衡）
- 是否避免在需求中规划设计（方案）？
- 需求是否在详细程度上保持相当一致的水平？有些需求应该更详细的描述吗？有些需求应该更粗略的描述吗？
- 需求是否足够清晰，即使交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？
- 每个条款都与待解决的问题及其解决方案相关吗？能从每个条款上溯到他的问题域中对应的根源吗？
- 是否每条需求都是可测试的吗？是否可能进行独立的测试，以检验满不满足各项需求？
- 是否详细描述了所有可能的对需求的改动，包括各项改动的可能性？
需求的完备性：
- 对于开始开发前无法获得的信息，是否详细描述了信息不完全的区域？
- 需求完备度是否达到这个程度：如果产品满足所有的需求，那么它就是可接受的？
- 你对全部的需求都感到很舒服吗？你是否已经取掉了那些不可能的需求-那些只是为了安慰客户和老板的东西？
B、确保每个人都知道需求变更的代价：客户只要想到一个新功能就会很兴奋，而且大脑充血，直至发昏，它会把与大家开过的需求讨论会，需求签字、以及已经完成的需求文档全部丢到脑后，那么治理这种新功能中毒患者的病症的方法是什么？
C、 建立一套控制变更程序：如果这个新功能中毒患者热情依然不减怎么办？
D、 使用能够适用变更的开发方式：演进交付吗？
E、放弃项目：现在放弃损失吗？
F、注意项目的商业案例：
以上是我的一些问题，欢迎大家讨论，我的邮箱和MSN地址：mercy.wang@hotmail.com
也可以举办这样技术讨论会。QQ: 838766365
以后继续相关项目管理的讨论：包括立项、结项、项目规划、项目监控、质量管理、配置管理、RUP、XP、CMMI、UCM、PMPBOK、测试管理、知识传播、师傅制度、沟通方式等方面的讨论。
------解决方案--------------------------------------------------------
专业..学习了!1
------解决方案--------------------------------------------------------
这个确实觉得很难
如果天时地利人和，这个应该可以能做到吧
这个是我们的目标。
学习ing
------解决方案--------------------------------------------------------
支持，这个就是行业经验的积累吧。具体技术的积累可能很快会过时，但这些积累是不是不变的呢、
------解决方案--------------------------------------------------------
很好的标准,
不过真的能做到的在做项目的时候也能全部对应上,
恐怕还是有很大的问题吧.
------解决方案--------------------------------------------------------
这是最基本的东西，达不到你可以回家逗孩子了，参考CMM5试试