I'll try to answer a few of these Wolfgang.
UML defines the four scope values that EA presents. Some tools ask - or allow - you to type them in freehand. Of these tools, some then validate what you typed, so you have to use one of the defined values, and some allow the value to remain as typed. This is useful for non-English models, but can wreck havoc when you move to code engineering. Note that UML does not provide for all scopes in use by major languages and development platforms, so many tools allow extensions here.
Level may refer to how far you have to drill down to the use case. It is not - to the best of my knowledge - a value from UML. Hopefully the gurus will correct me if I'm mistaken here.
Yes, the notes would be good for context. You would want to explain, if it was not obvious to your audience - why, how and when this use case might come about.
Primary actor. This is to distinguish an Actor from a Secondary Actor. This is not a formal UML distinction, but is very useful in some cases. Some methodologies, or modelling approaches in a less formal sense, identify as actors systems or roles that affect (or are affected by, or participate in) the use case in some indirect manner. You sometimes see secondary actors indicated by the rectangle notation with an <<actor>> stereotype shown and the primary actors as the common "stick men." [I personally find this quite useful, particularly when I present to less technical audiences.]
An example of primary and secondary actors would be the "Withdraw cash" use case for an ATM controller. The customer is a primary actor, and participates directly in the use case. The use case itself scoped to the ATM (this would be in your context) but must have some interoperation with the bank's account management system; however the bank's systems are not within scope, nor will the builders of the ATM be designing or modifying the bank's systems. The bank, or its account management system (depending on your level of detail) is involved however, and the use case depends on interaction with the bank. Thus, the bank, or its system, is a secondary actor in this case.
Preconditions - yes, you've got it.
Trigger. Similar to the context stuff. What event or circumstance causes this use case to be invoked? In the case of lower-level use cases this can be important. In a small system or one with straightforward interactions, you may not bother with this. For example, Enter Data, Maintain Database, etc. might be fairly obvious for the bowling league's game tracking system. But, in the case of a multi-user distributed, Web-based system you may really need to know why this use case should happen (context) and what specifically caused it (trigger) before the scenario makes sense.
HTH,
David
