幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。总结许许多多失败的原因，但归根到底更多的还是需求的问题。这篇文章，非常详细准确地描述了软件需求分析的重要性。
我们应当怎样做需求调研？
此书主要从客户的一些需求分析作为出发点，对用户的需求作大量的研究，从不同的角度做分析。我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。
对项目进行初始之后，就要进行拜访了。需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。
再接着，我们就要进行各具特色的研讨会。业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
在与客户进行研讨之后，接下来就是内部进行研讨了，讨论客户的潜在需求等问题。
接下来的迭代贯穿于整个开发周期，反复进行。
然后进行与客户交流，挖掘潜在需求。
在挖掘潜在需求之后，就需要重要的建模来表示了。进行功能角色分析和用例图的创建，分析各个角色的作用和相应的操作需求。
每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。用例分析实质是需求人员的一份设计。
我们进行相对应工作后，就开始制作报表。报表作用体现的是报表对于不同用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据链接、非功能需求，以及最后的界面原型，等等。
子用例与扩展用例 这部分里用例图中“按单位汇总考核结果”应该和前面几个查询是扩展关系，而不是父子关系。父用例应该是抽象的，共性的东西，子用例是具体的，个性的东西。 子用例继承父用例，使用或者重写父用例的部分内容。扩展则是对被扩展用例功能上的延伸，扩展用例不影响被扩展用例，被扩展用例可以单独存在。所以，我觉得 两者是扩展关系。因为“按单位汇总考核结果”是依赖于前面的查询结果的，但查询结果不因为是否汇总而受影响。对于一些用例，这种东西对于一些用户来说根本看不懂，这时候分析人员必须要用其他通俗易懂的话对用户进行指导。
对于软件需求与分析这门课来说，我认为必须要掌握一些必要的知识 ，我们应该学会调研，掌握调研的方法和技巧，对于用户提出的功能需求进行严谨的调查落实，从不同身份的人员进行调查，来确定最终的结果，对于这些问题，可以开展一些研讨会进行交流，由于需求分析有不同的方法，对于不同的问题用不同的解决方法。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。 明确了需求的定义，原则之后，接下来就是需求的过程。需求包括准备，收集信息，编写需求规格草稿，评审规格，评审后修改等五个阶段。其中最重要的是收集信息。信息的主要来源是人，文档和系统，但是最重要的来源还是人。与此同时，对所要实现的系统也要足够熟悉。做好信息的收集是做好需求的基础。
我们应当在实践中，按照这些步骤去具体操作，深入体会软件需求分析的重要性和艰难性，对掌握软件需求分析能力有着更进步一步的提升。
