阅读笔记1

读了这篇关于软件需求分析的博客之后，令我大有感触。我觉得这篇文章写得实在是太好了，完全可以绘制成一本关于软件需求分析的书。

此书主要从客户的一些需求分析作为出发点，对用户的需求作大量的研究，从不同的角度做分析。一个需求分析的是否彻底决定了项目的成功与否。但是从现实中来说，很难做到不停的调研，对用户的需求能够彻底的了解，直至到达用户需要的场景。对于一些基层人员，像这种专门做软件开发设计的，在开展一个项目之前，必须要了解用户的需求，用户在什么样的工作环境下的需求，对于最基层工作人员的工作情况了解，不能让此系统软件给工作人员造成了负担。要做到好的需求结果，我认为需要，大胆和用户沟通不要怕说错、有不懂业务问题一定要问用户不要怕打扰别人了、多写各类软件文档不要怕麻烦、多百度一下很多 问题能解决、多推敲在用户需求上能否在扩展更有用的东西、系统界面一定要美观，很多开发人员都不太重视界面，只注重一些功能的实现，每次先完成一些项目的功能之后，可以先让用户看看，是否按着他的一些思路，对于一些对此专业一窍不通的用户，可能会有一些天马行空的想法，在这个时候你不能拒绝用户的想法，这样会让用户感到反感。对于这种情况分析人员只能调查为什么用户会有这样的想法，这种想法对于用户的利益，然后分析人员 可以通过其他的解决方法进行解决。

我们应当怎样做需求分析：子用例与扩展用例 这部分里用例图中“按单位汇总考核结果”应该和前面几个查询是扩展关系，而不是父子关系。父用例应该是抽象的，共性的东西，子用例是具体的，个性的东西。 子用例继承父用例，使用或者重写父用例的部分内容。扩展则是对被扩展用例功能上的延伸，扩展用例不影响被扩展用例，被扩展用例可以单独存在。所以，我觉得 两者是扩展关系。因为“按单位汇总考核结果”是依赖于前面的查询结果的，但查询结果不因为是否汇总而受影响。对于一些用例，这种东西对于一些用户来说根本看不懂，这时候分析人员必须要用其他通俗易懂的话对用户进行指导。

在每次与用户交谈的时候，分析人员都会带着一个小本，对用户的需求进行统计，但是我们做软件，不仅仅要做出用户提出的功能，还要做一些潜在的功能，可能用户认为这种功能是一种常识，不需要讲出来，也许是因为用户忘记了这种功能，但是作为一个分析人员，必须要全面的分析出这个系统软件的所有有用的功能，否则，在做完项目之后，待到用户检验产品时，用户对于此类产品的功能不满意，要求重新添加修改一些功能，这样的任务是很庞大的，而且可能会出现各种各样的bug,因此，每次在开发人员做完一些必要的功能之后，就可以让用户检查看看是否满意，如果满意之后就可以进行后续的任务。

对于软件需求与分析这门课来说，我认为必须要掌握一些必要的知识 ，我们应该学会调研，对于用户提出的功能需求进行严谨的调查落实，从不同身份的人员进行调查，来确定最终的结果，对于这些问题，可以开展一些研讨会进行交流，由于需求分析有不同的方法，对于不同的问题用不同的解决方法，然后就是功能角色分析和用例，用一些用例图给用户讲解软件的功能，而且还要会对业务流程的分析 ，许多软件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，而没有深入细致地去分析，往往到了项目后期才把需求搞懂，才发现真正的需求与起初的 认识大相径庭，才恍然大悟需求原来是这样，而往往那时已经追悔莫及了。这样的经历相信你也有过吧。所以，我们一定要沉下气来认真仔细地做需求分析，一定要做到位。最后就是对于一些非功能的用户需求，分析人员一定要细心的解决一些非功能需求，不能忽略。

最后就是对需求列表的确认，对于用户的需求的变更，这个令很多分析人员很难理解，但是这个还是要按照现实来编写，不能有一些天马行空的想法。

只有这样的学习，才能为以后的发展打下良好的基础。