|
|
使用实例的描述并不向开发者提供他们所要开发的功能的细节。如果你在用户需求阶段
停止了需求开发，你将会发现在软件的构造阶段，开发者必须询问许多问题来弥补他们的信
息空白。为了减少这种不确定性，你需要把每一个使用实例叙述成详细的功能需求（ A r l o w
1 9 9 8）。
每一个使用实例可引伸出多个功能需求，这将使执行者可以执行相关的任务；并且多个
使用实例可能需要相同的功能需求。例如，如果有5个使用实例需要进行用户身份的验证，你
不必因此编写5个不同的代码块。
可以用多种方法来编写与一个使用实例相联系的功能需求文档。采用何种方法取决于你是否希望开发组从使用实例文档、软件需求规模说明，或二者相结合来设计、构造并测试。这些方法都不完善，因此选择那些最适合你编写文档和管理项目的软件需求方法。避免在不同地方产生信息冗余，因为冗余将使需求管理变得更加困难。
1. 仅利用使用实例的方法
虽然你仍可能需要用一个独立的软件需求规格说明来记录与特定的使用实例无关的需求，
但是一种可能的方法是把功能需求包括在每一个使用实例的说明之中。你必须交叉引用在多
个使用实例中重复的那些功能需求。一种方法是可以通过先前讨论的“包括”的关系来阐述，
在这一关系中一些公共功能（如用户身份验证）被分割到一个独立的，可重用的使用实例中。
2. 利用使用实例和S R S相结合的方法
另一种方法是把使用实例说明限制在抽象的用户需求级上，并且把从使用实例中获得的
功能需求编入软件需求规格说明中。在这种方法中，你将需要在使用实例和与之相关的功能
需求之间建立可跟踪性。最好的方法是把所有使用实例和功能需求存入数据库或者业务需求
管理工具中，这将允许你定义这些跟踪性联系（见第1 9章）。
3. 仅利用软件需求规格说明的方法
第三种方法是通过使用实例来组织软件需求规格说明，并且包括使用实例和功能需求的
说明。采用这种方法，你无需独立编写详细的使用实例文档；然而，你需要确定冗余的功能
需求，或者对每个功能需求仅陈述一次，并且无论需求是否重复出现在其它使用实例中，都
要参考它的原始说明。
|
|
