在软件生命周期过程中，设计和维护通常是开发者们乐此不疲的话题，而编码过程几乎是开发者们避而不谈的问题，每当程序员进入一个开发过程时，他们不再抱怨需求的多么的不清晰，测试是多么的荒唐，取而代之的是他们开始享受这份编码的乐趣，这份静静地无人打扰的编码过程，尤其是当遇到了编程难题时，开发者们像打了“鸡血”一样，玩命的追踪这个问题，直到解决掉这个难题为止。
对于很多开发人员来说，得到了一份详尽的需求说明书，是他们的梦想。对于开发者的这份小小的梦想来说，很多公司也会尽可能的去满足他们，因为如果公司有了这份详细的说明书，开发人员就可以更加迅速的开发出他们想要的软件。然而，大多数情况下，都是事与愿违的。客户方面没有足够多的材料，公司方面没有足够多的设计师和需求工程师去整理这些需求。
这时候，开发人员必须要承担起编制需求文档的责任来，千万不能因为这块职责不属于自己的，就糊弄搪塞。对于企业来说，职责独立，业务解耦是为了提高企业的生产效率。而对于个人来说，要提供自己的综合实力，就必须尽可能多的掌握软件有关的所有的知识。对于个人来说，知识的耦合度越高，一个人的价值也才越大。当开发人员接到新的需求与挑战时，应该把它看做是个人职业道路上的台阶。只有抬步，才能走的更高，看的更远。
对于一个开发者来说，或许整理出的需求文档比不是需求工程师做的专业，但是整理出的文档，一定是开发人员最容易理解的文档，而且也能省去某些冗余的内容。通常来说，一个软件系统的需求可以用下面的公式来表示：
软件需求 = 上一期项目 + 客户现有的软件系统 + 其它厂商的相关软件系统 + 客户的定制需求 + 现有的项目规范 + 个人业务理解
上一期项目：很多项目的开发，都是在项目的上一期的基础之上进行开发的，了解上一期项目的内容，有利于对项目的整体需求有一个把控。
客户现有的软件系统：客户有时候的需求不是因为现有的软件系统无法满足他们的办公需求，或许仅仅是因为他们想要升级一下系统，使用新的架构改善现有的业务系统，来提高系统的响应速度。
其它厂商的相关软件系统：尽管弄个这个东西很困难，但是如果有其它厂商的软件系统可以作为参考的话，一定要参考其它厂商的方案。一个偌大的系统，总有一些经验是可以借鉴的。
客户的定制需求：客户的定制需求是客户最大的需求，如果软件无法满足这个需求的话，这个软件基本上也就无法成交。
个人业务理解：很多时候，客户的表达可能不是那么明晰，软件能否做的美观、大方，易用性，也看个人对于业务室怎么理解。
世界上没有最好的软件，只有更好的软件。时代在进步，科技在进步，软件也在进步。只有不断的学习科技知识，才能创造出更好的软件来。祝愿世界人民以后都用中国生产的软件。
