需求的理解 (在这边我们假设拿到的需求说明书（有可能是OO的文档，有可能会掺着一些设计，很多时候经常是会忽略好多的业务逻辑，或者业务逻辑自相矛盾。）)
- 这是一个什么样的系统呢？
如何进行这个操作呢？ 当拿到一份文档的时候我们当然是打开阅读它了 在通读之后我们大概需要了解的
第一个事情呢？ 就是我们是需要搞明白这个系统到底是为某个行业服务，或者说是什么类型的系统。比较简单的来说我们可以判定他是一个（销售激励，网店，企业网站，某种信息类型服务（hotel查询，或者垂直搜索），娱乐性站点，） - 这个系统大吗？
它是否会涉及到很多的用户，一般来说平台类型的系统都是属于大型的系统。这个在后续的数据库中就要注意到这个问题了。 - 是否存在什么样的技术难点？全局规约是否有没有注意到的地方。
视频转换，垂直搜索，域名注册，在线支付，SSL, TCP/Socket, 手机浏览器
一般来说你没有碰到过的技术都可以认为是你的难点，如何去处理它呢？所以是找自己所在的小组里面的成员来咨询一下，前面他碰到这个东西的时候是如何处理的。有没有什么东西是需要注意到的。这样做的好处是？不这样做会带来什么样的影响。如果你对方面一点知识也没有的话最好是先baidu,google一下。是 - 业务规则有冲突吗？业务设计是否完善，是否存在某个方面的缺陷，
如果是只是单纯的阅读，我们有时候没有办法让自己身其境去考虑问题。思路进行是一个一维的过程。我们也比较难得出，他会有什么东西没有弄好。
这个时候我们需要的是画出他的用例，不断的从上面的哪一份文档中，画出所需要的用例，然后合并角色，这个时候时候我们基本就可以找出所有的用例了。所有系统必须做的东西，然后我们就需要组合这些用例画出我们的业务场景，并在业务场景，找出他这个文档没有描述的到东西记录到临时文档里，等需求分析结束后发给用户来确认。
这里边一般是会要求到经验了：
某些系统需要的用到的通用功能他都没有描述是他不懂还是无意中的没有记录进来呢（比如用户退出，用户忘记密码）文档有时候只会描述 用户登录跟本就不会描述到退出， 通常我们需要进行一下逆向思维。如果你有组员的你可以向他们重述一下整个系统。这时候他们就比较容易发现某个地方没有弄好。你也可能是自己发现了.
用例场景 如果时间比较充裕的话我们可以深入到每一个用例场景，有一张用例场景太一样了。基本每个系统都是哪样进行的，我们就可以舍去了。而一些比较重要的场景我们就必须画出来了。在后面的需求确认文档里就会用到了.
作者：Lovebanyi
出处：http://www.cnblogs.com/Lovebanyi/
关于作者：菜鸟一枚。如有问题或建议，请多多赐教！
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接
如果您阅读了我的文章并觉得有价值在充话费的时候就到小店充话费吧