Я не мистер Кокберн, но ...
Актер должен быть любым (или кем-либо), кто вступает в контакт (/ использует) с системой. <= Более простое определение для меня. </p>
1.) Так что в вашем случае, клиент должен быть актером.
2.) Я всегда создавал прецеденты с использованием только прецедентов и действующих лиц. Каковы заинтересованные стороны и интересы? Они просто другие актеры. Если нет, это просто добавляет сложности инструменту, который должен быть простым. (ИМО)
Кстати: "The system looks up unpaid orders and sends reminder to customer". действительно вариант использования? Разве это не сценарий (часть варианта использования)?
Редактировать: варианты использования должны описывать поведение с точки зрения конечного пользователя. Так что это действительно должно быть что-то вроде:
Scenario: Pay for order
Actor: Customer
Flow:
1. Customer requests unpaid orders from system (not specifing how).
2. System provides (shows) unpaid orders.
3. Customer chooses one order
4. System process selection and shows detail about selected order
5. Customer requests to make a payment (again not telling something like 'customer will click on button called "pay"')
6. System requests payment details from user
7. User fills details
8. System validates entered data
9. IF successful:
a.) Order payment is comleted, system redirects user to XXX.
10. ELSE go back to step 7
Это может быть немного длинно ... но это в основном то, как я делаю сценарии (которые сгруппированы в один вариант использования).