作者：fasiondog 来源：http://fasiondog.cn/archives/1382.html
1.2 层次与边界
从之前的定义中可以看出，业务需求、系统需求、模块需求体现了需求逐步被分解、细化的过程，三者之间的关系如下图所示：
需求的层次
厘清业务需求、系统需求和模块需求之间的边界范围，是进行有效的需求分析和软件开发的基础。“边界”是软件开发方法中的重要概念，任何系统都有一个边界，外界只能通过这个边界来认识系统，与系统打交道。边界也是我们认识事物的基础，我们需要通过系统的行为、外观、性质来描述它是一个什么东西，而行为、外观、性质就是这个东西的边界。边界的作用体现在以下几个方面。
1.2.1 边界决定视界
边界可大可小，由需求分析人员主观臆定。收集需求和开发软件的过程，有点像盲人摸象，墙或是柱子，在不同的边界条件下都是正确的。为了更接近真相，需要我们不断的变换边界、改变视界，从更多的视角去描述同一个信息，以求最大程度的符合真实的需求。
1.2.2 边界决定抽象层次
在需求分析与开发过程中，总要确定选择在哪个抽象层次来展开需求描述。而边界的扩大、缩小决定了抽象层次。从业务需求到系统需求，再从系统需求到模块需求，其本质正是边界不断缩小、从抽象逐步到具体的过程，也是是自顶向下的软件工程思想的体现。在软件工程实践中，解决问题的过程并非严格的“自顶向下”，但编写好的需求文档或是设计文档，却一定需要“自顶向下”的表达。易于理解的文档一定遵循由高到低、由粗到细、由抽象到具体的表述。因而，正确理解边界，掌握从业务需求如何得到系统需求，系统需求又如何得到模块需求，正是需求分析和需求文档写作的基础。
在实际的软件开发活动中，正是由于需求开发人员缺少对需求边界的明确认识，混淆了不同级别需求之间所对应的边界范围，而导致经常出现下面的现象或问题：
- 《系统需求规格说明书》和《软件需求说明书》（或者《业务需求规格说明书》和《系统需求规格说明书》）写起来一模一样，基本就是拷贝+粘贴。
- 《需求规格说明书》需要写到什么程度？要多细？需求或用例的粒度如何把握？
当出现上述问题时，应该首先确认是否选择了正确的边界，并检查自己是否越过了这个边界。
1.2.3 边界确定“参与者”和信息
边界意味着系统和外部环境之间的物质、能量、信息的交换（对于纯软件系统只涉及信息的交换），这确定了和系统存在交互的对象及其之间交互的信息。在基于用例的需求分析方法中，和系统进行交互的对象称为“参与者（Actor）”。边界的不同决定了“参与者”及其目的的不同，也决定参与者和系统之间交换的信息存在差异。
例如（见下图）：将银行视为一个整体，那么“储户”就是银行系统的客户，是其参与者。对应的“提前现金”则是银行系统为储户提供的服务，也称为银行系统的业务需求，其对应的用例称为业务用例，对应的流程称为业务流程。当客户走进银行办理取款时，需要先排队取号，然后到柜台，由柜员进行取款操作并提取现金交给客户。银行为了实现IT化时，排队取号由排队机完成，柜员通过柜面系统完成取款交易。对应的，排队机、柜面系统需要提供的功能则分别包括：排队取号、取款交易。
边界不但确定了参与者，还同时确定了参与者与系统之间交互的信息，而明确这些信息同样是需求分析的重要工作。如在上例中储户和银行的交互传递的是什么信息? ——取款单。在业务需求分析中，需要明确取款单的内容。柜员和柜面系统之间交互的信息，则是由柜员将取款单的信息，通过界面录入到计算机中，其中或许存在为了系统实现额外加入的信息，但主体仍然是取款单信息。明确这些额外加入的信息，则是系统需求分析的重要工作之一。
边界示例