UML简单介绍(二十二)——基于UML的需求设计分析

1、需求的内容

文档的介绍，产品介绍，产品面向的用户群体，设计和开发遵循的标准或者规范，产品的功能性需求和非功能性需求。这样的一些内容在J2EE开发的时候是非常重要的，在Android移动端开发似乎并不是那么重要，外包公司除外。

绝大部分的移动互联网公司，都是迭代式的开发产品，不断根据市场行情来变更需求，所以很少有成文的文档和需求设计。但是学习这样的设计规范，会理清楚我们的整个开发流程，让你做应用更加得心应手。需求文档的模版，在网上有很多，其华为的一些文档是比较靠谱的，可以参考使用。

文档的介绍，一般要包括：文档的目的，文档的范围，读者对象，参考手册，术语与编写解释等。

2、项目评估阶段

大多数的需求分析是在细化阶段进行的，并且伴有产品品质的早期编程和测试。初始阶段会持续的做需求分析，可以认为在进入测试之前，都是初始阶段。初始阶段不是需求阶段，初始阶段要做：项目的设想，是否可行，成本估算，是购买还是开发等等。

3、需求的阶段

一般如下的几个阶段：

第一次需求：评估及非功能，这里就和上文提到的项目评估是一样的了。需求的第一步不是上来就问业务，更不是上来就问流程。需求的第一步需要了解客户的预期运行环境，客户的预期效果，以及客户可能提供的资源等信息。同时，要对这个需求甚至整个项目进行评估，包括质量的评估，投入人力及各类资源的评估，还有周期的评估。

第二次需求：领域边界，做到什么地方，尤其是确定功能模块和子模块有哪些。

第三次需求：功能性需求，具体的模块，需要实现每一个子模块的功能。最好包括，用例图，时序图，对象图。

第四次需求：界面需求，界面需求已经是非功能性的需求，主要是界面的美观等需求。用户体验的沟通，主要是用户期待的界面，操作习惯等等和一些细节上的问题。

然后，以上四个需求不断的迭代，形成最后的产品。

4、迭代式需求

1）四要素

环境和前提：需要知道是哪些人在使用，需要使用什么语言，用多久（在Android中笔者曾经使用过第三方的后台，）？

子系统和子模块：先搞清楚有多少子系统，然后才是子模块。一层一层的向下剥离，不推荐直接在某一个单一系统划分太深。

R&P：确定了系统和模块之后，需要开始具体的业务模型和场景，开始进行具体的某一个模块的功能与用例分析。

界面原型：这里就是我们常说的UI原型了，实际上在做移动开发中，需求分析什么的都已经在产品经理和设计师的讨论下就定下来了，程序员开始做的时候，就会直接拿到这样的界面原型。

2）五原则

沟通＋建模＋成文

沟通很重要，在充分沟通的基础上，我们要使用建模工具，比如思维导图等来说明你的需求，最后还要落实成为一个文档或者需求。

文不如表，表不如图

有时候，我们发现，你使用文档很难说清楚你的需求，在使用语言的过程中有时候会产生一些歧义，这个时候，如果使用图表来表示，会清楚很多，也会更加直观。

至顶而下，逐层细分

需求应该是从顶上到下分析，还记得我们在RUP模型介绍中，有一个V字型的模型，可以看看，与他类似。一般来说，在做分析设计的时候，要尽可能涵盖用例的运行语境，显示相关目标的生命周期，最好能够为底层用例提供一个目录表。

一般来说，一个模块的用例不应该超过7个，如果超过，可以考虑进行一个细分。

业务＝R&P

R可以表示是我们的资源，P表示是我们的计划，对资源做计划，就是我们的业务。这个与我们的四要素提到的类似，不再赘述

拥抱变化，不断重构

在最开始的时候，需求点可能不会想得那么详细，在后期不断的沟通和使用过程中，可能设计的东西与预期不符合，就会进行一些调整。

3）三轴线

简单来说就是立体图形了，分为X、Y、Z三个维度。

Y轴是相对独立的功能需求，例如菜单的顶层结构，互不影响，可以算是单独的功能性需求，它不依赖别的模块。，X轴是贯穿整个系统模块的，是被依赖的功能模块，比如权限系统；Z轴是我们的非功能模块，比如安全性，健壮性，美观性等等包括我们的日志系统，也是非功能性需求。

5、迭代式需求步骤

1）需求是连接客户和设计的桥梁。客户是不专业的，设计是专业的，需要通过这样的需求文档或者用例来进行沟通。

2）需求是需要有一个分析设计过程的，不要直接给设计的原始需求，所以需求一定要先整理，理清楚顺序逻辑等。

3）需求的时候，不要去想设计，先听完整体的需求，不要听一个设计一个。不过这一点对大型系统而言，我们在迭代式开发的时候，大多是边需求边设计。

4）需求的时候，功能对象要和界面对象分开来。在移动端，现在有很多第三方的SDK提供了逻辑实现给你，而需要你自己去做界面设计。

5）做功能需求的时候不要去看美工或者设计师设计的界面，你应该先关注你的逻辑实现。

6、需求成文

对于项目的需求，了解需求点之后，一定要形成文档。第一是确定这些需求，第二是明确责任（这一点做过外包，或者接过私活的程序员应该很懂的吧）。对于文本需求，最好是两方面都能看懂，比如word，Excel或者是UML，XMind都行。

我们为了提升工作效率，也总结了需求成文的四大要素，只要满足这样的四个要素，基本就可以完成一份比较靠谱的文档。

1）系统运营的环境和前提

2）模块，子模块；系统，子系统。使用自顶向下设计，分清层次，从第一层开始，抽丝剥茧

3）资源和计划（R&P），使用用例图（场景和业务的描述），时序图（流程）和类图（对象）

4）界面原型（界面原型更多是UI来完成的，所以这个不一定是客户必须给的，最好是我们提供一套给客户选）

7、软件工程模版

这里可以按照上面的四要素，组成一个简单的模版，就不再赘述了。网上有流传一份华为的需求文档，虽然很老了，但是还是不错的，大家可以找来看看。

附录，添加一个附件文档，点击打开链接