The approach we have outlined, based on essential use cases and object responsibilities, is quite applicable even to those systems without a traditional user interface, such as embedded systems, or software engines that interact only with system actors.
The key point here is that any system has to interact with the ``outside world''. For any system, it is important to determine the boundaries between the interior and exterior of the system; to determine the principal interactions between the system's actors (human or machine); and to characterize those interactions in a way that facilitates later design. We have found that essential use cases retain most of the same benefits for these kind of systems (or rather, these kind of interfaces to systems) as they do when used to describe user interfaces: by working at the right level of abstraction, they capture the essence of the actors intentions and system responsibilities while eliding the accidental details of syntax and implementation. As we have described, essential use cases are smaller (and thus quicker to write, review, and modify) than longer, more detailed use cases, and facilitate system responsibilities flowing seamlessly from analysis to design: all these benefits apply equally to interactions with system actors as well as with human users.
Real-time systems often impose non-functional constraints (response time, transaction rate, information volume, reliability) upon their use cases. When using more conventional use cases, such constraints can be associated with the use cases narratives, and managed along with them. Managing these constraints is orthogonal to the way use cases are structured, and this information can be handled in much the same way when using essential use cases. Usage-Centered Design [9], for example, has always associated this kind of property with essential use cases, since they are crucial to the design of high-performance user interfaces.
The traceability between the system responsibilities of the essential use cases, the consequent responsibilities of the system object, and the resulting responsibilities of the internal objects making up the system design is also beneficial in ensuring the system does meet such non-functional constraints. For example, the system-level constraints (on use cases) can be propagated forwards with their responsibilities to objects during design, and objects' non-functional performance can be tracked backwards via their responsibilities to the use cases. Either way, the explicit traceability gained by using a common notion of responsibility can be used to verify that such non-functional constraints can be met in a final design.