分享

许多人傻傻分不清 “业务需求、用户需求和系统需求”

 过河卒冲 2021-05-27

软件研发自然离不开需求,而且我常说:需求是源头,需求的质量最为关键,也就是我们经常说的,首先要做对事情,“做正确的事” 比“正确地做事” 更重要。需求这么重要,那么我们搞清楚需求自然也就很重要,但是许多研发同学(包括测试同学)都搞不清什么是需求,傻傻分不清 “业务需求、用户需求和系统需求”,一谈需求就会提 “系统的功能、性能” 等,完全忽视业务需求,正如文章 “业务需求与系统功能,你分清楚了吗?” 所描述的场景:

小艾:“新来的那位资深 QA 同学技术很不错,感觉对业务理解还是不够,想要他讲一下 XX Feature(特性)的业务,结果他一上来就打开系统,给我们演示具体的操作流程……”

我也曾经看到过某企业的一个正式文档,如下所示,标题明明是“业务需求总体描述”,但一上来就是“主要功能模块”,丝毫没有业务需求的描述。

图片

(错误的业务需求描述文档)

功能需求不是业务需求,甚至可以说是业务需求的解决方案(非功能特性是解决方案的约束条件),因为功能往往是研发人员定义和设计的,通过实现某项功能来满足用户需求,所设计的功能只是其中的一个方案。为了满足不同的业务需求,完全可以设计不同的功能、不同的UI(用户界面),例如:通过用户名/口令登陆系统,是一个 “登录” 功能需求,它要解决的问题是用户身份验证,我们也可以通过U盾、指纹、人脸识别等各种功能解决这个问题。你可能感觉某个功能好用、实现得不错,但把它放在一个特定的业务环境中,它可能就有问题,如缺乏安全性,不能满足业务要求。这也就是说,脱离业务环境来讨论软件系统的功能是没有意义的,所以今天的软件质量模型ISO/IEC 25010把之前单纯的 “功能” 改为“功能适应性”,功能必须适应业务环境才是有效的、有价值的。说到这里,你大概了解什么是 “业务需求(Business Requirements)” ,那就是解决特定业务领域中的一个问题,例如:在个人纳税业务中,解决的问题主要有:所在区域(省、市)所有纳税人方便申报个税、个人收入汇总、已缴的税款统计、计算要补交的个税额度等。业务需求具体的表现为业务流程、业务规则、业务角色、业务数据、业务可管理性、业务发展等,针对业务也可以建模,也就是人们通常所说的领域建模和商业画布等,有图为证。

图片

(业务建模示意图)

图片

(商业画布/业务分析模板)

图片

(商业画布示例)

业务需求通常通过MRD(市场需求文档)、用业务领域的术语来描述,一般由业务人员和市场调研人员提出来。有些开创性的软件产品,意味着目前还不存在那样的市场,而是挖掘某一类群体所面临的问题(痛点)、所拥有的欲望或潜意识等,从而去解决这类问题或满足这类潜在的需求。

是不是有了这些业务需求,就可以讨论系统的功能或非功能特性了?别急,还没有到系统需求这个层次。你想一想,在敏捷中常常用于需求描述的“用户故事” 还没出现呢!那“用户故事” 是什么?是什么需求?“用户故事” 是用例(Use Case)另一种说法,其实就是用户行为分析,把它归为“用户角色需求”:作为一个特定的用户角色,想通过做什么到达什么目的。在某个特定的业务活动 或 业务流程中,不同的用户(end user)角色(roles)发挥不同的作用,其行为是不一样的,即需求也是不一样的。例如,在个人办税(申报)活动中,要区分收入超过12万和不到12万的用户,也要区分是自己申报还是代理人申报、是否为外籍人士或港澳台人员等。不同的用户,在同一个活动(如 办税)中所要处理的事务有差别,期望的结果也不一样。

把用户角色的需求,进一步扩展到干系人需求,包括系统运维、技术支持、销售、市场等相关人员的需求。今天,软件作为一种服务,这些干系人的需求更为显著,他们也可以看成是软件系统的广义用户。

我们所构建的软件系统最终是为用户所用,所以我们所构建的系统需要更好地满足最终用户不同角色的需求,即系统的功能是为了支持用户的需求,而业务需求要分解成用户角色需求,在敏捷中就是将业务需求(产品故事 Epic)分解为用户故事,而用户故事又需要具体的系统功能来实现。为了保证业务服务能正常开展,还需要软件系统具有良好的性能、兼容性、安全性和可靠性等支撑。

下面用一张图来说明三个层次的软件需求:业务需求、干系人需求和系统需求之间的关系。

图片

(不同层次的软件需求的关系)

图片

(软件不同层次需求之间的另一种表达)

如果从测试角度看,你可以写覆盖业务需求的用例(通常是end-to-end用例,即覆盖业务流程图中基本路径的E2E用例);你也可以写覆盖用户角色需求的用例(通常采用基于场景的测试方法而设计的用例),即用户故事的验收标准(AC)、BDD GWT场景的实例化结果(相当于在AC、GWT的基础上加上具体的测试数据)。你也可以针对系统功能写功能测试用例、针对安全性做渗透测试、针对性能做负载测试,等等。所以,当你谈测试覆盖率时,一定要从某个需求层次的高度去谈。

如果大家像 从一则笑话 看产品需求获取与分析 所描述的那个学生那么认真对待需求,相信大家一定能把 软件需求 搞清楚😄 

(15个专场中的一个专场)

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多