软件需求与分析——读后感
需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。我们需要学会的就是如何和客户交流，做出需求分析。其中包括需求调研，需求分析，需求确定这三个大方面。
需要调研，我个人认为，需求捕获最有必要学习。文章中也有提到它是整个需求分析工作中最重要的部分。需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。已经远远超出软件开发这个知识领域，但是我觉得这就是它的难点。我们不仅要学习书本，还要不断练习。另外，我们在需求捕获时，必须采取主动态度，不能成为记录员，然后原封不动的丢给开发人员。这样获得的需求不仅不易理解，而且变态不易实现。并且再记录也只会是冰山一角。我们要做的是要主动出击，善于挖掘隐藏的需求。我们在需求分析的整个过程，不断进行业务领域知识的学习，了解客户所在领域的业务规则。当我们可以深入地理解这些领域知识，站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求。当我们达到这样的水平，隐藏的需求就会被发掘出来，最终做出来的需求分析才是完整的、准确的。才不会给项目开发的后期带来巨大的风险。另外，我们要站在项目开发的真实意图的基础上，用自己的专业知识分析，去发现客户不需要但是在开发中会出现的需求，防止客户需求在后期改来改去。
在捕获时，我们为什么要主动呢？因为在与客户交流的过程中，难免会有分歧，这个时候需要双方的沟通，而不是一味的记录。这个是最重要的。
在需求分析中，我觉得就是在分析之后可以绘制用例图，充分体现出整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。它是沟通用户与技术人员的桥梁。用例图用户视角是用户，也就是说，我们需要站在用户的角度来观察的我们需要设计的系统。取名时，应该在用户的角度起名字，使得用例的命名容易理解。另外，绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。不能一概而论，只有一个用例图。重要的是我们不能浮于表面，而是要深入细致的分析，落实到详细的每一步，这样才能保证项目的顺利进行。另外我们要明白和铭记做需求分析应当化繁为简，不必去拘泥于那些过程。还要注意非功能需求，非功能需求更加靠近的是技术，是设计，是实现，是我们关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。
在需求确认中，最重要的应该是学会对需求的跟踪。无论我们如何分析与设计，如何变更，我们都要如实记录原始的需求，并以此来验证我们最终的软件。所以我们需要建立需求列表。其记录的是最开初的、最完整的、正确的业务需求。它是以业务人员的口吻表达的。学会快速原型法，来解决软件上线后客户不满意的情况，在分析的阶段就拿出实物来和用户确认。利用它的好处是用户在讨论需求时各种需求会源源不断的被提出来，许多的问题会被简化，也可以建立与用户的信任。坏处是做出的系统并不是最终交付的系统，一定要和用户解释清楚，总言之，原型法只是可以使你更加顺畅的与用户确认需求。最后一定要编写需求规格说明书，我们要本着本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。学会采用RUP统一建模的方式分析需求，编写需求规格说明书的模板。