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 [17] 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
[23], 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 
. 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 [17] but does not
typically feature in use of UML or in the Rational Unified Process
[16]. 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.
Figure: A use case diagram, explicitly showing the boundary
around the system object.