1. PMD

     1)PMD是一个代码检查工具，它用于分析 Java 源代码，找出潜在的 问题：
1)潜在的bug：空的try/catch/finally/switch语句
2)未使用的代码：未使用的局部变量、参数、私有方法等
3)可选的代码：String/StringBuffer的滥用
4)复杂的表达式：不必须的if语句、可以使用while循环完成的for循环
5)重复的代码：拷贝/粘贴代码意味着拷贝/粘贴bugs
2)PMD特点：
1)与其他分析工具不同的是，PMD通过静态分析获知代码错误。也就是说，在
不运行Java程序的情况下报告错误。
2)PMD附带了许多可以直接使用的规则，利用这些规则可以找出Java源程序的许
多问题
3)用户还可以自己定义规则，检查Java代码是否符合某些特定的编码规范。
3)同时，PMD已经与JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、
CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、
IntelliJ IDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs
集成在一起。
4)PMD规则是可以定制的: 可用的规则并不仅限于内置规则。您可以添加新规则：
可以通过编写 Java 代码并重新编译 PDM，或者更简单些，编写 XPath 表
达式，它会针对每个 Java 类的抽象语法树进行处理。
5)只使用PDM内置规则，PMD 也可以找到你代码中的一些真正问题。某些问题可能
很小，但有些问题则可能很大。PMD 不可能找到每个 bug，你仍然需要做单元测
试和接受测试，在查找已知 bug 时，即使是 PMD 也无法替代一个好的调试器。
但是，PMD 确实可以帮助你发现未知的问题。

1. FindBugs

     1)FindBugs是一个开源的静态代码分析工具，基于LGPL开源协议，无需
运行就能对代码进行分析的工具。不注重style及format，注重检测真正
的bug及潜在的性能问题 ，尤其注意了尽可能抑制误检测(false positives)
的发生。以bytecode（*.class、*.jar）为对象进行检查。除了单独动作，还可
以用作Eclipse 的plug-in，以及嵌入Ant作为task之一 进行利用。
2)findbugs自带检测器的介绍:  findbugs自带60余种Bad practice，80余种
Correntness，1种Internationalization，12种Malicious code
vulnerability，27种Multithreaded correntness，23种Performance，
43种Dodgy。
3)Findbugs的一些特点：
1)FindBugs主要着眼于寻找代码中的缺陷，这就与其他类似工具有些区别了，
直接操作类文件（class文件）而不是源代码。
2)FindBugs可以通过命令行、各种构建工具（如Ant、Maven等）、独立的
Swing GUI或是以Eclipse和NetBeans IDE插件的方式来运行。                
3)FindBugs输出结果既可以是XML的，也可以是文本形式的。
4)开发者可以通过多种方式来使用FindBugs，最常见的是在新编写模块的代码
分析以及对现有代码进行更大范围的分析。   
5)不注重style及format，注重检测真正的bug及潜在的性能问题，
尤其注意了尽可能抑制误检测(false positives)的发生。    
4)FindBugs可检测的bug pattern举例:
检测java programing中容易陷入的bug pattern，equals() 实现时的一般规约违反
Null pointer的参照 ，Method的返回值的check遗漏 ，初始化前field的访问，
Multi-thread的正确性， 同期化处理的矛盾， 无条件的wait()，  Code的脆弱性 ，
可以变更的静态object ，内部数列参照的return等

1. Checkstyle

     1)定义： Checkstyle是一款检查Java程序源代码样式的工具。
2)特点：
1)它可以有效的帮助我们检视代码以便更好的遵循代码编写标准，特
别适用于小组开发时彼此间的样式规范和统一。
2)Checkstyle提供了高可配置性，以便适用于各种代码规范，所以
除了使用它提供的几种常见标准之外，你也可以定制自己的标准。
3)Checkstyle提供了支持大多数常见IDE的插件，大部分插件中就含有
最新的Checkstyle，就不用费心再部署一份了。
4)Checkstyle可以检查代码的很多方面，从传统观点看，它主要是用来
检查代码层面的，自从第三版以后，它的内部架构作了重大改变，很多
其它意图的检测加了进来，现在Checkstyle可以检查像类设计的问题，
重复代码，如锁的双重检查的bug模式。
3)CheckStyle的主要流程是：
1)对Java文件进行词法语法分析，生成语法树。
2)载入配置文件（checkstyle-metadata.xml以及自定义的配置文件）
register check事件。
3)按照深度优先遍历对语法树进行解析，按照注册的事件，在到达某些节点
( AST ) 时进行style检查（AST，A child-Sibling Tree，是语法
树中的某个节点，其类型在TokenTypes类中定义。）
4)我们所说的自定义Style的检查，就是在第二步设定的。
这里牵涉到一个叫com.puppycrawl.tools.checkstyle.api.Check 的类，
我们通常需要重载其中的两个函数： public int[] getDefaultTokens()
        和public void visitToken(DetailAST ast). 这两个函数的含义为，
在遍历语法树的过程中，每当到达getDefaultTokens函数所返回的AST类型，
程序就进入visitToken进行具体的检查和分析，即，真正的分析检查过程是在
visitToken中实现的。

1. Hammurapi

     1)定义： Hammurapi它是一个开源的代码审查/评审(review)工具。它可以帮助改进
Java代码的质量。它可以基于一套设计规范来分析代码库。当它碰到违反规
范的地方，会在报告中标识。就像Checkstyle一样，它与Ant无缝集成并且
由基于XML配置文件来驱动。
2)特点：
1)Hammurapi是用来强制代码设计规范的。
2)Hammurapi是一个遵循设计的工具，提供了自动而且一致的方式来实现设计规范，
因此使代码评审更加有效而轻松。
3)Hammurapi如何工作：
         Hammurapi这样的代码分析工具都带有语言分析器。语言分析器是一种输入
语言代码并输出抽象语法树的工具。这个树上的节点代表语言标识。例如，考
虑一下简单的算术表达式：3+4. 语言分析器会解析他成为一个如图5所示的语
法树。在这个树中，节点+代表操作符标识。节点3和4是操作数标识Hammurapi
使用ANTLR（另一个语言识别工具）作为语言分析器。然而ANTLR API是相当底层的。
为改善可用性，Hammurapi使用另一个API，基于ANTLR 的JSEL（Java源程序
工程类库），来访问抽象语法树。 一旦树构建完成，一种树遍历算法就被用来访
问树中每一个节点。每次访问到一个节点，一种回调机制（Visitor模式）被用来
提示相应的检查器。在这些回调方法中，检查器收集相关的信息来确定是否有违反
规范的地方存在。　　

1. Lint4j

     1)定义:Lint4J是一个针对Java的源代码分析工具，它可以对Java源码和字节
码进行静态分析，判断其中是否存在死锁、性能问题或者伸缩性问题。
它可以集成到任何IDE种或构建系统
2)特点：
1)检测代码语法规则
2)潜在的bug
3)检测编码模式对代码可读性及大小的影响
4)检测是否违反EJB规范

1. Sonar

     1)定义：代码质量管理工具Sonar提供了设计与架构度量。Sonar 2.0引入了
针对Java应用的设计分析、架构与面向对象的度量，Sonar 2.1可以
检测到未使用的方法以及对不建议使用方法的调用。是一个集成了
CheckStyle,PMD,Findbugs的代码校验规则 ,重复代码发现，
代码测试覆盖率， 代码注释率，及所有的检测率变化追踪的完美
代码质量检查工具。它包含了代码质量检测的七个方面，如下图
2)特点：
        1)代码覆盖：通过单元测试，将会显示哪行代码被选中。
2)改善编码规则。
3)搜寻编码规则：按照名字，插件，激活级别和类别进行查询。
4)项目搜寻：按照项目的名字进行查询。
5)对比数据：比较同一张表中的任何测量的趋势。
6)单元测试
3)Sonar2.1：
Sonar还基于Squid引入了一个全新的规则引擎、Sonar解析器既可以处
理源代码，也可以处理字节码，解析器带有内建的规则，可以检测未使用
的私有与保护方法以及客户端对不建议使用的方法的调用。
Squid通过分析应用源代码、Java API和外部程序库
的字节码来决定哪些方法、类和属性是不建议使用的。
Sonar 2.1的新特性：
1)一个全新的“Libraries”页面，显示了项目中所有的程序库和依赖，该特性要求使用
Maven来构建项目。
一旦在Sonar站点的主页上选择了一个项目，该服务就会以
可视化的树形结构展示出项目依赖。此外，还有一个可选的
动态过滤器，可以根据名称过滤程序库以便在应用的依赖间导航。
2)用于搜索程序库使用情况的“Dependencies”页面。比如说，可以
搜索到使用了第三方框架如Commons Logging 1.1的所有项目。
3)可以使用各种插件扩展Sonar的功能。现在有一个全新的
“System Info”页面显示了系统属性、已装插件和Java虚拟机内存
统计信息。该页面还给出了关于Sonar配置和数据库统计的详细信息。
4)一个用于管理已装插件和系统信息的管理控制台。
最新版的Sonar为这些插件引入了一个测试框架和一个客户化的Maven
生命周期管理工具。它还带有一个用于集成项目事件的
Web Service并在项目的size widget中增加了一个新的度量模块。

1. JDepend

     1)JDepend一个开放源代码的可以用来评价Java程序质量的优秀工具，
它遍历Java class的文件目录，以Java包（package）为
单位，为每一个包/类自动生成 包的依赖程度，稳定性，可靠度等
的评价报告，根据这些报告，我们可以得到包或类之间的依赖关
系，并分析出包的稳定程度，抽象程度，是否存在循环依耐关系等 。
可以根据JDepend给出的报告数据，分析出我们的包是否是
可靠的，稳定的，健壮的包，是否符合面向对象的设计原则。
2)特点：
1)评价设计质量
2)翻转依赖性
3)支持并行开发和极限编程
4)独立的发布模块
5)识别package的循环依赖
3）Depend生成的Java包的质量评价报告主要包括：    
1)Number of Classes and Interfaces：实现类与抽象接口的数目
2)Abstractness (A)：包的抽象度。指一个包内包含的抽象类或接口
占整个包中的类的比重。
3)Afferent Couplings (Ca)：向心耦合。依赖该包（包含的类）的外
部包（类）的数目（i.e. incoming dependencies），该数值越大，
说明该包的担当的职责越大，也就越稳定。
4)Efferent Couplings (Ce)：离心耦合。被该包依赖的外部包的数目
（i.e. outgoing dependencies），该数值越大， 说明该包越不独
立（因为依赖了别的包），也越不稳定。
5)Instability (I)：衡量一个包的不稳定程度。I=Ce/(Ce+Ca)。它的值处于
[0，1]之间。I=0时说明包是最稳定的，反之I=1则说明包极不稳定。
6)Distance from the Main Sequence (D)： 该指标主要用来评价包的抽象
程度与稳定程度的平衡关系，它可以用二维直线图 A + I = 1 来表示。
7)Package Dependency Cycles：包的循环依赖度。
8.  IBM Checking Tool for Bugs Errors and Mistakes(简称BEAM)
1) 定义：是 IBM 开发的一个静态分析工具，可以用于分析并查找出 C, C++ 和 Java
代码中的一些不容易发现的潜在错误，从而达到提高代码质量的目的。同动态
分析工具和其它静态分析工具相比，它拥有一些可贵的特性。
2)特点：
1)对代码进行语法扫描，通过算法对代码进行检查分析
2)和一些 bug 模式进行比较，最终标明问题区域，输出分析结果
3)使用了额外的定理证明（theorem proving）技术来判断一个潜在的错误是否
是真正的错误，从而减轻了程序员判断错误真伪所需的工作量
 9. LDRA Testbed  
1)定义：LDRA Testbed为应用软件的确认和验证提供强大的源代码测试和分析功能，
是独特的质量控制工具。 它有助于提高计算机软件必需的可靠性，健壮性和尽
可能的零缺陷，它的使用带来时间、成本和效率上真实的节省，这些都是无法衡
量其价值的。它是强大和完整的集成工具包，使先进的软件分析技术应用在开发生
命周期的关键阶段。
2)LDRA Testbed提供强大的分析功能，用于两个主要的测试领域，静态分析和动态分析。
1）静态分析： 分析代码，并且提供对代码结构的理解。
2）动态分析： 利用源代码的插装版本，使用测试数据执行，在运行时发现软件
缺陷
3) 使用LDRA testbed 的好处
软件开发和测试过程的成本效率分析工具
单元、集成和系统测试的理想工具 
贯穿于软件开发的整个生命周期
LDRA Testbed应用于许多不同的领域 
过程改进
软件测试
软件维护
LDRA Testbed的优点：
改进软件质量
定位软件缺陷
强制执行工业标准
减少维护费用40％以上
减少开发和测试成本75％以上
通过自动化过程提高员工动力
10.   Yasca 
1) 定义：yasca是一个开源静态代码分析工具插件框架,　集成流行的多语言静态分析工
具如findbugs/pmd/jlint/rats/cppcheck,由于插件本身多样故可支持java
c++等语言静态分析.Yasca是一个用来寻找安全漏洞，在程序的源代码中检测代
码质量、性能以及一致性的软件。它集成了其他开源项目，其中包括FindBugs
PMD ，JLint ， Cppcheck ，并扫描某些文件类型，以及自定义扫描书面的
Yasca 这是一个命令行工具，与报告中生成的HTML ， CSV格式， XML的，的
SQLite ，和其他格式。

　　Java Excel API 文档

　　http://www.andykhan.com/jexcelapi/

  java api 帮助文档 chm 1.5 1.6 中文版英文版. 收藏
Sun 公司提供的Java API Docs是学习和使用Java语言中最经常使用的参考资料之一。但是长期以来此文档只有英文版，对于中国地区的Java开发者来说相当的不便。目前Sun 公司正在组织多方力量将此文档翻译成中文，并于2005年10月31日在Sun 中国技术社区（http://gceclub.sun.com.cn/）正式发布第一批中文版Java API文档（包括java.lang和java.util类库API 文档的中文版）。经过将近10个月的努力，目前我们已经将Java SE 5.0的全部API文档中文化。开发人员可以通过Sun 中国技术社区的网站在线浏览相关文档，也可以将全部文档下载到本地以方便检索和使用。
J2SE DK & API下载
-------------------------
http://java.sun.com/j2se/1.3/download.html
http://java.sun.com/j2se/1.4.2/download.html
http://java.sun.com/javase/downloads/index_jdk5.jsp
http://java.sun.com/javase/downloads/index.jsp
J2EE DK & API下载 
-------------------------
http://java.sun.com/j2ee/1.3/index.jsp
http://java.sun.com/j2ee/1.3/download.html
http://java.sun.com/j2ee/1.4/index.jsp
http://java.sun.com/j2ee/1.4/download.html
http://java.sun.com/javaee/downloads/index.jsp
JDK1.6API中文版（全）
-------------------------
* HTML 格式(在线英文) http://java.sun.com/javase/6/docs/
* HTML 格式(在线中文) http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/html/zh_CN/api/index.html
* zip 格式(中文) http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/html_zh_CN.zip
* CHM 格式(中文)  http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/chm/JDK_API_1_6_zh_CN.CHM

JDK1.5API中文版（全）
-------------------------
* HTML 格式(在线英文) http://java.sun.com/javase/5/docs/
* HTML 格式(在线中文)  http://gceclub.sun.com.cn/Java_Docs/html/zh_CN/api/index.html
* zip 格式(中文) http://gceclub.sun.com.cn/Java_Docs/html_zh_CN.zip
* CHM 格式(中文) http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/builds/JDK_API_1_5_zh_CN.CHM

相关网站
-------------------------
http://java.sun.com
http://gceclub.sun.com.cn/
http://developers.sun.com/downloads/
http://java.sun.com/javaee/downloads/
http://java.sun.com/javase/downloads/
http://www.netbeans.info/downloads/
 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhsp1029/archive/2008/04/05/2253865.aspx

VLAN的好处在于有效地限制了L2的广播域。对于有线网络，常见的VLAN划分方法包括基于交换机端口的划分、基于MAC地址的划分、基于L3的IP划分以及基于802.1x的安全凭证划分等，这方面的资料比较多，支持的产品也很多，应用很成熟。

但对于WLAN，该如何划分VLAN呢？

WLAN的网络结构基本单位是BSS。BSS有两种形态：独立基础结构（IBSS，也叫自组网Adhoc）和基础结构Infrastructure。自组网就是多个站点自发组成一个可以互通的WLAN，而基础结构模式则以AP为中心，其它站点都先与AP关联，然后才能与BSS中的其它站点进行通信。以下所提到的BSS仅指基础结构。

WLAN中的VLAN划分必须要有AP的支持。每一个VLAN由一个VLAN ID来标示，因此以什么作为VLAN ID的依据，决定了VLAN在哪个层次划分。根据VLAN与BSS的关系，WLAN中的VLAN划分有几种情况。

1. 以MAC层依据作为VLAN ID

一个AP至少可以组建一个BSS，而且不少实际的产品还支持同时虚拟出多个BSS，每个BSS拥有不同的BSSID。对于每个BSS，一些AP产品还可以同时支持多个SSID，不同的SSID共享大部分的BSS配置和Radio接口配置，可以有少部分配置不一样（比如密钥）。

1.1 以SSID或BSSID为划分依据

一种容易实现的VLAN划分方法就是以SSID为划分依据，每个SSID对应一个VLAN ID。这种划分依据完全来自于802.11 MAC层的SSID，因此可以完全在AP内部实现。根据AP对多SSID支持情况的不同，具体情况又有所不同。

1.1.1 AP支持多个BSS，每个BSS又支持多个SSID

这种情况下按照SSID来划分VLAN，所有连接到该SSID的站点都属于同一个VLAN。每个SSID提供给STATION的接入端口均为VLAN的Access端口，是不带tag的端口。

由于一个BSS内有多个SSID，因此一个BSS内就会有多个VLAN。由于这些SSID均属于同一BSS，因此如果位于两个VLAN内的STATION要通信，只需要经过AP内部的转发桥接即可。

1.1.2 AP仅支持一个BSS，每个BSS支持多SSID

这种情况下按照SSID来划分VLAN，跟上面的情况类似。

1.1.3 AP支持多个BSS，每个BSS仅支持一个SSID

这种情况下SSID与BSSID一一对应，因此根据SSID来划分VLAN与根据BSSID来划分是一样的。这种情况下属于同一个BSS的站点属于同一个VLAN，位于两个VLAN内的STATION要通信，只需要经过AP内部的转发桥接即可也仅仅需要AP内部的转发。

1.1.4 AP仅支持BSS，每个BSS仅支持一个SSID

这种情况下如果按照SSID或BSSID来划分VLAN，则整个BSS均属于同一VLAN。由于不存在多个VLAN，因此不存在VLAN互通的问题。

可见，如果在同一AP内部划分不同的VLAN，那么这些VLAN间的互通仅需要AP内部的MAC桥接即可实现，而不需要将数据交到更高层进行转发或桥接。

1.2 以MAC地址为划分依据

这种情况根据STATION的MAC地址在BSS内划分VLAN。AP根据从STATION发来的帧中的源地址决定该STATION所属的VLAN，从而可以保证同一VLAN的互通和不同VLAN的桥接。

上面的两种划分均是以802.11 MAC层的信息作为VLAN ID的划分依据，因此同一VLAN内部的转发和不同VLAN之间的桥接均可在AP内部实现，而不需要分发。

在上面的两种情况下，在AP内部只需要维护两张表即可：一张表是VLAN ID与VLAN依据（SSID/BSSID或MAC地址）之间的对应表，另一张表示VLAN ID与VLAN接口之间的对应表。Access端口上的数据收发情况如下：

进入Access端口的数据：可以不带tag。如果需要分发到AP外（目的地址不是BSSID且不是任何BSS中的其它站点），则加上tag通过分发接口分发；如果不需要分发到AP外，则有几种情况：

DA为BSSID，则由AP接收并处理；
DA为同一VLAN中的其它STATION，则MAC层转发；
DA为不同VLAN，但同一AP中的其它STATION，则执行VLAN之间的桥接协议。
从Access端口发出的数据：不带tag，直接发到STATION。

这种划分的缺点仅适合于较小的网络，灵活性较差。比如，无法实现跨AP的VLAN，也就是连接到不同AP的两个STATION无法划分到同一个VLAN。

2. 动态VLAN划分方式

动态划分方式并不由AP来决定VLAN ID，而是由其它更高级的设备来决定。一种方法是由RADIUS服务器来划分。当一个STATION与AP关联时，AP中的RADIUS客户端与RADIUS服务器进行通信，从而得到该STATION所属的VLAN ID。RADIUS决定STATION服务器所属VLAN的依据可以是用户名、IP地址等，因此具有很大的灵活性。当用户的位置改变后，他所属的VLAN仍然不变。

采用动态VLAN方式后，同一个AP的同一个SSID中的两个STATION可能属于不同的VLAN，而连接到两个不同AP中的STATION却可能属于同一VLAN。因此这种情况下，要实现同一VLAN中不同STATION之间的互通，需要更高层的转发和桥接，可能需要经过位于WDS接口或以太网DS接口等接口之上的VLAN trunk、hybrid端口。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/rangzh/archive/2008/07/02/2606778.aspx

从用例到代码, 第一部分： 用例分析

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

第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 核心技术和其他方面的信息。