OO系统分析员之路--用例分析系列(6)--用例实现、用例场景和领域模型[整理重发]

本文继续探讨OO系统分析员的用例分析系列,重点关注用例的实现、用例场景和领域模型。通过业务用例实现视图、用例场景和业务实体模型(领域模型),对初步的业务分析进行细化,形成更全面的需求框架。同时,强调了用例文档(用例规约)和非功能性需求的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 上一篇说到我们经过初步的业务分析,得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架,并圈定了业务范围。这时应当做一份基线。

当然,第一份基线所包括的内容是非常粗的,要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物,以及这些成果对需求的贡献。在开始之前,还是提醒读者下载实例,本文下面只会从实例中挑选很少一部分来说明,对照实例读者将能更好的理解。

上一篇确定了业务用例,以及业务场景。该场景只描述了业务框架,接下来要对业务用例进行场景分析。用例场景分析要用到三种视图,业务用例实现视图、业务用例场景、业务实体模型(领域模型),每个业务用例还应当写一份用例文档,也称为用例规约(UseCase Specification)。若有非功能性需求,例如性能要求,吞吐量要求等,还应当写一份补充用例规约。用例规约将在下一篇描述。

 

  • 首先是业务用例实现视图。并非所有的业务用例都一定要最终在系统中实现,因此,这个视图的含义是表达由需求范围到系统范围的映射关系。这个视图没什么技巧,也可以省略,不过笔者建议不要省略。需求应当保持过程的连续和可追溯性,这是软件过程可控的重要保证。

    业务用例实现视图: 
    业务用例实现视图

     

  • 针对每个业务用例实现,应当对用例的实现过程进行场景模拟。上一篇是业务场景,而用例实现既然已经谈到“实现”,则应当将计算机包括进来,从人-机交互的视角来模拟业务场景。这是概念模型的一种,表达用户的实际业务在计算机环境下是如何实现的,给用户一个初步印象,告诉他们将来他们将怎样来做业务。请注意,虽然计算机已经参与需求描述,但是要尽量避免使用计算机术语,因为这时的文档仍然属于需求文档,是要与用户交流的,太多的计
评论 12
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值