从用例到代码，第二部分：用例设计

第1章前言

目的

需求调研是为需要说明书做前期工作，可以说需要说明书说是从需求调研表中得到或抽取而出。

需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程，再把这些需求开进细节整理由设计部开发，再由销售部销售给用户。

用户：系统分析人员

回页首

第2章前期准备

2.1. 确定工具

• 没有什么工具是好还是坏的问题，问题是关键是如何使用它们，无论是什么工具也只是一个辅助工具，也不是生成工具。
• 工具的选取要求是自己（本组）熟悉的工具，不能是一件最新时髦工具而自己对它了解很少，结果大部分时间化在学习工具上，而不是使用它为你工作。
• 工具最好也是要求是普通流行的，因为要考虑交流的问题。

2.2. 要做什么就要先了解什么

• 如果做的项目是你所不了解的一个行业（专业）同组有要最好有要专家----最终用户做为这个专家是最好的，最少你有了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），不然您甚至不知道去问什么问题或者如何去问他们，甚至于人家在说什么你也不知道。
• 相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要求更深入的一些资料。当然有专家的参入就另当别论。
• 如果行业的难度不是很大，可以通入分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。

2.3. 建立设计环境

一定建立一个专门的设计环境来为本项目服务，进行一定的资源分配，进行必要的文件管理。

2.4. 真正了解自己和用户

• 那些是用户可能明确要达到的目地
• 要知道那些是自己能做到的，那些是自己不能做的。
• 对于不能做的处理方法，如拒绝，转包等
• 那些是用户想要做到的

2.5. 列出人员分配表和所有工具列表

• 明确项目人员分工
• 统一项目所用的工具
• 统一项目文件模版
• 其它资源列表（资料，相关网站，资询电话。。。）

回页首

第3章调研过程

3.1. 搜集需求得到需求说明书

注意：

1. 虽然最终必须要编成基于计算机解决方案的描述，但到目前为止，我们关注的焦点的文档在相应领域方面的部分。
2. 记住这里没有计算机方面的行话，如果是编写一个会计软件，那么一位会计师都应该清楚地理解程序员写的会计方面的问题说明书
3. 需求说明书问题中，不要太正式。只要描述能表达您想要做的事情就行了，就和另外一个人在说话一样就可以。
4. 对于客户或相应人员了解问题时，一定要有记笔记的习惯，谈上几个小时，很多细节是记不住的。

3.2. 整理，检查和细化需求说明书

1. 对于客户的需要进行必要的整理和分类有进从用户那里会得到很多信息，不行进必要的整理就不能从中进行合理的分析
2. 分清有用功能、可选功能用、无用功能及不可实现功能对于用户来讲他可以说出他想要的很多功能，但这些功能间的关系有时是清晰的，但对于很多用户来讲想通过计算机或新系统实现他以前没有的功能，在这时他所提出的新需求的可行性和与其它模块之间的关系就已经不清，所以对于分析员来讲，要从用户的需求中分清有用功能和无用功能和可选功能，进行分别区分处理，比如不可实现功能请用户放弃。
3. 不要忽略明显的错误用户倒是不经常提及他需要的东西，而这些东西对问题来说都是很基本的，要细化检查一定有注意这个问题。
4. 你认为的也许不是对的对于系统分析员对需求分析的自认为的情况要加以注意，对于一个行业来说，有些规则可以不是最合理，但它就是那样存在和使用，所以对于每一个非明确确定的需求，要由专业人员来审定。除非你就是专家。

3.3. 改进

最初的第一次需求在分析，细化一定有不明及不确定之处，那么就把整理出一份问题细化问询表，对发现的问题进行整理，列出不明之处，可根椐以下格式

问询人：
            问题：
            业务不清问题列表（业务描述不清）：
            1 ….是什么含义？
            2 …..与XX是什么关系？
            多种选择可以列表（请用户进行选择）：
            1 ……有多个可能，那么现在我们使用
            A ……   B…….   C……..  D ……

3.4. 审核需求

1. 自我审枋
   把自己从用户的角度来考虑
   是否合理，是否可以提高效率，是否可以达到目的，是否有完整
2. 由用户来评价
   由最终用户来评价你所列的需求是否达到了用户要求（用户人数1-3人，再多也没有什么益处）。
3. 重复过程，最终通过审核完成需求说明书

参考资料

• 标准版API 规范，JAVA 2 核心技术和其他方面的信息。