[图解]用例规约之写完需求后要对照涉众利益

2024-08-22 20:12

本文主要是介绍[图解]用例规约之写完需求后要对照涉众利益,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1
00:00:01,790 --> 00:00:04,940
我们写完了补充约束之后

2
00:00:06,430 --> 00:00:08,060
用例规约就算写完了

3
00:00:09,340 --> 00:00:13,190
但是这个时候我们还要和涉众利益对照

4
00:00:14,510 --> 00:00:18,500
我们对照涉众利益看

5
00:00:18,510 --> 00:00:20,750
涉众利益

6
00:00:21,240 --> 00:00:24,070
有没有照顾到,我们这个剧本

7
00:00:24,280 --> 00:00:26,230
我们用例规约相当于一个剧本

8
00:00:27,020 --> 00:00:29,190
我们这个剧本这样表演的话

9
00:00:30,020 --> 00:00:31,140
观众会满意吗

10
00:00:33,070 --> 00:00:36,620
至少要照顾到前面几排的涉众利益

11
00:00:37,800 --> 00:00:40,070
后面的照顾不到那就没办法了

1
00:00:00,800 --> 00:00:03,390
在这个地方,我们过一遍

2
00:00:04,410 --> 00:00:06,070
就可以减少很多风险

3
00:00:08,330 --> 00:00:10,630
因为后面的需求如果会变

4
00:00:12,640 --> 00:00:13,590
很可能是什么

5
00:00:14,100 --> 00:00:15,890
根本原因就是你涉众利益没有找到

6
00:00:16,760 --> 00:00:20,850
你之前写的需求没有照顾好

7
00:00:21,550 --> 00:00:22,830
应该照顾的涉众利益

8
00:00:24,080 --> 00:00:25,400
结果后面它冒出来了

9
00:00:27,210 --> 00:00:29,850
你没照顾到,你没看到,不代表它不存在

10
00:00:29,980 --> 00:00:30,450


11
00:00:33,010 --> 00:00:34,280
那么后面它必然冒出来

12
00:00:34,290 --> 00:00:36,200
冒出来,你又说哇,需求又变了

13
00:00:36,660 --> 00:00:37,970
没有那么厉害的

这篇关于[图解]用例规约之写完需求后要对照涉众利益的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1097275

相关文章

图解TCP三次握手|深度解析|为什么是三次

写在前面 这篇文章我们来讲解析 TCP三次握手。 TCP 报文段 传输控制块TCB:存储了每一个连接中的一些重要信息。比如TCP连接表,指向发送和接收缓冲的指针,指向重传队列的指针,当前的发送和接收序列等等。 我们再来看一下TCP报文段的组成结构 TCP 三次握手 过程 假设有一台客户端,B有一台服务器。最初两端的TCP进程都是处于CLOSED关闭状态,客户端A打开链接,服务器端

图解可观测Metrics, tracing, and logging

最近在看Gophercon大会PPT的时候无意中看到了关于Metrics,Tracing和Logging相关的一篇文章,凑巧这些我基本都接触过,也是去年后半年到现在一直在做和研究的东西。从去年的关于Metrics的goappmonitor,到今年在排查问题时脑洞的基于log全链路(Tracing)追踪系统的设计,正好是对这三个话题的实践。这不禁让我对它们的关系进行思考:Metrics和Loggi

十四、我们应当怎样做需求分析:子用例与扩展用例

用例模型作为UML中4+1视图中非常重要的一员,非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程,按照场景划分到了一个一个的用例中。由于场景的出现,使得用例中的业务流程存在着高度的内聚性,从而成为了日后各种对象的雏形。同时,在用例分析中,又将那些存在于各个用例中的,相同或相近的业务操作提取出来,形成一个一个的子用例或扩展用例,又体现了面向对象设计中的复用性。现在

十三、我们应当怎样做需求分析:查询报表分析

在我以往的用例分析中,使用这样格式的用例模式,对于大多数业务操作流程来说是得心应手的,但对于有些功能来说总感觉不对劲。感觉不对劲的,就是那些查询、汇总与报表功能。对于这部分功能,需要我们描述的不是什么操作流程,而更重要的是那些数据项、数据来源、报表格式、数据链接,以及使用者、使用频率的说明。而这些,在以往的用例说明格式中统统都没有,怎么办呢?俗话说“东西是死的人是活的”,把我们的用例格式改改吧。

九、我们应当怎样做需求分析:功能角色分析与用例图

在我们进行一系列需求调研工作的同时,我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司,我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时,我们应当首先将上次需求分析的结果与客户进行确认,同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。  但是,当我们经

八、我们应当怎样做需求调研:需求捕获(下)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

七、我们应当怎样做需求调研:需求捕获(上)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

六、我们应当怎样做需求调研:迭代

前面我一直在反复强调这样一个观点,需求分析不是一蹴而就的,是一个反复迭代的过程。它将从第一次需求分析开始,一直持续到整个项目生命周期。为什么这样说呢?让我们一起来分析分析。  在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获••••••  需求捕获,就是我们与客户在一起开研讨会

五、我们应当怎样做需求调研:需求研讨

前面我们探讨了业务研讨会应当怎样组织,下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底,那么讨论业务需求就是需求分析人员的功底。  以往我们常常认为,需求分析是一件最简单的事情。客户说他们需要做一个什么软件,有些什么功能,我们照着做就可以了,所谓的需求分析员就是需求的记录员。我要说,这是一个极大的错误,许多失败的软件项目,或者说软件项目中的需求问

【轻松上手postman】入门篇:如果根据接口文档写postman接口用例

在我们平时的测试工作中除了最基本的网页测试外,也会遇到没有页面但需要验证内部逻辑正确性的接口测试任务,在遇到没有网页的测试任务时,我们就要使用到接口测试工具来模拟对程序代码触发。 在接到接口测试任务时,一般都会拿到接口需求文档,没接触过接口测试的人看到接口文档正常反应一脸闷🤣不知如何下手怎么开始测试😓,下面我就来讲讲如何将接口文档上的一个个接口转换成postman用例 首先需要安装