需求工程系列(二)- 基于用例的需求管理框架

网友投稿 728 2022-05-30

为了解决前文所述的软件需求困境,我们首先需要找到一种可以被各方真正理解和沟通、并可以被逐步精化的需求体系。我认为,这种体系应该是基于用例(usecase)的。

首先,让我们仔细研究一下用例的定义:

一个用例抽象了目标系统在现实中将执行的一组场景(每个场景由一系列动作组成);这些场景会产生一个对某个Actor有价值的、可观测的结果;

需求工程系列(二)- 基于用例的需求管理框架

在这个定义中,我们强调了两件事情:

一、用例是被从现实的场景中抽象出来的,而不是被随便发明出来的;

二、每个用例(场景)应能提供完整的商业价值。在未来的博文里会介绍这两条会如何帮助我们避免对用例的误用。

用例的优势在于它天生是黑盒的,它用自然语言抽象了用户和目标系统的交互,避免了混入分析、设计和实现细节,以保证用例可以被不懂具体技术的业务及测试人员所真正理解。同时,需求分析员又可以方便地通过用例分析(use case analysis)(即用分析类来试图在理想方式下实现用例),将需求体系精华成分析模型。在这一过程中,需求分析员可以更进一步地完善基于用例的需求体系,而不必担心分析模型会污染需求,从而实现需求与分析的分离及有效互动。

最后,我们必须指出,基于用例的需求管理体系中不仅仅包含用例,它还应该包括涉众请求,特性列表,前景文档,补充规约,词汇表等等。

用例其实是Ivar在许多年前发明的老技术了,现在被很多人所采用,而被更多人误用,下面的文章让我们看看一些对用例的典型的误解和误用。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:SENet双塔模型:在推荐领域召回粗排的应用及其它
下一篇:软件总结--与回顾
相关文章