需求开发指南2-需求的基本概念

fasiondog · · 610次浏览 ·

作者:fasiondog  来源:https://fasiondog.cn/archives/1382.html

1.2 层次与边界

从之前的定义中可以看出,业务需求、系统需求、模块需求体现了需求逐步被分解、细化的过程,三者之间的关系如下图所示:

需求的层次

需求的层次

厘清业务需求、系统需求和模块需求之间的边界范围,是进行有效的需求分析和软件开发的基础。“边界”是软件开发方法中的重要概念,任何系统都有一个边界,外界只能通过这个边界来认识系统,与系统打交道。边界也是我们认识事物的基础,我们需要通过系统的行为、外观、性质来描述它是一个什么东西,而行为、外观、性质就是这个东西的边界。边界的作用体现在以下几个方面。

1.2.1 边界决定视界

边界可大可小,由需求分析人员主观臆定。收集需求和开发软件的过程,有点像盲人摸象,墙或是柱子,在不同的边界条件下都是正确的。为了更接近真相,需要我们不断的变换边界、改变视界,从更多的视角去描述同一个信息,以求最大程度的符合真实的需求。

1.2.2 边界决定抽象层次

在需求分析与开发过程中,总要确定选择在哪个抽象层次来展开需求描述。而边界的扩大、缩小决定了抽象层次。从业务需求到系统需求,再从系统需求到模块需求,其本质正是边界不断缩小、从抽象逐步到具体的过程,也是是自顶向下的软件工程思想的体现。在软件工程实践中,解决问题的过程并非严格的“自顶向下”,但编写好的需求文档或是设计文档,却一定需要“自顶向下”的表达。易于理解的文档一定遵循由高到低、由粗到细、由抽象到具体的表述。因而,正确理解边界,掌握从业务需求如何得到系统需求,系统需求又如何得到模块需求,正是需求分析和需求文档写作的基础。

在实际的软件开发活动中,正是由于需求开发人员缺少对需求边界的明确认识,混淆了不同级别需求之间所对应的边界范围,而导致经常出现下面的现象或问题:

  • 《系统需求规格说明书》和《软件需求说明书》(或者《业务需求规格说明书》和《系统需求规格说明书》)写起来一模一样,基本就是拷贝+粘贴。
  • 《需求规格说明书》需要写到什么程度?要多细?需求或用例的粒度如何把握?

当出现上述问题时,应该首先确认是否选择了正确的边界,并检查自己是否越过了这个边界。

1.2.3 边界确定“参与者”和信息

边界意味着系统和外部环境之间的物质、能量、信息的交换(对于纯软件系统只涉及信息的交换),这确定了和系统存在交互的对象及其之间交互的信息。在基于用例的需求分析方法中,和系统进行交互的对象称为“参与者(Actor)”。边界的不同决定了“参与者”及其目的的不同,也决定参与者和系统之间交换的信息存在差异。

例如(见下图):将银行视为一个整体,那么“储户”就是银行系统的客户,是其参与者。对应的“提前现金”则是银行系统为储户提供的服务,也称为银行系统的业务需求,其对应的用例称为业务用例,对应的流程称为业务流程。当客户走进银行办理取款时,需要先排队取号,然后到柜台,由柜员进行取款操作并提取现金交给客户。银行为了实现IT化时,排队取号由排队机完成,柜员通过柜面系统完成取款交易。对应的,排队机、柜面系统需要提供的功能则分别包括:排队取号、取款交易。

边界不但确定了参与者,还同时确定了参与者与系统之间交互的信息,而明确这些信息同样是需求分析的重要工作。如在上例中储户和银行的交互传递的是什么信息? ——取款单。在业务需求分析中,需要明确取款单的内容。柜员和柜面系统之间交互的信息,则是由柜员将取款单的信息,通过界面录入到计算机中,其中或许存在为了系统实现额外加入的信息,但主体仍然是取款单信息。明确这些额外加入的信息,则是系统需求分析的重要工作之一。

边界示例

边界示例


发表评论

电子邮件地址不会被公开。 必填项已用*标注

我不是机器人*