软件需求的方法论（1）

一、从故事谈起
    话说在上世纪50年代的一个人民公社的领导，找到我们软件公司的项目经理，说我们有一个项目由你来做吧。

    项目经理：“yes sir,你的需求是什么？”
    公社领导：我对公社养牛的家伙很不满意，他养的牛满足不了我们放卫星的要求，我想要一头吃的草比现在的牛少一半，干的活比现在的牛多一倍的新牛（像不像你们的BOSS）； 我的需求很明确吧？
    项目经理：是的是的；我现在可以写出需求规格说明书了，然后你鉴上字，确定下来，我们就可以开工了。
    公社领导：好，就这样定了。

   在需求分析与评审会上，我听到了这个项目的初始需求，项目经理带回来的是让项目组开发出一头新牛的生物工程项目。

    如果按项目经理理解的需求，我们需求玩把DNA技术了，呵呵，反正软件公司是万能的嘛。

    可事情真的是这样？

    其实真的不是这样的，在项目经理与用户的交流过程中用户已经把实际需求显性的说了出来，其实就是想如何利用第三方产品或工具提高生产效率。

    如果项目经理能在需求分析过程中把握好用户的产业特点，并能理解用户的需求，那么提出的解决方案就能真正解决用户所存在的问题。  

    故事讲起来很轻松，可我发现在实际工作中我们的项目经理们经常在做生物工程。
    如何在工作中正确的识别需求是项目成功的基础，这一点没有人会反对，可做起来非常不容易。但是，科学的思维和方法论为我们提供了捷径。

所以这个解决方案很简单，卖给他们几台拖拉机！

二．软件需求分析的方法论

按照哲学观点：方法正确，结果就一定正确。软件需求分析应该在科学的方法论下指导完成的。什么时候需求分析的科学的发放论呢？第一，全局理解业务；第二，抽象出业务模型，剔除功能实现细节；第三，研究核心业务需求，剔除次要业务需求。

 

软件开发如建房子，和你如何装修好无关系，你可以把墙敲了，你可以东墙补西墙，但与建筑框架毫无关系。

 

在软件开发中，界面是依赖于市场策略的，是依赖于业务系统的。而不是市场策略或者业务系统依赖界面。通过界面去思考和发现问题，是错误的路线，虽然，界面很形象，让人一目了然，但是这样的路线只能看到表面现象，而看不到实质。古人都说了：“道可道，非常当，名可名，非常名”。要看到问题的实质，要剔除直观思维，剔除次要的因素，进入抽象思维，抽象出问题的核心，加以思考。

 

    现代软件的开发，需求分析是融入到开发环节中的，需求分析的成果之一，就是得出系统的业务模型（不是界面），借助UML，业务模型直接就可以用于系统开发之中，把这些业务模型，直接转化为程序开发的代码。

 

三，需求分析的几个层次，

        1，包含哪些实体。（实体关系渗透到了业务关系，所以在分析实体的时候，是基于业务，但是这个阶段主要研究一些抽象的概念）

        2，包含哪些功能或者说业务。（实体之间的关系如何建立，理论上，实体不依赖于业务）

        3，界面，界面是最后的环节，仅仅是如何展现的问题，和实体，业务关系都不大。

 

（待续）