终于看完了
我可以说,我终于看完了吗...这本书我两天看了两遍。总得来说,收获一般,一方面是因为翻译,感觉就像是机器翻译的,看着那翻译我能推出原文的结构,看着文字就是它认识我我不认识它;另一方面,是因为和预想的有点不大一样,就我目前的经历来说,很多地方看起来还没啥感觉,也许过两年就有感觉了。
1. 我为什么要看这本书
我做了4年的需求分析,唯一写过的用例就是测试用例。写这本书之前,我以为这本书是关于怎么通过写测试用例来检验需求质量的,结果发现只对了一半。但是总的来说,还是学到了不少东西,对以后写需求文档会有帮助。
2. 从书中获得比较大的收获是什么
对于我而言,要充分把这本书用起来,就要想想如果让我做一个新的架构,或者是做一个新的功能模块,我要怎么着手,从0做到1. 以下是我从书里摘抄出来的,比较有用的。
1. 概要用例是描述整个系统或者整个模块要做什么事情。只需最简洁的语言,确保所有项目相关人员都明白我们在做什么,并且确定大家都同意接下来要做的事情。
2. 在描述用例的时候,其实一共要描述四个部分:概要,主功能场景,失败情况,失败处理情况。这其实是四个层次,要先描述第一层,做完第一层之后再做第二层。不要马上开始深入讨论主要场景或者失败处理情况,这样很浪费精力,也容易精疲力尽,更重要的是,当上层用例出现问题的时候,前面的功夫就全部白费了。
3.在描述的时候,把一些用户用例紧密联系在一起,显示它们是如何与业务方针相配套的。它描述了关闭,清除和获得一个申请的过程,而该项目中的许多人对这些内容都不太了解。尽管其中有一些步骤并没有为编程人员做什么工作,但是它们还是处理申请事务情节中的一部分。对于每位读者来说,他们都是很重要的信息。
4. 在编写用例的时候,一定要考虑两种情况:最小保证和成功保证。最小保证是指当用例失败的时候,对项目相关人员的保护,实现对他们的最低承诺。常常容易被忽略的最小保证即是系统将其执行进度情况记入日志。而成功保证则是说明项目成功之后,项目相关人员的哪些利益会得到满足。
5. 我们在描述场景的时候,经常会从系统内部来看并描述外部世界。这个其实是不对的,应该是俯视,这样才能看清项目相关人员与系统的交互,并了解相关人员的目标。
比如,我们经常会写成“读取ATM卡和PIN号码,并从账号余额中扣除一定数量”,但是正确的俯视的写法是:用户插入ATM卡并输入PIN。
说明 · · · · · ·
表示其中内容是对原文的摘抄