标签：错误 视图 获得 专业 部分 可行性 探讨 好的 精确
今天阅读了第二部分的第7章：寻找客户的需求 和 第八章：聆听客户的意见 的一部分
软件需求 获得分析确定 看起来几个字很简单，但是通过该阅读才知道实则是一个繁琐马拉松似的过程，不仅是需求的改变，文档的多次修改甚至重写，还有会以的召开，同时还得注意说话的方式和态度。在合作中更好的获取需求。
通过今天的阅读，我知道了项目视图和范围是描述项目的边界，应当有什么不应当有什么；项目视图是描述业务需求的，不仅是要有需求的宽度，还得有深度，也就是不仅是有什么需求还得对这个需求进行细节的描述。通过关联图，我们可以确定项目的问题域。
项目不仅是有商业需求的考虑还应当有用户使用者的考虑，不然会导致用户少的结果。所以针对不同的使用者，我们应当有不同的用户类别的用户代表，形成核心用户组。
在获取需求时，我们可以通过实例图来使得用户更好的理解，可以使用统一建模语言。当出现需求变更或补充的时候，应当对优先级可行性延迟还是放弃作出判断，对预算和进度等重新估计，并且对计划和文档重新整理，以适应变化。当需求出现冲突、意见不统一谁来做决策，就应当分析需求的比重哪个大，哪个重要，并且应该听谁的谁是最终决策者，代表应当时刻记住虽然产品代表者对软件和本行业的一定了解，但自己不是唯一的用户。
另外阅读体验还有：
我们可以通过签订保密协议，经济鼓励保证产品的不外泄。雇用相关能力的人作为产品代表，聘请专业人员作为指导和产品代表，观察用户使用、分析用户内容、市场调研的方式获取需求。
当和用户交流时，我们可以：
1.想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。
还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能……”,”当……时，将会发生什么”“你有没有曾经想过……”,“有没有人曾经……”为开头。记下每一个需求的来源，这样向下跟踪直到
发现特定的客户
2.客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”
标签：错误 视图 获得 专业 部分 可行性 探讨 好的 精确
原文地址：http://www.cnblogs.com/Amyheartxy/p/7719550.html
