写需求分析必须牢记的5大要点

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

               

需求验证的5大要点

    要做好需求验证，必须在思想、方法、语言、人员、内容5个要点上做好相应的工作，否则就会产生很多负面的影响。
1．思想
    前面已经说过，由于Review被翻译成“评审”，导致很多人将其与中国人常说的评审相混淆，其实它们之间是有区别的：中国人常说的评审是评价，而Review应该是复查，是发现问题。这一点，必须成为所有组织、参加需求评审会的人员都应该建立的统一认识。
隐喻：
    当测试团队严肃、认真地对你说：“经过我们三天时间的测试，发现你提交的程序一个Bug也没有！”请问你会作何理解呢？
  A、我的程序很牛！
  B、这个测试团队的方法或态度有问题。
    我想很多人会选择B吧！因为“人非圣贤，孰能无过！”应该是测试手段还存在问题，导致潜在的问题没有被暴露。
可是，“我的需求评审通过了！”之类的话题总是被许多需求人员以很开心、愉快的方式说出来，我怎么听怎么觉得像听到“我的程序真牛！”。
    就像我们不是想花大量的测试成本来验证自己的程序无错一样，采用成本昂贵的评审技术也不是为了验证需求文档是无错的，而是帮助我们尽早地发现问题、找到错误，避免因问题被延误到后期解决而付出惨痛的代价。
SERU诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。
2．方法
    统一了思想之后，接下来的重点就是“方法得当”。
SERU诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，是创建企业评审文化的有效手段。
3．语言
SERU诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。
4．人员
    要开好评审会，选择合适的参与人员是很重要的；要点在于合适，而不是越多越好。具体来说，包括三个方面的要点：
  同级：别忘了，在CMM/CMMI中提到的是Peer Review，Peer就是同级，千万不要一开评审会就请高阶领导。
  该来的人要请：也就是评审的内容所涉及的第一责任人，要想办法请他们参加。
  不该来的人不要请：也就是评审不是越多人参加越好的，通常应该保持比较小的范围，要直接相关的人员参与；一方面可以保证参与者对评审内容熟悉，另一方面也可以保证参与者关心评审过程。
SERU诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。
5．内容
    建议大家控制在9条之内，理由就是心理学中的“7±2” 原则，也就是人们容易记住的信息条目在5～9条之间。因此大家也可以根据实际的情况做一些变通。
    除了要对缺陷检查表的规模进行压缩之外，还应该对评审的需求规格说明书进行压缩。根据笔者的经验，一个较熟悉的团队，要对需求进行相对有效的评审，应该控制在每小时30～40页之间。
那么在实际的工作中，我们如何对需求文档进行切分呢？是开一个时间周期很长的评审会，还是多次时间周期较短的评审会呢？似乎这两种方法都不尽可行。
    解决该问题的关键在于必须对需求规格说明书进行拆分，根据读者的层次、所关心问题域的不同进行拆分，具体的方法我们在第4～6章中已经做了很多说明。
SERU诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30～40页的速度来准备，缺陷检查表尽量在9条之内。

上述文字摘自于 徐峰老师 编著的《 软件需求最佳实践：SERU过程框架原理