首先，写这篇文章还是花了点时间的，所以转载请注明出处。
虽然才Enterprise Architect还没多长时间，但它杰出的管理能力，强大的功能，小巧的体积，柔和的界面设计，都让我非常惊叹！与之前的rose相比，Enterprise
Architect是我现在画用例图与做需求的首选工具。
对Enterprise Architect不了解的可以去百度一下。那么开始讲需求实例吧，就以“资讯浏览”为例子。这次我在做的项目中要求把需求写得很“细”，希望大家不要觉得很八股。
一般情况下，像“资讯浏览”这种需求是任何网站都有的，那么我们在做需求建模时可以它做成一个包。
这里需要明确一下需求是什么，虽然定义有很多，但我的理解就是“用户期望有的”。根据这个，我们就可以将资讯浏览当成需求项进行描述。在Enterprise
Architect中，在选中一个对像的时候，可以在侧边工具栏中打开Notes,直接在里面编辑需求描述。在这里我对资讯浏览写的描述是“客户经理可以按照资讯分类，对资讯进行分类浏览与阅读”。在写需求描述时，一定要将用户写清楚，我这里的用户是“客户经理”。如果写成“用户可以按照资讯分类，对资讯进行分类浏览与阅读”那就不完全正确了。
需要注意的是，对于需求描述用得最多的词往往是用户“可以”、“希望”、“能够”等词，非常八股。
接下来，就是要详细定义资讯浏览的需求点了。大家可以想想在浏览时用户会有哪些期望的需求呢？一般情况下，我们会看到列表，列表要不要看到摘要？对列表会有哪些排序？会不会有分页？需要什么样的分页方式……..
想不到随便想想就有这么多，那么做为需求项，就需要一个一个的来定义。双击创建的“资讯济览”的包，可以进入详细的可视化建模区。在右侧边栏中，我们可以创建需求点。
将要用的需求点都表示出来，最后出来的图就成了这样：
在图中，有些需求之间是具有关系的。如上图中的黑色实心箭头，表示 下方的需求项是伴随着箭头所指的需求项的，如果没有“文章排序”的需求，也就不存在“按时间排序”的需求点了。
还有一种空心箭头，表示需求项之间的关系是共存，也就是说当一个需求项不存在时，另一个也能够存在。
在画的过程容易遇到这样一个问题，有的需求点明显可以再分开，如上面提到的排序需求可以分解为按时间与按类别。那么什么样的需求点才应该被分解，什么样的需求点不需要在图中进行分解，而只需要在文字中写上一笔说明。其实判断依据很简单，按时间排序与按类别排序代表两个功能，所以可以分开写。如果是分页的话，虽然分页有几种方式，但实际做出的功能是一个整体，所以也就不需要分开写了。为什么要根据这种规则来区分呢，在本文最后我会解释。
再按照开始的方法,把这些需求项的描述写清楚.这里我只举几个例子:
分页选择方式：
客户经理可以灵活的选择需要浏览的页面。
分页提供三种分页选择方式：
1. 显示离当前页最近的9个页面的超链接。当前所在页没有链接。
2. 按“上一页”，“下一页”的方式进行翻页，当前页面处于首页时，“上一页”无链接。当前页处于尾页时，“下一页”无链接。
3. 允许客户经理直接输入需要查看的页面数。当客户经理输入项超过页面最大数时，直接进入尾页。
第二个
浏览文章：
客户经理可以浏览文章的详细内容。包括文章标题、出处、所属类别、更新时间及正文。
在所有需求项写完后，我们会发现之前的需求包已经变成了这样：
如果确认没有漏掉什么的话，那么“资讯浏览”的需求项就写完了。
再回到之前的问题，为什么需求点要根据功能点来分。其实很简单，在项目后期需要测试，那么完全可以根据这些需求点来进行验证，如果一个需求点对应一个功能，那么测试就变得很明确了。当然，这些并不是测试的全部，但做为项目管理来说，还是非常有实际意义的。
同时，在Enterprise Architect中还可以画用例图，当画完了“资讯浏览”的用例时，在完成用例描述后，还可以将用例与需求对应起来。这时，才算完整。程序员在做这个功能时，既可以通过用例描述了解交互过程，也可以对应需求了解关键点，减少疑惑，再加上界面原型，那么开发起来就非常明确了。
好了，需求建模的实例就是这样了，我写的这篇文章虽然不见得全部正确，还是希望能够帮助大家了解需求建模是怎么样的。以后我会再写一些需求与用例对应关系的应用实例。再重申一下，写这篇文章还是花了点时间的，所以转载请注明出处。
感谢洋洋，在我写文章的时候给带来了好吃的东东，嘿嘿。
|
