当一个诺大的软件工程项目结束之后，对于技术人员来说，提心吊胆的感觉远远大于满心欢喜的心情，这是因为客户往往对于我们所完成的项目一脸嫌弃，总是要求我们改这改那，这往往会让我们失去对项目的满腔热血。那么为什么客户会经常对我们的“劳动成果”不屑一顾？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
知道问题的所在，那么我们该如何去做软件的需求分析？以及软件需求与分析需求我们掌握哪些必要的内容？总结来说，我们需要做到以下几点：相识——用以了解客户的性格与习惯爱好；交流——用以充分了解客户的真正需求；讨论——与同事讨论分析客户的需求；画图表——对所了解到的需求进行显示；灵活——对于用户的需求灵活变通；总结——需求分析结束之后要做的工作。接下来将对以上一点要掌握的内容进行分析讲解。
相识。所有任务的第一步就是与客户见面（当然并不是全都如此），通俗来讲，两者的关系是雇主和雇佣的关系，因此我们往往是以一种谦卑和客气的态度和客户交流，适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。为什么这么说呢？过于的谦卑，处处都是唯唯诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意。正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。所以我们和客户应该保持一种朋友的关系，相互理解和支持，这样才能真正理解客户的真正需求。
交流。首先是研讨会，在会上我们应该多和客户交谈，对于客户的不合实际的需求，我们应该勇于提出，并且给予能让客户满意的建议，毕竟相对于客户来说，我们更加专业，另外，用专业术语更能给客户安全感，从而能更加听从我们的意见和建议。交流是一个迭代的过程，经常和用户交谈，能更加深入了解客户，更好地捕捉到客户的所有需求，最终才能做出让用户满意的软件。
讨论。对于自己辛辛苦苦“讨来”的客户的所有需求，在我看来，自己的见解往往是片面的，对于客户的种种需求，我们无法全面理解，此时，和同职业的人讨论更能深入解决自己疑惑的问题。
画图表。当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。功能角色分析与用例图，功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
灵活。与客户相比我们是专业的，不能死死只看客户的需求，有些需求甚至是难以实现的，我们不能不知变通地直接上手，此时，我们需要先和客户商讨然后提出意见，对该功能进行修改，换一种方式去实现。
总结。编写需求规格说明书，用户需求规格说明书与产品需求规格说明书的差别并不大。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言，来表达大家都清楚明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。
