Take note of the following traps: • Too many usage examples If you find yourself in the explosion of the instance, you may not be able to write a document in a suitable abstortion. Do not write separate use instances for each possible description. Instead, integrate the normal process, optional process, and exception to write a simple usage example. Do not see each step in the interaction as a separate usage example. Each usage instance must describe a separate task. You will get more examples of usage than business needs, but your functional needs will be more than using instances. Each usage example describes a method that allows users to interact with the system to achieve specific goals. • Redundancy (Duplication Accross) If the same function appears in multiple usage instances, it is possible to rewrite the implementation of the function multiple times. To avoid repetition, you can use the "including" relationship, in which the public function is separated and written in a separate usage example, when other use instances require this function, you can request calls. • Design usage instances using the user interface in the instance should focus on what the user uses the system, not what is displayed on the screen. Emphasize the understanding of conceptual dialogue between executors and systems, and postpon detail of the user interface to the design phase. The impact of screen and user interface mechanisms on any screen is only visualization of the executor-system interaction, and does not use the primary design instructions. • Using an instance I have seen some use instances that include data items and data structures definitions, which can manipulate these data items and data structures, including data types, lengths, formats, and legitimate values. This method makes the participants of the project difficult to find the definitions they need, because in the instance, it means that each of the data it contains is not obvious. This can also lead to redundant definitions, when a use instance changes, other no changes, but destroy synchronization. Data definitions should be concentrated in the data dictionary applicable to the entire project (discussed in Chapter 9) to reduce inconsistency when using this data. • Try to contact every requirement with an instance using an instance can effectively capture most desired system behavior, but you may have some needs, these needs and user tasks or other executives have no specific relationships. . At this point you need a separate demand specification, you can write non-functional demand documents, external interface requirements documents, and some functional requirements that cannot be obtained by using instances in this specification.
