你有这样做过需求分析和设计吗？

-----读《Java How to Program, 6Edition》(英文版)有感。

 

转眼Advanced Java Programming 这门课就结束了，说是Advanced，其实也没有讲太深，主要就是将面向对象、GUI、ArrayList、DataStructure等做了特别讲解。由于推荐教程是《Java How to Program》，所以这次特意研读下这本书，其实最新版已经是8Edition了，基于JDK1.6的，我手里的6Edition还是基于JDK1.5的。全书1100多页，全英文看着都恐怖，呵呵~~~不过静心阅读发现还是非常好的，尤其是里面的Case study，非常有感触，第一次让我感觉到老外的编程学习思路与国内的课程确实不同。

 

言归正传，前十章有个Software Engineering的Case Study，以实现一个ATM机为案例，讲解了从需求分析、设计、到实现的整个过程。

 

首先，说说需求文档。这个案例的第一章就是描述需求，与我们日常软件开发和项目实施相同。因为只是实现一个模拟ATM机的小程序，所以文章不长，需求部分也就大概A4纸三页左右。但是却将ATM机的功能、操作、输入输出等描述的非常清楚。当然这只是一个案例，所以肯定有案例的局限性，我们重在学习思路。

回想当年自己做项目实施时候的需求文档，简直就是千差万别。过去我在做项目实施时，需求文档中感觉基本都是废话连篇，实际上是写给用户看的，而项目组内部基本上写完就完了，实施过程从来不拿来用。事实上也不能拿来用。我可以简单罗列下其中的主要部分：

    1。 系统概述：介绍下实施的背景和目标等；

    2。 业务需求分析：主要是分析用户、用户组织机构（也即用户层级和关系）、业务流程；

    3。 数据需求：分析系统的数据需求情况；

    4。 功能需求：罗列用户对于系统的功能的需求和表现形式；

    5。 性能需求：用户期望系统能达到什么样的性能级别；

    6。 安全性

    7。 运行环境：软硬件设施。

看上去，逻辑结构清楚，层次分明，好似这样的需求基本符合要求。可是实际上具体实施时有很多问题，因为只描述只浮于表面，未能够深入其内。举个简单的例子，业务流程、数据到功能的表现是关联的，写文档时却独立了，没有明确其关联关系，像三张皮，业务流程只描述业务流程，如果描述清楚还好，描述不清楚就是废话。因为如果遇到项目实施时间分配不合理或其他因素，需求分析并没有经过充分的需求调研，技术人员对用户的行业知识不够深入，都会导致业务流程部分只能是简单讲讲，更有甚者直接从其他文档中Copy，开始来是那么回事，应付用户就好了。这样当然不会考虑什么与数据的关系。后期设计开发也自然不会拿来用，因为看了也没意义。功能部分也是同样的问题，回想之前我做的项目，大大小小参与过的十几个，无一不是花个图，描述或解释下功能是干什么的就没了。好不容易有个规范的，写到了数据的输入输出，用了UML的Use Case Diagram但是输入输出的数据与上面的数据需求部分毫无干系。基于这些原因，我们写出来的需求分析报告也就自然无法在后续的项目实施中使用了。肯定有人会问，不依托需求，后续如果进行，哈哈~~~这就是问题的关键，就那么弄呗，还能咋得，这不有用户嘛，于是乎，用户说应该这样就这样，应该那样就那样，没有流程，自然也就需求不可控。用户变成了功能测试者，因为他不会帮你去梳理业务流程，对他来说看到的只是功能不对，项目也就一拖再拖，一改再改，程序员累死，项目仍然没有起色。想想以前的经历，真是惨痛，很是失败~~~~~

 

那么，需求分析应该如何做呢？（不一定正确，仅我个人观点，不同的软件实施过程方法各有不同，特此声明！！！）

作为需求分析我认为一定要将用户的业务流程、数据、功能、展现形式等描述清楚，并且其相互关系一定要讲明白。而不能像独立的一页一页纸一样，各自是各自的。

    比如以ATM为例：

    首先这个东东的构成：

        给用户显示消息的显示屏；

        接受用户输入键盘；

        用户收取现金的现金出口；（可以理解为输出）

        用户存钱的入口：（可以理解为输入）

    核心数据当然是钱了，其他数据就不多说了。

    然后假设一个ATM机包含查询账户、取钱、存钱这三个核心功能。以取钱为例描述其操作步骤：

        1。显示器显示一个标准的取钱数量菜单选项：100,200,500,1000,2000，其他，菜单项中还要包含一个允许用户退出的选项；

        2。用户使用键盘输入一个键盘选项；

        3。如果选择或者输入的取款数量大于用户现有金额，显示器给出提示消息并告诉用户选择一个更小的值。 此时ATM 回到第一步。如果权限数量小于或等于用户现有金额，ATM继续进行下一步。如果用户退出取款，ATM回到主菜单并等待用户输入；

        4。如果ATM中有足够的现金满足用户请求，ATM继续进行下一步。否则，显示器提示用户并告诉用户选择更小的数值。此时ATM回到第一步。

        5。ATM在数据库中从用户的现有账户中减去要取的钱。

        6。现金出入口将用户取的钱送出给用户。

        7。显示器提示用户将钱取走。

 

我们可以看到整个流程还是很清晰的，符合程序实现逻辑。然后真正写文档时不是这么简单。有了这样的需求文档，下一步怎么做呢？看看书中的方法，我觉得非常有用：

    1。 将需求文档中的所有名词罗列出来，并分析和筛选，因为这将是你的Entity Class，即是系统中可能需要定义的实体类，当然也不一定全部都是实体类；如对于ATM的需求，我们分析出来有以下一些名词：ATM, 显示屏（Screen），键盘（Keypad）， 取款口（Cash Dispenser），存款口（Deposit Slot），账户（account），银行数据库（Bank Database），账户查询（Balance Inquiry），取款（Withdrawal，因为这里是名词），存款（Deposit）

    2。 既然类已经出来了，那么各个类之前是什么关系就可以描述了。可以使用UML中的Class Diagram，描述各类之间的关系。

    3。 然后每个对象的属性我们也可以分析了；也就是定义Attribute，即类的成员变量，然后每个成员的变量的数据类型也可以分析出来。

    4。 类的属性有了，就可以描述对象的状态，那么这个状态还可以从需求文档中的形容词或者限定词中筛选。然后在使用流程图来表述这些的对象的行为，比如说取钱，存钱，账户查询应该是什么流程。使用UML的State Diagram和Activitiy Diagram描述。

    5。 各类之间的关系，对象的属性，状态，工作流程全都有了，就剩定义类的操作了，也就是对象具有的行为，类的方法。此时可以再次从需求文档中找出描述上述名词的动词短语，因为这些动词短语就告诉我们这个对象要执行那些操作，他要具有什么行为，也就是我们要定义的方法。

    6。 然后对象执行的操作总要有流程，根据上面的工作流程，描述各对象（类）之间的交互关系和执行序列关系。使用UML的Communication Diagram和Sequence Diagram。

    7。 这样从需求分析到设计就出来。

 

我们可以看到，这才使使用需求文档，再回想之前的需求文档如何使用，功能描述没有流程可循那如何分析呢。我们定义的每个类，设计的所有内容都要从需求上来，这样整个系统才有逻辑结构。才是正真的面相对象设计。而且这样做需求和设计，之间就可以细化到详细设计。每个类，以及其属性、方法、接口都已经明确了，日后需求变更也很好维护，代码实现也就很简单了。

 

虽然这只是书中的一个案例，也许和实际项目差距甚远。但是还是能感觉到，国外项目实施与国内项目实施的不同之处：通过对需求文档中的名词、形容词（限定词）、动词短语分析得出设计框架。这也让我对之前自己在国内进行项目实施举步维艰的困境有了深刻感受，需求不明确，设计浮于表面，何来的顺利实施项目。除了这个案例，在这么课程最后的结课作业中，lecturer提供了需求文档，这份需求文档也可以按照上述此路来进行分析和设计，与我之前自己项目实施中的非常不同。我觉得这种思路还是非常有用，可以借鉴之~~~~特此记录。