Which parts should be included in the document, why should they include these parts?
Scott W. Amblerronin International President October 5, 2000
Content: Reference Resources Author
Scott Ambler clarifies the difference between basic use cases and system instances, and some suggestions for how to write these two types of use cases (mainly discussed system use cases). This article is "The Object Primer 2
The third chapter of ND Edition is adapted.
When recording the behavioral demand based on components, the use case is one of the most common technologies. One of the problems that developers often ask Yes, "What information should be included?" Although some parts I mentioned here are optional, but in my opinion, these parts include a good idea in the use case document. . When writing a basic use case (see the previous skill MODELLING ESSENTIAL USE CASES), I tend to ignore the optional part (because the basic use case is concerned about what, not why, there is no need to complicate like the system ). When writing system usage, I usually include all parts. Looking back, the main difference between the basic use cases and system use cases is that system use examples include advanced implementation decisions, and basic use cases capture users in a manner that is unrelated to technology and implementation.
Participants (actors) and the use cases of the use cases actually only look at the example. However, according to my experience, each use case is best independent. In other words, the use case should include all critical information they need and their context. This allows your subject matter expert (SME) to enrich each use. (They may work together in the group in the morning, and the present independently enrich the use cases allocated with the fastest speed, thereby improving the production efficiency of the entire group.)
Each component of the use case
