谈谈需求(下)

谈谈需求(下)

         上一篇啰啰嗦嗦讲了半天，好歹把用户需求跟功能需求扯开了，但是讲完用户需求分析，发现篇幅已经很长了，怕大家没耐心看下去，所以只好就此打住，另起一篇来谈谈功能需求规整，也就是通常说的《需求规格说明书》。

         功能需求规整，核心要素无外乎三者——用例、原型、ER图。

用例用来描述用户在预实现的软件系统中的操作流程。原型图用来直观描述系统主要用户操作界面与主要交互流程，方便系统设计人员与业务用户做直观的需求沟通与辨析。而E-R图，则主要用于描述系统将会用到的业务实体对象（或叫业务领域对象）的特征与关联关系，是软件系统对现实世界中特定概念模型的一种高层次抽象化、结构化表述。这三者中，用例是核心，原型图作为用例的图形外化扩展，起着连结业务用户与系统设计人员的桥梁纽带作用，而E-R图，作为用户需求中对现实世界中特定概念模型的第一次抽象的载体，为最终系统领域对象模型与数据结构模型的形成打下基础。

原型

         先说说原型图吧，一是因为它最简单直观，是未来系统的界面层预呈现，二是因为它也是本人比较纠结的地方。若按照功能用途来放，原型图似乎应该放在《需求分析报告》中，因为它首先是用来与业务用户沟通业务需求用的，以便更好地帮助业务用户表达他们内心真正的业务需求期望，并给出形象化描述信息；但是我还是将它归类在了《需求规格说明书》中，因为完整版(高保真或低保真)原型图，后续也是业务用户与系统设计师对系统最终功能实现的预期值达成一致的契合点，是用来指导UI开发的。

原型图作为系统最初的界面实现内容表述载体，是业务用户、开发人员、系统设计人员、UCD设计人员四者沟通功能需求实现并达成一致系统实现目标的最直接承载体与实现依据——既是UCD设计人员界面设计思想精华的直接产物，也是开发人员实现系统功能的最终展现目标，还是系统设计人员产品设计思想的第一版图形化产物。

         具体工具而言，用的比较顺手的是axure，简单快速，虽然笔者也用过Visio，但是效果与开发效率不如axure。

       原型虽然重要，但也不是万能的，原型图强在界面呈现，弱在功能流程表述。对于稍复杂一点的系统，同一个界面都可能会支持好几个不同场景的数据呈现，就原型而言，如果仅仅为了描述不同操作场景而画多张大同小异的高保真图确实很有点奢侈，会累死美工mm去的。这个时候，用例就开始派上用场了。

用例

         用例，准确切来说，貌似应该叫用例建模，包括用例图与用例描述两部分。给一段从网上Copy的定义：

         用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

         还是比较抽象对吧，那看看我的吧（其实我也是先copy，然后补充扩展的，嘿嘿），用例是用于表述系统对于一系列用户操作的响应，也就是系统的功能性需求或行为，可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例的系统处理过程与分支场景，文以文本段落的形式来完成。

         一幅最简单的用例图如下所示：

         每个系统的参与者可以分多种角色，不同角色拥有不同权限，可执行不同系统操作。这种操作权限通过用户与用例单元的连线来体现。如上图中将系统的参与者分为了两种角色——系统管理员与普通用户；系统管理员用户拥有所有权限，而普通用户仅拥有“查看客户端列表”的权限。

         用例图最重要的作用在于确定系统边界，即从全局出发明确该系统要实现哪些功能，并将功能粒度化，同时明确系统参与者的角色与各角色的权限。虽然是这么简单一句话，但是要将一套完整的系统用例图画出来可不容易，因为用例设计的过程其实就是软件系统第一次功能设计的过程，是一个全局统筹、客观冷静的功能需求规整过程。一套系统用例图设计出来了，这个系统的功能模块的划分也就出来了。

在我们的《需求分析报告》中，针对每个用户需求，我们分析出了很多功能点，这些功能点只考虑到了单个用户需求的实现，所以不可避免的，从不同用户需求分析得出的功能点列表中，肯定有重复功能点或者相近功能点。功能需求规整的第一大工作就是要将这些功能点去重、整合，从用户需求到功能需求的分析归纳过程大致如下图所示。

         而功能需求规整的第二大工作就是功能模块设计，这部分工作看似简单，实则最复杂最不可确定。因为它既与产品定位强相关，也要充分考虑用户交互。这两者在进行功能模块设计时不可避免的会产生冲突与矛盾，这种冲突通常就体现在软件设计师与交互设计师对系统设计的冲突上，而冲突与矛盾的化解恰恰就反应了软件设计师的功底。

如果说用例图设计是一个统筹全局的工程，那么用例描述的编写则是一个精耕细作的过程。在此需要再次明确下——用例描述，描述的是系统逻辑处理过程，更倾向于面向软件设计师与软件开发者，应尽量用系统语言来进行描述。

一个完整的use case大致包括以下内容：功能需求编号、用户需求编号、功能需求描述、参与者/角色、前置条件、输入、输出、处理过程、其他说明。

         示例表格如下：

3.2.2客户端添加

功能需求编号

R.Func.Module1.001

用户需求编号

P.Func.Module1.001

P.Func.Module2.004

功能需求描述

用户在客户端添加界面能通过IP地址添加客户端；

参与者/角色

ITMS系统管理员

前置条件

1.         用户已经登陆ITMS系统，并进入了“客户端添加”界面；

输入

用户输入IP地址、端口号，点击“添加”按钮

处理

1.      用户单击“添加”按钮；

2.      系统读取并检查“IP地址”文本框中数值，若符合IP地址规则，则执行下一步操作，否则弹出提示框提示用户“IP地址格式错误，请重新输入”；

3.      系统读取“端口号”文本框中数值，若符合端口号输入要求，则执行下一步操作，否则弹出提示框提示用户“端口号输入错误，请重新输入”；

4.      系统根据IP地址与端口号数据，执行客户端发现操作，并对操作结果做如下处理：

    a)        若指定IP存在活动客户端，则将所获取数据存入数据库表中，同时弹出消息框提示用户“客户端添加成功”，用户点击“确定”按钮后，清空原界面数据以便用户继续添加操作；

    b)        若不存在，则弹出消息框提示用户“客户端添加失败，可能是该客户端程序未开启”，用户点击“确定”按钮后，不清空原界面数据以便用户更正数据。

输出

添加操作执行结果

其他说明

1.       IP地址必须为IPV4地址格式；

2.       端口号必须为正整数值；

 

功能需求编号：用于将功能需求(即Use case)编码，以方便需求跟踪。格式一般为R.Func.ModuleName.001。

用户需求编号：用于记录此use case中满足了哪些用户需求的功能点，可以是多个，编号来源于《需求分析报告》；

功能需求描述：一般就是从《需求分析报告》中各业务需求分析得出的功能需求点的集合，每个Use case涵盖了所有业务需求的相同或相似功能点；

参与者/角色：用于说明哪些角色用户有权限执行此usecase；

前置条件：用于说明执行此use case的系统环境，例如需要用户先进入某个功能界面、需要用户先执行了某些操作等；

输入：用户执行此use case的数据性触发条件，例如输入文本框内容、点击某个按钮等；

输出：系统执行完此use case后的界面结果性信息展示，例如列表显示查询结果信息；

处理：用于描述系统执行此use case过程中进行的程序处理逻辑步骤，不需要达到伪代码级别，但是要条理清晰、步骤明确，方便将来在概设中将各步骤抽象成类方法；

其他说明：用于备注执行此use case时的约束性信息或规范性信息；

 

E-R模型图

         E-R图相对而言就比较简单了，援引维基百科上的说明应该就比较清楚了：

E-R模型,全称为实体联系模型或实体关系模型或实体联系模式图(ERD)(Entity-relationship model)由美籍华裔计算机科学家陈品山发明，是概念数据模型的高层描述所使用的数据模型或模式图，它为表述这种实体联系模式图形式的数据模型提供了图形符号。这种数据模型典型的用在信息系统设计的第一阶段；比如它们在需求分析阶段用来描述信息需求和/或要存储在数据库中的信息的类型。但是数据建模技术可以用来描述特定论域（就是感兴趣的区域）的任何本体（就是对使用的术语和它们的联系的概述和分类）。在基于数据库的信息系统设计的情况下，在后面的阶段（通常叫做逻辑设计），概念模型要映射到逻辑模型如关系模型上；它依次要在物理设计期间映射到物理模型上。注意，有时这两个阶段被一起称为"物理设计"。

         从这段定义可以得出以下几点：

a)        E-R图是需求分析阶段的产物；

b)        E-R图是逻辑模型（也就是数据库表模型）设计的基础，所以应该将其归类在与《概要设计说明书》关系更加紧密的《需求规格说明书》中，而不是需求分析的前期阶段《需求分析报告》中；

c)        E-R图是一种概念模型的表述方式，是对现实世界各类个体的第一层信息化抽象，关注的是这一类个体的共同属性；

d)        E-R图也需要将不同类个体间的通用关系表述出来，以便在逻辑设计阶段将其进一步抽象为数据表关系；

e)        如果对面向对象开发比较熟悉，特别是对OR-Mapping技术有一定了解的读者，在此处便可初步总结出将来系统中会用到的实体对象(Entity)；

 

E-R模型是一种比较接近人的思维模式的信息表述方法，使用简单的图形符号表述软件设计师对问题域的理解，即使不熟悉计算机技术的用户也能理解它，因此，ER模型也可以作为用户与软件设计师之间有效的交流工具。

　　实体(Entity)：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体;在E-R图中用矩形表示，矩形框内写明实体名；比如学生张三丰、学生李寻欢都是实体。如果是弱实体的话，在矩形外面再套实线矩形。

　　属性(Attribute)：实体所具有的某一特性，一个实体可由若干个属性来刻画。在E-R图中用椭圆形表示，并用无向边将其与相应的实体连接起来；比如学生的姓名、学号、性别、都是属性。如果是多值属性的话，再椭圆形外面再套实线椭圆。如果是派生属性则用虚线椭圆表示。

　　联系(Relationship)：数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下 3 种类型：

(1) 一对一联系 (1∶ 1)

　　例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

(2) 一对多联系 (1∶ N)

　　例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教【见下图】。

(3) 多对多联系 (M∶ N)

　　例如，上图表示学生与课程间的联系(“学 ”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。联系也可能有属性。例如，学生“学 ” 某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩 ” 既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学 ”的属性.

总结

         很多人分不清《需求分析报告》与《需求规格说明书》的区别，更有甚者，鱼目混珠，混淆视听。其实这些人是不懂用户需求与功能需求的区别，而之所以不懂，大部分是因为没有从头至尾开发过一个完整系统，没有做过全过程的系统分析与设计，不明白各个分析设计阶段的真正价值所在。

         其实软件工程这一整设计流程就像剥白菜心一样，只有求实谨慎、脚踏实地才能最终取到最鲜嫩的那一颗黄金般的菜心。现在，我们还只剥了两层菜叶，若您有兴趣，我们可以一起来拨开还剩下的几层紧致但是有路可寻的菜叶。

 

         说实在的，写这种文章真的很耗费心力，写完半篇文章比工作一天还累。不过看到洋洋洒洒四千五百字就这么出来了，也还是挺有成就感的，小小激动下，继续努力，后续把全流程文档谈完，我们再来聊聊现在热情似火的敏捷开发与软件工程的关系。

参考文献

         什么是原型设计

http://jiangtao-xu.blog.sohu.com/129532751.html

什么是原型设计？

http://blog.sina.com.cn/s/blog_643917d90100gz2h.html

         关于原型设计的一些事

         http://www.ikent.me/blog/4477

         初学UML之-------用例图

         http://blog.csdn.net/dl88250/article/details/1826713

         详解UML建模之用例图关系

         http://developer.51cto.com/art/201111/302360.htm

         用例

         http://zh.wikipedia.org/wiki/用例

         ER图

         http://wiki.mbalib.com/wiki/ER图