完整的需求集合包括：inputs，outputs, functions, attributes of the system（reliability,maintainability,availability, and throughput）, the attributes of the system environment.
需求应该排除项目相关信息，包括：进度，项目计划，预算，测试及涉及信息。
设计约束：对系统设计或开发系统的过程的约束
三种需求：
Functional：功能性（输入，输出，提供给用户的功能）
Nonfunctional:非功能性（Usability,Reliability,Performance,Supportability）
Design constraints:设计约束(对系统的设计或开发过程的约束，不影响系统的外部行为，但是必须被完成以满足技术、业务、合同中得要求)
细化用例
用例模型要经常被审查，并经常被重构。
好的详尽的用例：定义了所有可选择的流程，前置和后置条件，特殊的需求
增加的用例关系：include,extend,有利于维护用例模型
开发补充规格说明
用例：主要反映对用户或外部设备可见的行为
哪些需求需要给出补充规格说明：
（1） 功能性需求
a 注重算法和计算性的系统
b 很多应用均是幕后工作
c 解析输入句子，语言翻译系统
（2） 非功能性需求
Usability: (1)Specify the required training time for a user to become minimally productive or operationally productive
(2)指明完成典型的人户或交易所需要的时间
（3）将本系统与用户已知系统的适用性对比
（4）指明在线帮助系统，上下文相关帮助，用户手册等是否存在及特性
（5）遵循人机界面的约定
Reliability:（1）availability(2)平均故障时间（3）平均修复时间（4）准确性（5）最大错误或缺陷率（6）Bugs per type入：critical, minor,significant,注意以上都要定义什么是availability等
Performance:
（1） 事务的相应时间：最大，平均
（2） 吞吐量：每秒的平均事务数
（3） Capacity：系统能容纳的客户或者事务数目
（4） Degradation modes:系统degrade后，可以接受的操作模式。
（5）
Supporability:
Other:
在UML中use case通过collaboration来实现
协作：用虚线画的椭圆来表示。协作出现在设计模型中。
协作有两个aspects：
结构方面：描述了系统的静态结构（类，元素、接口、子系统）
行为方面：指定了系统为达到某个结果各个元素之间如何交互，描述了动态行为。
模型既可以用来描述用例定义的功能性需求，也可以描述非功能型需求。
从用例到测试用例：
用例技术可以直接用来驱动测试过程。
从用例得到测试用例：
1， 确定use-case scenarios.(一个use case会产生若干个senario)
2， 对每个场景，确定一个或多个测试用例
3， 对每个测试用例，确定让他执行的条件
4， 通过添加数据来完成test case
