需求文档通过的标准是什么？

yuanjun612

哪位能帮帮我，我将不胜感激。
       在下遇到点小问题，我每次在审查需求文档的时候都是靠自己的理解去审查，想到什么就是什么，但是花费的时间很多。哪位愿意帮帮小弟啊！可不可以把需求文档审查通过的标准告诉小弟下啊？（越详细越好）

xiaoyanzi518

多谢分享

yuanjun612

这只是我个人总结的，愿和大家一起分享！有不足的地方希望大家多提提意见！谢谢！

紫色梦幻

看了看,学习学习!

菜鸟上路

我也看看 嘿嘿`

yuanjun612

非常感谢版主的这份答案，我又从中知道了不少，谢谢！

ouyu

不知道你们公司对Review是怎么要求的，这里只是简要的介绍下功能设计review（FDR）要点，也只是review的基本点，通用性的，review的主要还是需要发表者的讲解，和会议参与者的经验，以及对review对象的了解深度，有很大关系。当公司或者部门的review比较成熟的时候，会在方法和形式上总结出来适合自己项目的最佳方法，既节约时间又能提高效率，不断积累，很重要。

参加Review的人员最基本要知道
1：Review的目的，必要性
2：Bug的定义
3：各阶段review的要点（BD,FD,DD,CD）
4：Review的实施（方法、流程、人员等）
这里只是简要的介绍下-〉功能设计review（FDR）要点
检查功能设计说明书各章和各项中记述的功能:
    是否满足基本设计书
    是否满足《开发概要书》中记叙的要求功能
1· 正确性
    ● 功能的正确性（有没有不明确的地方，正常或异常时是否都满足开发
       概要中提出的功能要求）
    ● 功能有无重大不足
    ● 外部接口描述有无遗漏
    ● 输入和输出项目正确与否

2· 实现方式
    ● 系统运行（ 安装、移动、恢复、操作方法等）有无问题
    ● 是否考虑到并行性（ 多处理[multiprocess] 等）
    ● 定义的功能在逻辑上是否可实现
    ● 相关的component有无遗漏
    ● 是否考虑到异常处理和界限值
    ● 限制事项有无与顾客要求相抵触的地方；限制事项是否充分
    ● 数据设计和文件设计是否恰当
    ● 是否考虑到兼容性/维护性/独立性/扩充性/通用性/移植性
        确认是否与已有的功能兼容
        结构上是否易于追加功能
        是否便于维护
    ● 确认功能追加、改造后是否引起性能下降
3· 标准化
  ● 审查功能设计书是否遵循了“软件设计作业标准”   
  ● 是否记述了开发的目的，内容，及对其他component的影响
  ● 是否记述了外部接口（目录、命令、message、画面等的人机交互、
     以及函数库等的程序间接口）
  ● 是否记述了环境设定方法，install方法，操作方法等
  ● 环境、资源是否充足；并且，环境和资源的配置是否没有超出顾客
     的要求

[ 本帖最后由 ouyu 于 2008-4-29 17:10 编辑 ]