一、参考 wiki 关于系统的定义中对边界的定义
系统理论将世界视为一个相互关联的零件的复杂系统。 一个系统通过定义其边界来定义; 这意味着选择哪些实体在系统内部并且哪些是环境的外部。 可以对系统进行简化的表示（模型），以便理解它并预测或影响其未来的行为。 这些模型可以定义系统的结构和行为。
Systems theory views the world as a complex system of interconnected parts. One scopes a system by defining its boundary; this means choosing which entities are inside the system and which are outside—part of the environment. One can make simplified representations (models) of the system in order to understand it and to predict or impact its future behavior. These models may define the structure and behavior of the system.
我们可以将系统视为单个系统对象，具有一组任何对象的职责，以及尚未考虑的实现。 Jacobson 提出了一个类似的想法，但是它在不同的方向。在基本用例中，我们可以使用职责来帮助确定系统的边界。如果系统像一个单一的对象，那么用例就像这个对象的方法。它们允许访问系统行为，并且不能进行其他访问。用例中的交互类似于方法参数和返回值，但是以顺序方式管理。
我们发现用例图有助于加强这个想法。我们使用一种形式的用例图，如在UML 中，显示了actor（作为stick figure）和它们与用例（作为椭圆）的参与。我们还显式地显示了系统边界，描述为围绕用例的框，用在演员和用例跨过边界之间的线，如图gif所示。这清楚地分离了演员的意图和系统的责任。 Jacobsen 使用了在用例图中显示系统边界的惯例，但通常不会使用UML或Rational Unified Process 。我们发现它是值得的，与系统作为一个对象的想法一致，并有助于解决有关确定系统责任的边界的问题。
Determining the System Boundary
In our experience, a major issue in determining requirements is distinguishing what the system should do from what it should not do. It often difficult to make decisions about this boundary, but it is also often difficult to communicate about this issue with all the people involved, analysts and stakeholders. We have found that it is very helpful to apply an approach familiar in design. We present the system as a
black-box”, with an explicit boundary, describing the behavior of the system by essential use case responsibilities.
We can regard the system as a single system object, with a set of responsibilities like any object, and an implementation not yet under consideration. Jacobson  proposes a similar idea, but takes it in a different direction. With essential use cases, we can use the responsibilities to help determine the boundary of the system. If the system is like a single object, then the use cases are like methods of this object. They allow access to the system behavior, and no other access is possible. The interaction in a use case resembles method parameters and return values, but managed in a sequential way.
We have found use case diagrams useful in reinforcing this idea. We use a form of the use case diagram that, as in UML , shows actors (as stick figures) and their involvement with use cases (as ellipses). We also explicitly show the system boundary, depicted as a box surrounding the use cases, with the lines between the actors and the use cases crossing the boundary, as shown in figure gif. This clearly separates the actor’s intention from the system’s responsibility. This convention of showing the system boundary in use case diagrams was used by Jacobsen  but does not typically feature in use of UML or in the Rational Unified Process . We have found it worthwhile, consistent with the idea of the system as an object, and helpful in resolving issues about determining the boundary of system responsibilities.