‍‍今天完成的事情‍‍

     需求理解分几点

     ‍‍客户没有需求或需求模糊时‍‍

     ‍‍需求分析的优缺点‍‍‍‍

‍‍明天计‍‍划的事‍‍情      

  总结需求分析的优缺点

  关于测试用例的相关知识吧

‍‍遇到的问题：还没有‍‍‍‍

‍‍收获‍‍‍‍‍‍‍‍

‍‍1、需求理解分几点‍‍‍‍‍‍‍‍

用户需求：满足用户所想，用户是上帝

商业需求：一切向钱看，商业化是目的，实现产品价值的最大化。

用户需求和商业需求的关系

提供产品必须满足用户需求，你只有满足了用户需求才会对用户产生价值，你才有可能实现你的商业化目的。谈商业需求的前提一定是谈用户需求，只要把用户需求满足好了你的商业需求才有可能得到实现。

2、客户没有需求或需求模糊时

需求的模糊性是客观存在的，我们应该尽量避免，或者尽量减少需求的模糊性对软件工程的影响，以下将讨论如何应对需求的模糊性问题。在收集软件需求时，要记住下面的质量属性

正确性一该质量只能由客户用户代表来保证。

可能(可行) 性一一该质量要求有开发方环境方面的知识; 可用工具、技术、人员和预算必须满足最终需求。

必要性一一该质量必须由开发人员和干系人在面谈和需求引出会议上决定; 有很多特性都值得包含，但在最初软件版本的开发和执行需求排序中，是不

鼓励增加锦上添花的功能的;一种测试必要性的方面是向后追溯需求来源，知道用例场景。

优先性一该质量能由开发人员或干系人来决定; von Mayerhauser建议了三个层次的优先次序; 非常重要; 绝对必须(在下一步发布时执行，本质的);重要，但对下一步发布来说不是必须的(有条件的);纯粹选择性的(最好有，但执行时依赖于资源和进度)。

明确性一-IEEE对该质量的解释是,只有一种解释易于阅读和理解。

简明性一一进行到下一开发步骤所必须的信息: 相关历史、成本、进度等。

可验证(可测试、可测量) 性一一这意味着个人或机器能够检查软件能否满足需求。除了以上所述得需求质量外，我们要注意整个SRS (软件需求规范) 的未

来质量需求

完整性一一该质量能够通过于系人的检查来保证，它意味着，所有重要的需求都包含进去(功能、性能、外部等);

一致性一一开发人员通常保证该质量，它在内部文档内都是-一致的;

变化性一-一需求变化是工作的一个方面;

可追踪性一一该质量由千系人可开发人员共同拥有，它意味着，需求能在早期文档中明白无误地之处其来源，如在联合应用设计(JAD)会议中产生出来;需求应能跟踪到SRS,然后到设计和编码。

如果没有需求文档的话，我会尝试着和客户沟通，希望客户能够把他们的需求整理一下，无论是文档或者口述，各种发放都可以。如果客户没有时间或者不原意给出，那么我会按照所作网页的大致用处自己先写一份，让相关业界的人帮忙看一下，最后交给客户修改及确认。