文档介绍：第九章面向对象的需求获取 与需求分析
需求获取是获得系统必要的特征,或者获得客户能接受的、系统必须满足的约束。
需求工程的目标是定义构造系统的需求。需求工程主要包括两个活动:
(1)需求获取,即导出用户可理解的系统规格说明;
(2)需求分析,其结论是给开发者无二义性解释的分析模型。
在这两个活动中,需求获取更具有挑战性,因为需求获取需要在多个具有不同背景的参与者团队之间进行协作。
采用场景和用例的沟通技术是弥补上述代沟的有力工具。
场景表达了用户和系统之间的一系列交互,描述了一个系统实例。
用例是对一类场景所进行的抽象。
场景和用例两者均用自然语言描述,这一形式对用户而言是易于理解的。
需求获取是关于开发者、客户和用户之间为了定义新系统而进行的沟通。
在需求获取过程中,如果无法及时发现所犯错误,将使得整个系统交付延迟。
这里所提到的错误包括:丢失了系统必须支持的功能、不正确的功能描述、引起误导或不可用的用户界面,以及无用功能等。
需求获取方法的目标,就是为了提高开发者、客户和用户之间的沟通。
对需求获取的总的看法
需求获取将注意力放在系统目标的描述上。
开发者、客户和用户共同标识了一个问题域,定义了解决这一问题域的系统。这类定义称为需求规格说明,这类定义可用于开发者和用户之间的沟通。
在分析过程,形式化需求规格说明,以产生分析模型。
需求规格说明和分析模型之间的区别,仅仅在于其所用语言和记号的不同;
需求规格说明通常用自然语言来书写,而分析模型通常用形式化或半形式化方式表示出来。
需求规格说明支持客户和用户之间的沟通。分析模型支持开发者之间的沟通。
需求获取和分析应该将注意点放在用户对系统的看法上。
需求获取包括如下活动:
(1)标识参与者。
(2)标识场景。
(3)标识用例。
(4)求精用例。
(5)标识用例之间的关系。
(6)标识非功能需求。
在需求获取期间,开发者将访问不同的信息资源,包括:
客户所提供的、与应用域相关的文档和手册
将被未来系统替换的遗留系统的技术文档;
用户和客户本人。第三个方面是最重要的信息资源,因为开发者在需求获取活动期间的最多活动是与用户和客户之间的交流。
在需求工程期间,常常使用一种称为联合应用设计(Joint Application Design,JAD)的沟通技术,即用户和开发者联合开发需求规格说明,将注意点放在营造开发者、用户和客户之间容易进行沟通的气氛上。
需求工程中的跟踪性将注意点放在记录、形式化、联结、分组和操作需求之间的依赖关系,以及需求和其它工作产品之间的依赖关系上。